Re: Non-Trivial SpecialPowers Usage Considered Harmful
Bobby Holley bobbyhol...@gmail.com writes: [...] If you find yourself itching to do something complicated, write a mochitest-chrome test. The default template [2] now generates html files (rather then XUL files), so the ergonomics there should be easier than before. If you don't want to write a mochitest-chrome test for some reason, you can also use SpecialPowers.loadChromeScript(uri), which lets mochitest-plain asynchronously load a privileged JS file in its own privileged scope. On e10s-enabled platforms, does loadChromeScript run the script in the parent process? There are currently a few mochitests (plain) that are SpecialPowers'ing nsLocalFile (or other classes that do direct filesystem access) in the content process, and I'd like to change them to remote that part of the test to the parent process -- preferably without reducing test coverage. (See also: https://bugzil.la/1043470#c6 ) --Jed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Non-backward compatible changes to JS 'let' semantics
On 8/15/14, 1:03 AM, Gijs Kruitbosch wrote: On 15/08/2014 07:17, Jeff Walden wrote: I think our best bet is probably to evangelize the change hard, update AMO linters to flag the issue, and (gulp) wait for, and assist wherever possible, addon authors to update their code. Part #1, shouldn't be too bad because they're syntax errors easily observed (and linted by AMO scripts). Last I checked, AMO's review flagging tools were all regex-based. I doubt even issue 1 is easily regex-able. :-( Maybe this has changed? Jorge? ~ Gijs As Jeff pointed out, we do have the ability to inspect the syntax with more depth than just regular expressions. Jorge ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Structured logging in mochitest and changes to command line arguments
Hi! Structured logging[1] for mochitest (along with other test suites) has landed and this could affect some of your scripts/workflows. Since the test harness now generates structured JSON logs instead of formatted strings, you can use different formatters to format your logs. [2] The following command will print the logs formatted with the mach formatter to stdout, and save the raw JSON logs to mochi.json: mach mochitest-plain --log-mach=- --log-raw=mochi.json If you want to get a formatting similar to the legacy formatting (activated by default if you don't pass a parameter), use the TBPL formatter: mach mochitest-plain --log-tbpl=mochi.log Note that we removed the --log-file arg so you will have to use the new syntax to save logs directly to a file. It's possible these changes to mochitest cause (more) regressions, so please file a bug if you see anything suspicious and make sure you CC me (akachkach), chmanchester and jgraham. [1] http://mozbase.readthedocs.org/en/latest/mozlog_structured.html [2] http://mozbase.readthedocs.org/en/latest/mozlog_structured.html#example-output ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Tuesday, 19 August 2014 at 4:00pm PDT
The next MemShrink meeting will be brought to you by the Asynchronous Pan/Zoom Controller (APZC) not leaking testing data when disabled: https://bugzilla.mozilla.org/show_bug.cgi?id=1041751 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 19 August, 4:00 PM PDT * http://arewemeetingyet.com/Los%20Angeles/2014-08-19/16:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - 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 num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Exporting user configurations
Hi, I wrote a blog post about a bug that was hard to diagnose because it involved a rarely-used cookie-related preference (https://blog.mozilla.org/nnethercote/2014/08/15/the-story-of-a-tricky-bug/). One of the commenters made an interesting suggestion: some kind of about:config export tool that would make it easier for Firefox devs to reproduce these kinds of problems. Do we have anything like that, currently? You can just bundle up an entire profile, but that's not easy, plus it contains all sorts of sensitive information. I guess about:support lists all the important modified prefs, though interpreting those can be difficult. Some kind of privacy-respecting profile replicator could be useful. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exporting user configurations
Nicholas Nethercote wrote: One of the commenters made an interesting suggestion: some kind of about:config export tool that would make it easier for Firefox devs to reproduce these kinds of problems. The profile prefs.js only contains the modified preferences, if that's all you need. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exporting user configurations
I seem to remember that the SUMO folk had an add-on that would install restartlessly and gather system info to pass along to them. I don't remember the specifics though. On Mon, Aug 18, 2014 at 4:19 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Hi, I wrote a blog post about a bug that was hard to diagnose because it involved a rarely-used cookie-related preference ( https://blog.mozilla.org/nnethercote/2014/08/15/the-story-of-a-tricky-bug/ ). One of the commenters made an interesting suggestion: some kind of about:config export tool that would make it easier for Firefox devs to reproduce these kinds of problems. Do we have anything like that, currently? You can just bundle up an entire profile, but that's not easy, plus it contains all sorts of sensitive information. I guess about:support lists all the important modified prefs, though interpreting those can be difficult. Some kind of privacy-respecting profile replicator could be useful. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Running mochitests from a copy of the objdir?
Time was that you could just python runtests.py to run mochitests. Then we needed modules that you don't get in the default python, so you had to invoke python from the virtualenv instead. Now that doesn't work either, because it's trying to run .mozconfig, so my questions are a) why and b) how do I stop it? (I found --binary but that didn't seem to be enough on its own.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mochitests from a copy of the objdir?
You should use ./mach mochitest-* to run mochitests. Gavin On Mon, Aug 18, 2014 at 4:45 PM, Neil n...@parkwaycc.co.uk wrote: Time was that you could just python runtests.py to run mochitests. Then we needed modules that you don't get in the default python, so you had to invoke python from the virtualenv instead. Now that doesn't work either, because it's trying to run .mozconfig, so my questions are a) why and b) how do I stop it? (I found --binary but that didn't seem to be enough on its own.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Running mochitests from a copy of the objdir?
On 8/18/2014 4:45 PM, Neil wrote: Time was that you could just python runtests.py to run mochitests. Then we needed modules that you don't get in the default python, so you had to invoke python from the virtualenv instead. Now that doesn't work either, because it's trying to run .mozconfig, so my questions are a) why and b) how do I stop it? (I found --binary but that didn't seem to be enough on its own.) Can you please describe your workflow so we can consider a solution for your needs (as opposed to giving you hints on how to subtly hack around the existing implementation). i.e. please report user stories instead of trying to reverse engineer the build and automation systems :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
