799526 - Split the private browsing browser-chrome test suite into three buckets to make it easier to transition to per-window private browsing

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect)

Description

[(no longer active)]

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.

Comment 1

[(no longer active)]

Attachment: Patch (v1)

Comment 2

[(no longer active)]

Attachment: Patch (v1)

(The previous patch was not the squashed version...)

Comment 3

[Josh Matthews [:jdm]]

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.

Comment 4

[(no longer active)]

(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.

Comment 5

[(no longer active)]

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?

Comment 6

[Josh Matthews [:jdm]]

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.

Comment 7

[(no longer active)]

(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.)

Comment 8

[Josh Matthews [:jdm]]

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.

Comment 9

[(no longer active)]

(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.

Comment 10

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/cd5679486c7b

Comment 11

[Ed Morley [:emorley]]

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

Comment 12

[(no longer active)]

Relanded: https://hg.mozilla.org/integration/mozilla-inbound/rev/06eb83abf17f

Comment 13

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/06eb83abf17f