Re: Changes to tests build system integration (mostly xpcshell for now)
Just landed in inbound is a mass conversion of mochitests to use manifests.
Not all references were moved. However, the intention is to move them
all eventually. If you want to help with the effort, the tracking bug is
920185. See
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=22a30d73daf6
for what is involved.
Please try to avoid adding new mochitest-related functionality to
Makefile.in files, as you'll just be creating more work for the eventual
conversion.
The manifest file format is documented at
https://ci.mozilla.org/job/mozilla-central-docs/Build_Documentation/test_manifests.html.
On 9/24/13 9:23 PM, Gregory Szorc wrote:
Just landed in inbound and bound to stick sooner or later are some
changes to how tests are integrated with the build system.
* The per-directory xpcshell make targets have been removed. Use mach
(preferred) or TEST_PATH=... make xpcshell-tests top-level make target.
* xpcshell.ini files are now required to annotate their support files
so the build system knows what needs to be installed. i.e. files added
to xpcshell test directories are no longer automatically packaged by
default.
* Support for test manifests for all the flavors of mochitests have been
added to moz.build files. This means we should not be defining
mochitests in Makefile.in any more. Instead, create {browser-chrome.ini,
mochitest.ini, chrome.ini, a11y.ini} files (like xpcshell.ini files) and
reference said files in moz.build files via A11Y_MANIFESTS,
BROWSER_CHROME_MANIFESTS, MOCHITEST_MANIFESTS, and
MOCHITEST_CHROME_MANIFESTS. Bug 920185 has been filed to track this
effort. **Moving files over and reducing the total number of Makefile.in
and moz.build files will make the tree build faster.**
* Test manifests now support some additional features. Run |mach
build-docs| or see
http://build-docs.paas.allizom.org/test_manifests.html for the canonical
documentation.
___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Xulrunner and Angularjs
After some tweaking around in the angular code because XULrunner returns 0 as
status for successful xhr request made to local resources (on disk) I am
running into yet another obstacle.
Any link that's manipulated by angular stops working:
a href='#/students/JON'Wors/a
a href='#/students/{{JON}}'doesnt work/a
Yet links that are dynamically added work fine too
var a=document.createElement(a);
a.href=#/students/JON;
a.innerHTML=JS added works fine;
document.body.appendChild(a);
The html file is in a XUL browser element and all the scripts and templates are
located in chrome://myapp/content/. After having angular accept 0 as a
successful return status, loading the templates and binding the data XUL
descides it's time to mess with the links.
Working links have a href of: chrome://myapp/content/index.html#/students/JON
Non working: unsafe:chrome://myapp/content/index.html#/students/JON
This only happens to elements that angular binds data to. Not sure why this
feature of XUL would do this because all links point to resources located in
chrome://myapp/content/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
DOM Bindings Meeting - Monday (today) @ 12:30 PM PDT
Our (professedly) weekly DOM bindings meetings continue on Monday Sept 30 at 12:30 PM PDT. Thanks to Kyle Huey for sending out these meeting notices over the last year or so! Meeting details: * Monday, September 30, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST) * Dial-in Info: - Vidyo room: Boris Zbarsky - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference number 9235 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Hang monitoring for non-main threads
Hi all, I'm looking at implementing a hang monitoring mechanism for non-main threads. The initial motivation was that we've been noticing hangs on the compositor thread in Fennec. These hangs are not as easy to notice as main thread hangs, and we'd like more information about them like how frequently they occur. As we move more components off main thread, I think this kind of information could be useful to other areas as well. So far I looked at the main thread hang monitor [1], but it seems to make a lot of assumptions about the main thread. I think it would make sense to have a separate, generic hang monitor that can monitor multiple other threads. Each thread would register with the hang monitor and tell it how much time the thread must be blocked before it's considered a hang. The hang monitor would then relay counts/histogram of hangs to telemetry. It would be even better if we can get stacks. One thing I'm not sure about is we have a variety of threads (IPC threads, media threads, etc.), and I don't know how hard it would be to adapt them to use the hang monitor. Please share your comments and suggestions! Thanks, Jim [1] http://mxr.mozilla.org/mozilla-central/source/xpcom/threads/HangMonitor.cpp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Hang monitoring for non-main threads
On 9/30/2013 2:48 PM, Jim Chen wrote: So far I looked at the main thread hang monitor [1], but it seems to make a lot of assumptions about the main thread. Yes. I think it would make sense to have a separate, generic hang monitor that can monitor multiple other threads. Each thread would register with the hang monitor and tell it how much time the thread must be blocked before it's considered a hang. The big problem is properly defining what hung actually means. For threads which primarily process events, hung pretty much means that the thread is stopped in the middle of processing an event but has never finished. But not all threads are like that. And, you have to be aware of times such as a computer going to sleep when a thread is hung on purpose by the user. But this kind of hang monitoring wouldn't catch a problem if a thread stopped processing events for some other reason. It might also get confused with nested event loops. The main-thread hang monitor original was designed to crash the app after a prolonged hang, but it turns out that getting sleeping computers right as well as scaling the timeout to slow systems especially at startup was causing false positives. So the hang monitor is currently just used for telemetry collection. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Hang monitoring for non-main threads
On 30/09/2013 2:48 PM, Jim Chen wrote: So far I looked at the main thread hang monitor [1], but it seems to make a lot of assumptions about the main thread. I think it would make sense to have a separate, generic hang monitor that can monitor multiple other threads. I like the idea, but with Benjamin's caveats The hang monitor would then relay counts/histogram of hangs to telemetry. It would be even better if we can get stacks. Getting stacks will not be difficult, you can use the same infrastructure as the chrome-hang reporter. Are you interested in permanent hangs or transient hangs? You'll have to make sure the browser can still exit properly when the hangs you're interested occur, otherwise Telemetry might not get a chance to write down the hang info to disk at session exit and it will never get reported. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Silencing debug spew
Hi everyone, If you run debug builds, you're probably aware of all the gunk that gets dumped out to the console for even simple things like starting up a browser. There's probably a rationale for all of WARNING: No disk space watcher component available!: file /home/billm/mozilla/in1/dom/indexedDB/IndexedDatabaseManager.cpp, line 207 these messages and warnings, and we probably do fix some of them occasionally. But at this point, there are so many that it's a ++DOMWINDOW == 4 (0x7effb67f08b8) [serial = 4] [outer = 0x7effb67ef8b8] ++DOMWINDOW == 5 (0x7effb64f1cb8) [serial = 5] [outer = 0x7effbfbe70b8] little overwhelming. What's really bothersome is that my own WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) subjPrincipal) failed: file /home/billm/mozilla/in1/docshell/base/nsDocShell.cpp, line 8442 debugging printfs are hard to find in all the unrelated spew. I just landed bug 921293, which makes it possible to silence some of these messages with an environment variable. If you just add the following to your .bashrc or whatever: # Silence ++THIS and --THAT export MOZ_QUIET=1 # Silence NS_WARNING export MOZ_IGNORE_WARNINGS=1 then you won't get any more messages about DOM windows or docshell creation/destruction or about NS_WARNINGs firing. So far it's had a much more positive effect on my debugging experience than I would have expected. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Silencing debug spew
Bill McCloskey writes: # Silence ++THIS and --THAT export MOZ_QUIET=1 # Silence NS_WARNING export MOZ_IGNORE_WARNINGS=1 then you won't get any more messages about DOM windows or docshell creation/destruction or about NS_WARNINGs firing. Thanks very much, Bill. I think I'll also find this useful. Can we all agree to only use NS_WARNING for things that are unlikely to happen? This includes NS_ENSURE_SUCCESS and friends. I thought there was almost consensus on avoiding NS_ENSURE_* because of the way jump statements are hidden, but I've still seen some advocating. Can we at least agree not to use NS_ENSURE_SUCCESS when failure is reasonably likely in normal use? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Silencing debug spew
If MOZ_IGNORE_WARNINGS=1 becomes common, I worry that warning spew will pile up even more than it does now, making it impossible to use warnings as part of the development process. Incorrect warnings should be removed. Especially noisy warnings, such as those that happen during startup and showdown, should be disabled until the underlying bugs are fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=fx-noise ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
