Closed Bug 799526 Opened 7 years ago Closed 7 years ago
Split the private browsing browser-chrome test suite into three buckets to make it easier to transition to per-window private browsing
Here's the global: split the test suite into three chunks: * obsolete: tests that test weird global PB interactions and can just be dropped when we switch to pbngen. * global: tests that test things that would be relevant to the world of per-window PB as well as global PB. We should port these to the per-window APIs. * perwindow: tests that only test things that would be relevant to the per-window PB world.
Assignee: nobody → ehsan
Status: NEW → ASSIGNED
Attachment #669569 - Flags: review?(josh)
(The previous patch was not the squashed version...)
I'm not thrilled that we don't run the per-window tests in non-per-window configurations. I really want to be sure that those keep passing.
(In reply to comment #3) > I'm not thrilled that we don't run the per-window tests in non-per-window > configurations. I really want to be sure that those keep passing. They will be tested on the birch branch.
A bit more about the reasoning behind this. I don't want to expose per-window APIs in regular builds just yet, to make sure that people don't pick it up and build stuff on top of it before we're ready. We'll still land all of the fixes on central and I'll setup continuous builds on the birch branch. Later on when we're close to ready, we can look into just hiding the UI behind a pref and enabling the tests and APIs on central. Does this make sense?
I would still rather have tests that break when other people land patches, rather than tests that break when we merge batches of changes into birch. There's no downside to running the per-window tests right now that I can see, so I don't understand why we shouldn't do so.
(In reply to comment #6) > I would still rather have tests that break when other people land patches, > rather than tests that break when we merge batches of changes into birch. > There's no downside to running the per-window tests right now that I can see, > so I don't understand why we shouldn't do so. Well, like I said, the only downside with doing that would be that we need to expose the API added in bug 798508 to regular builds. Do you think that's acceptable? (I don't feel totally strongly about that, so you might be able to convince me if you have a good reason.)
Ah. I was considering the existing tests that don't need that API. As long as we'll be regularly updating birch, I'm ok with this.
(In reply to comment #8) > Ah. I was considering the existing tests that don't need that API. As long as > we'll be regularly updating birch, I'm ok with this. Yep, I'll be setting up a cron script which does that twice a day initially to keep the load reasonable. In my experience with maintaining similar branches before, that is usually frequent enough to find problems with a quick bisection after they show up on Birch.
Target Milestone: --- → Firefox 19
Push backed out for causing frequent failures in browser_bug400731.js on debug mochitest-other (primarily OS X 10.6, but occurred on other platforms too): eg https://tbpl.mozilla.org/php/getParsedLog.php?id=16010390&tree=Mozilla-Inbound To see retriggers use: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=de6c6589ebe4&jobname=Rev4%20MacOSX%20Snow%20Leopard%2010.6%20mozilla-inbound%20debug%20test%20mochitest-other (and press down to see the relevant range) Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/48557b9d07f2
Target Milestone: Firefox 19 → ---
Target Milestone: --- → Firefox 19
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.