https://bugzilla.mozilla.org/show_bug.cgi?id=805529
has been filed.
Thank you!
Olivier
-Original Message-
From:
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
O
I have found the problem!
when the main thread may wait on future events such as when it is notifying
another thread to shutdown, the code in nsBaseAppShell::OnProcessNextEvent
enters the glib loop assuming that native events will occur frequently allowing
it exit eventually when the thread eve
> Why have those tests be placed into this location and not beside the
actual implementation code?
Necko has had a general policy of not allowing mochitests within the
/netwerk tree, so any cookie, etc tests that need browser functionality
(i.e. more than xpcshell) live elsewhere. It's really
Ah, interesting. I think I misunderstood the main point of your
proposal -- your purpose isn't to standardize the names of directories
which contain tests much as to move tests closer in the directory
structure to the code they're testing.
Thanks for clarifying.
> So let me give one example.
>
>
On 10/25/12 11:51 AM, Rob Campbell wrote:
You won't have browser-chrome living next to xpcshell in the same location
(pretty sure, please correct me if I'm wrong).
http://mxr.mozilla.org/mozilla-central/source/docshell/test/
It's got xpcshell tests, xpcshell-ipc tests, browser tests,
browser
On 2012-10-25 11:49 AM, Henrik Skupin wrote:
Justin Lebar wrote on 10/25/12 10:06 AM:
I'd probably be a lot more sympathetic to this proposal if I
understood in a concrete way how making my life a little harder here
would make your life a little easier. What problem exactly are you
trying to s
+1.
Flatter directory structures are virtuous. I also shudder at the thought of a
bunch of patches and potential tree redness from scripts that shuffle around
our make files for no reason other than adding extra depth.
In most cases, the location of the tests will dictate what types of tests li
Justin Lebar wrote on 10/25/12 10:06 AM:
> I'd probably be a lot more sympathetic to this proposal if I
> understood in a concrete way how making my life a little harder here
> would make your life a little easier. What problem exactly are you
> trying to solve?
Good points. So let me give one e
I own dom/browser-element/, which has its tests in
dom/browser-element/mochitest.
I personally like the fact that we don't have the tests in
dom/browser-element/tests/mochitest. The extra directory would have
just one child, so from my perspective, it would add very little. (I
have to type this
Hi all,
When I started to work on tests for WebRTC and WebAPI lately I have
noticed that there are no clear specifications where tests have to be
added. Some are located in a tests subdirectory (like
/dom/feature/tests/) while others are under a testing folder (like
/dom/testing/mochitest). This i
10 matches
Mail list logo
