Re: All profile settings lost in new version

On 2016/09/02 20:15, Wayne wrote: I'm wondering, under what circumstances would a user have a prefs.js-1 and prefs.js be missing? ref https://support.mozilla.org/en-US/questions/1136992 ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Reorganization of Firefox-UI tests in mozilla-central

On 02/09/2016 13:49, Henrik Skupin wrote: Gijs Kruitbosch wrote on 09/02/2016 11:37 AM: We should be doing the same for firefox-ui tests. Not just to avoid duplication of files in archives, but because otherwise, if we want to add new tests somewhere else, we both have to add the manifests to

What if you could reinvent Firefox theming?

(cc'ing dev-platform, please reply to firefox-dev) What if you could reinvent Firefox theming? What would it look like, what would its capabilities be? We want users to have fun customizing Firefox and make it feel like their own. We hope to make it easier to create the type of themes that

Re: Reorganization of Firefox-UI tests in mozilla-central

Henrik, It's not clear to me if this is just moving the location of existing tests, or if you're bringing in new tests. If it's the later, I'm concerned that we're going to get more intermittents filed in Bugzilla, which adds noise to the triage process. If you are adding more tests, then would

RE: Reorganization of Firefox-UI tests in mozilla-central

I don't believe that's a workable situation. At the moment, the policy is that every new intermittent failure gets a bug filed for the purpose of tracking it. There's talk (and has been for at least a year or two, now) that work will begin on OrangeFactor version 2, where intermittent failures

Re: Reorganization of Firefox-UI tests in mozilla-central

On 2016-09-02 2:29 AM, Gijs Kruitbosch wrote: On 02/09/2016 00:15, Matthew N. wrote: On 2016-09-01 9:24 AM, Gijs Kruitbosch wrote: On 01/09/2016 16:37, Henrik Skupin wrote: Do those locations sound good? I have heard at least once that "firefox_ui" might not be the best choice as folder name,

Re: Reorganization of Firefox-UI tests in mozilla-central

On Fri, Sep 2, 2016 at 12:11 PM, Ryan VanderMeulen wrote: > On 9/2/2016 2:56 PM, Andrew McCreight wrote: > >> In DOM triage, we've just set up our list to not include bugs with the >> keyword intermittent failure. Ideally, we'd see intermittent failures that >> have a high

Re: Reorganization of Firefox-UI tests in mozilla-central

Gijs Kruitbosch wrote on 09/02/2016 11:37 AM: > I am not familiar with this bit of our build architecture, but as far as > I can tell from a quick look it builds bits of the zipfile off the > objdir. So it collects mochitests from $OBJDIR/_tests/testing/mochitest, > where (again, AFAICT) things

Re: Reorganization of Firefox-UI tests in mozilla-central

Gijs Kruitbosch wrote on 09/02/2016 01:22 PM: > AIUI, if we can run tests directly from a checkout, we no longer need > the common.tests.zip archive to exist (or at least not to have the tests > in them), so the problem is moot, no? Those files are used by test machines for all of our test

Re: Reorganization of Firefox-UI tests in mozilla-central

Gijs Kruitbosch wrote on 09/02/2016 01:22 PM: > AIUI, if we can run tests directly from a checkout, we no longer need > the common.tests.zip archive to exist (or at least not to have the tests > in them), so the problem is moot, no? I think so. There should not be a need to have to run "mach

Re: Reorganization of Firefox-UI tests in mozilla-central

On 02/09/2016 00:15, Matthew N. wrote: On 2016-09-01 9:24 AM, Gijs Kruitbosch wrote: On 01/09/2016 16:37, Henrik Skupin wrote: Do those locations sound good? I have heard at least once that "firefox_ui" might not be the best choice as folder name, but that's how the harness is called, and

Re: Reorganization of Firefox-UI tests in mozilla-central

On 02/09/2016 08:08, Henrik Skupin wrote: Gijs Kruitbosch wrote on 09/01/2016 06:24 PM: As I did over IRC, I would like to strongly object to the continued use of per-test-type subfolders in our test directories. You can already use a specific mach command per test type, and the tests are

Re: Reorganization of Firefox-UI tests in mozilla-central

Gijs Kruitbosch wrote on 09/01/2016 06:24 PM: > As I did over IRC, I would like to strongly object to the continued use > of per-test-type subfolders in our test directories. You can already use > a specific mach command per test type, and the tests are listed in > different manifests, *and*

NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION

Greetings, NS_WARN_IF_FALSE has been renamed NS_WARNING_ASSERTION. See https://bugzilla.mozilla.org/show_bug.cgi?id=1299727 for details, including the justification. See https://bugzilla.mozilla.org/show_bug.cgi?id=137 for a bug that this change exposed, thus adding weight to the

Re: Reorganization of Firefox-UI tests in mozilla-central

Matthew N. wrote on 09/02/2016 01:15 AM: >>> /browser/components/sessionstore/test/firefox_ui/ >>> * update tests:/toolkit/mozapps/update/tests/firefox_ui/ > > Is there a plan to merge those with > /toolkit/mozapps/update/tests/marionette? It seems unusual to use both > when this

Re: Reorganization of Firefox-UI tests in mozilla-central

On 02/09/2016 10:54, James Graham wrote: On 02/09/16 10:37, Gijs Kruitbosch wrote: On 02/09/2016 08:08, Henrik Skupin wrote: The problematic piece here will be the package-tests step which currently picks complete subfolders. It would mean if we mix-up tests for firefox-ui-tests and eg.

All profile settings lost in new version

I'm wondering, under what circumstances would a user have a prefs.js-1 and prefs.js be missing? ref https://support.mozilla.org/en-US/questions/1136992 ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Reorganization of Firefox-UI tests in mozilla-central

On 02/09/16 10:37, Gijs Kruitbosch wrote: On 02/09/2016 08:08, Henrik Skupin wrote: The problematic piece here will be the package-tests step which currently picks complete subfolders. It would mean if we mix-up tests for firefox-ui-tests and eg. mochitests all would end-up twice in the

Build System Project - Latest Update

Below is a highlight of all work the build peers have done since the last report[1]. The build peers have been working to get faster builds in automation as well as for local developers. We have landed changes to stop generating XPIDL sources in artifact builds[2], which is a performance and