Closed Bug 1668809 Opened 1 year ago Closed 1 year ago

Disable some tests intermittently failing with sessionHistory and Fission

Categories

(Core :: DOM: Navigation, task, P3)

task

Tracking

()

RESOLVED FIXED
Fission Milestone M6c

People

(Reporter: smaug, Assigned: smaug)

References

Details

(Whiteboard: [stockwell disabled])

Attachments

(2 files)

No description provided.
Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6b89ff1b983e
Disable some intermittently failing tests, r=peterv
Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/304e15dfa979
Disabled browser_privilegedmozilla_process_pref.js on fission. a=test-only DONTBUILD CLOSED TREE

Olli, I disabled browser_privilegedmozilla_process_pref.js as well.

Flags: needinfo?(bugs)
Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/455ac1cc7e68
Disable intermittently fission failing browser_doorhanger_toggles.js. a=smaug-on-matrix CLOSED TREE
Pushed by ncsoregi@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/81146bda0b51
Disable more intermittently failing tests. CLOSED TREE
Severity: -- → N/A
Status: NEW → ASSIGNED
Type: defect → task
Fission Milestone: --- → M6b
Priority: -- → P3
See Also: → 1668970
See Also: → 1668971
Pushed by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/616d802acbd3
Update expectancy for location_reload.html. CLOSED TREE
Pushed by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6fbcad0b7d50
Update expectancy for location_reload.html CLOSED TREE
Pushed by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4f3c9c44c1f9
Update expectancy for navigation-in-onload.tentative.html
Keywords: leave-open
Whiteboard: [stockwell disabled]
Target Milestone: 83 Branch → ---
Status: RESOLVED → REOPENED
Keywords: leave-open
Resolution: FIXED → ---
Attachment #9179486 - Attachment description: Open Bug 1668809 - disable browser_new_tab_in_privilegedabout_process_pref.js on fission r=smaug → Bug 1668809 - disable test_bug385434.html and browser_new_tab_in_privilegedabout_process_pref.js on fission r=smaug
Fission Milestone: M6b → M6c
Attachment #9179486 - Attachment description: Bug 1668809 - disable test_bug385434.html and browser_new_tab_in_privilegedabout_process_pref.js on fission r=smaug → Bug 1668809 - disable test_bug385434.html and browser_new_tab_in_privilegedabout_process_pref.js on fission r=smaug DONTBUILD
Pushed by rmaries@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/38bb8344b1fe
disable test_bug385434.html and browser_new_tab_in_privilegedabout_process_pref.js on fission r=smaug DONTBUILD
Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Flags: needinfo?(bugs)
Keywords: leave-open
Resolution: --- → FIXED
Summary: Disable some intermittently failing tests → Disable some tests intermittently failing with sessionHistory
Summary: Disable some tests intermittently failing with sessionHistory → Disable some tests intermittently failing with sessionHistory and Fission

Tom, this browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js test is currently skipped on Fission with a comment saying: "Pref and test only relevant for e10s".

Is this test relevant for Fission? I don't know if "e10s" in this comment means to differentiate between "pre-e10s" or "pre-Fission". The browser.tabs.remote.separatePrivilegedMozillaWebContentProcess pref is currently enabled by default, with or without Fission.

[browser_new_tab_in_privilegedabout_process_pref.js]
skip-if = !e10s || (os == 'linux' && debug && bits == 64) || fission # Pref and test only relevant for e10s, Bug 1581500. Bug 1668809

https://searchfox.org/mozilla-central/rev/ef900cd2258d4c5d968093f612f807d96e6e7c98/browser/base/content/test/tabs/browser.ini#75-76

Flags: needinfo?(tom)

So the intent of the Privileged Mozilla Content Process (PMCP) is to put FXA and AMO into a separate content process and then reject certain capabilities if a content process requests them and it's not the PMCP. Patch 1 Patch 2.

With Fission we can change that check to say "You have to be a content process for FXA/AMO" and eliminate the notion of the PMCP - the only difference between a Content Process and a PMCP is the checks in those two patches.

The real question is does Fission work on those sites using those capabilities when the PMCP is enabled? Or does Fission mess up the notion of the PMCP. If those sites were broken I'm sure someone'd have noticed, so maybe the question is - do those sites go into Fission Content Processes with Fission or do they go into one PMCP and share a process? If they do, I don't think it's urgent that we fix it, but we should put a bug on file to clean this stuff up.

In conclusion, I think it is probably relevant for Fission because if the test fails it could indicate a way that FXA and AMO may fail with Fission.

Flags: needinfo?(tom)

(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #16)

With Fission we can change that check to say "You have to be a content process for FXA/AMO" and eliminate the notion of the PMCP - the only difference between a Content Process and a PMCP is the checks in those two patches.

The real question is does Fission work on those sites using those capabilities when the PMCP is enabled? Or does Fission mess up the notion of the PMCP. If those sites were broken I'm sure someone'd have noticed, so maybe the question is - do those sites go into Fission Content Processes with Fission or do they go into one PMCP and share a process? If they do, I don't think it's urgent that we fix it, but we should put a bug on file to clean this stuff up.

Nika, can you answer Tom's questions about Fission and PMCP?

I don't know if the browser_new_tab_in_privilegedabout_process_pref.js test currently passes with Fission or not. It's currently skipped for !e10s || fission.

Flags: needinfo?(nika)

This test is almost certainly failing for the same reason as some of the other tests like it, it is waiting for a process switch to happen using SSTabRestored here: https://searchfox.org/mozilla-central/rev/31ddf859c57e812878a5f817e4097efb06de4d97/browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js#169,185. This event never fires anymore, as we don't use sessionstore to perform process switches anymore. These can easily be fixed by just waiting for BrowserTestUtils.browserLoaded instead.

(In reply to Tom Ritter [:tjr] (ni? for response to sec-[advisories/bounties/ratings/cves]) from comment #16)

The real question is does Fission work on those sites using those capabilities when the PMCP is enabled? Or does Fission mess up the notion of the PMCP. If those sites were broken I'm sure someone'd have noticed, so maybe the question is - do those sites go into Fission Content Processes with Fission or do they go into one PMCP and share a process? If they do, I don't think it's urgent that we fix it, but we should put a bug on file to clean this stuff up.

They go into a single PMCP and share a process with fission. All special process allocations are not impacted with Fission, only loads which would've ended up in the web content process.

Flags: needinfo?(nika)
Depends on: 1686133

(In reply to Nika Layzell [:nika] (ni? for response) from comment #18)

This test is almost certainly failing for the same reason as some of the other tests like it, it is waiting for a process switch to happen using SSTabRestored here: https://searchfox.org/mozilla-central/rev/31ddf859c57e812878a5f817e4097efb06de4d97/browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js#169,185. This event never fires anymore, as we don't use sessionstore to perform process switches anymore. These can easily be fixed by just waiting for BrowserTestUtils.browserLoaded instead.

In that case, I filed new bug 1686133 to track fixing and re-enabling browser_new_tab_in_privilegedabout_process_pref.js test.

You need to log in before you can comment on or make changes to this bug.