Proposal for reorganizing test directories

2012-10-25 Thread Henrik Skupin
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

Re: Proposal for reorganizing test directories

2012-10-25 Thread Henrik Skupin
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

Re: Proposal for reorganizing test directories

2012-10-25 Thread Boris Zbarsky
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,

Re: Proposal for reorganizing test directories

2012-10-25 Thread Justin Lebar
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. I

Re: Proposal for reorganizing test directories

2012-10-25 Thread Jason Duell
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

RE: deadlock while flash plugin calls posturlnotify

2012-10-25 Thread LANGLOIS Olivier PIS -EXT
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

RE: deadlock while flash plugin calls posturlnotify

2012-10-25 Thread LANGLOIS Olivier PIS -EXT
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]