2083975 - Notification bar created by RelaunchRequired enterprise policy is not replicated to Firefox windows created subsequently

Status: RESOLVED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[oneofthedamons]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:159.0) Gecko/20100101 Firefox/159.0

Steps to reproduce

1. Implemented the new RelaunchRequired enterprise policy
2. The 159b4 update was automatically applied in the background
3. Waited until the notification bar spawned due to the policy was shown: "A new version of Firefox is available. Your administrator will restart your browser at…"
4. Ignored the prompt to Update now and instead created a new window using File > New Window

Actual results

The notification bar is not shown on the new window.

Expected results

The notification bar should be shown on the new window so that the user continues to be prompted to Update now

Comment 2

[Mike Kaply [:mkaply]]

This isn't specific to RelaunchRequired: no universal infobar shows up in a window opened after the bar first appears.

When a new window opens, InfoBar gets a domwindowopened notification and calls _showWhenLoaded. That function shows the bar right away if the window's readyState is "complete", and otherwise waits for load. At domwindowopened the window still has its initial about:blank document, which already reports "complete". So _showWhenLoaded doesn't wait: it finds no tabbrowser yet and gives up without showing anything.

The other caller, showNotificationAllWindows, only calls _showWhenLoaded for windows that are still loading. So neither caller can reach the "show right away" branch with a window that is actually ready. Only tests reached it, by passing windows that were already loaded or faked as complete, which is why this wasn't caught.

The fix removes that branch so _showWhenLoaded always waits for load. It updates those two tests and adds a test that opens a real window and checks that the bar appears in it.

Comment 3

[Mike Kaply [:mkaply]]

Attachment: Bug 2083975 - Wait for load before showing a universal infobar in a new window. r?#omc-reviewers

Comment 4

[Mike Kaply [:mkaply]]

This also affects the Terms of Use infobar. The tou-experience-0 rollouts (US and non-US) ship tou-experience-0-white-infobar and tou-experience-0-blue-infobar as universal infobars, so they never appear in windows opened after the bar first shows. I confirmed it locally with the real tou-experience-0-white-infobar message: without this patch it shows in the original window but not in a new one; with the patch it shows in both.

Universal infobars have missed new windows since they were introduced in bug 1960078. At domwindowopened the window still has its initial about:blank document, which already reports readyState "complete", so the show-immediately branch ran before the browser document loaded. Originally that threw; later it returned silently.

Comment 5

[Mimi Jung]

thanks for catching this and for the fix. One small correction, Universal infobars did trigger in new windows, running mozregression it looks like it's been broken since 147:

 6:41.38 INFO: Last good revision: 37f1c536fdb89cd69039774a87f3ad8a94b95328
 6:41.38 INFO: First bad revision: 86c4f03a43058ea62f76021ad5a50e6199c34567
 6:41.38 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=37f1c536fdb89cd69039774a87f3ad8a94b95328&tochange=86c4f03a43058ea62f76021ad5a50e6199c34567

however, the "regressor" highlighted that the infobar code wasn't right about what complete meant

Comment 6

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 543435

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6850376f392e
https://hg.mozilla.org/integration/autoland/rev/81010ada3e05
Wait for load before showing a universal infobar in a new window. r=omc-reviewers,mimi

Comment 8

[Silaghi Andreea]

https://hg.mozilla.org/mozilla-central/rev/81010ada3e05

Comment 9

[BugBot [:suhaib / :marco]]

The patch landed in nightly and ESR is affected.

:mkaply, please make an uplift decision for ESR:

• For ESR, nominate the patch for the appropriate ESR uplift approval if the fix should be included in ESR, or set the ESR status flag(s) to wontfix if an uplift isn't needed. Each affected ESR release needs a decision.

Uplift requests can be submitted from Lando: D336938.

See Requesting an Uplift for documentation on how to request an uplift.

For more information, please visit BugBot documentation.

Comment 10

[Phabricator Automation]

firefox-esr153 Uplift Approval Request

• User impact if declined/Reason for urgency: Infobar for TOS and forced update doesn't show in all windows.

Regression

• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Actually makes the code more reliable
• String changes made/needed?: None
• Is Android affected?: no

Comment 11

[Mike Kaply [:mkaply]]

Attachment: Bug 2083975 - Wait for load before showing a universal infobar in a new window.

Original Revision: https://phabricator.services.mozilla.com/D336938

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr153/rev/24380bf8ae3e