1594162 - Blank tabs are shown after Firefox updated to version 71.0b7

Status: VERIFIED FIXED

(Firefox :: Session Restore, defect, P1)

Description

[Pablo]

[Description:]

Blank tabs are shown after Firefox updated to version 71.0b7
From version 50.0b2 (zh-CN ) to 56.0b3 it is ok
from version 56.0b3 (zh-CN) to 71.0b7 it shows 2 blank tabs.

[Steps to reproduce:]

• Install FF Beta 50.0b2 (zh-CN localization) with new profile http://releases.mozilla.org/pub/firefox/candidates/50.0b2-candidates/build1/win64/zh-CN/
• Update version by going into hamburger menu - Help
• after Firefox updates to 56.0b3 , restart it
• Notice 2 tabs are open with information
• Update firefox again to 71.0b7 by going to hamburger menu - Help
• after Firefox updates to 71.0b7 restart it.

[Actual results]:
Previously open tabs are now showing all white, without data

[Expected results:]
Open tabs Should show data after restart

NOTE:
the links on those 2 tabs are:

https://support.mozilla.org/zh-CN/kb/how-change-your-default-browser-windows-10?utm_source=firefox-browser&utm_medium=firefox-browser&utm_campaign=redirect&utm_content=windows10-welcome-tab

https://start.firefoxchina.cn

by clicking on those links and hitting [enter key] the information appears on the screen.

On MacOs & Ubuntu: Only the tab with https://start.firefoxchina.cn showed empty.

TESTED ON:

Windows 10 64bit updating 50.0b2 (zh-CN localization) to latest version
Ubuntu 18.04 64bit updating 50.0b2 (zh-CN localization) to latest version
MacOS 10.14 updating 50.0b2 (zh-CN localization) to latest version

Comment 1

[Pablo]

Attachment: bugupdate1.jpg

Comment 2

[Molly Howell (she/her) (mostly inactive)]

Does this happen again if you restart the browser after updating it, or does the bug only reproduce on the restart that applies the update?

Comment 3

[Pablo]

Hi Molly
I saw 2 things.

1. 50.0b2 (zh-CN ) to 56.0b3 (zh-CN) to 71.0b7
   If i restart the browser one more time as you asked, i see the https://start.firefoxchina.cn/ tab only and i see the site properly

but

2. 50.0b2 (zh-CN ) to 56.0b3 (zh-CN) to 71.0b7 + enable restore previous session in about:preferences when its on 71.0b7.
   If i restart the browser one more time at the end of the process, both tabs ares still blank

regards
Pablo

Comment 4

[Molly Howell (she/her) (mostly inactive)]

Okay, thanks for checking that. It sounds like something is going on with the session restore, not the update itself.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:mikedeboer, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Pablo, any chance you could help run mozregression tool to find which commit fixed this issue in 72? Thank you.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #6)

Hi Pablo, any chance you could help run mozregression tool to find which commit fixed this issue in 72? Thank you.

I overlooked the comment and got something wrong. Sorry!

Comment 9

[Pascal Chevrel:pascalc]

Wontfix 71 and untracking as this looks like an edge case and we are in RC week, even if an investigation was successful and a fix were found, it would be too late for the release.

Comment 10

[Alphan Chen [:alchen]]

Attachment: Nov26-Bug 1594162

I tried to reproduce the symptom on several platforms.
I can reproduce it on Win-10 32 bit in the virtalbox.

Here is the log from BrowserConsole.

Only the following error is from session restore component.
"Attempt to set a remote URL https://... as a tab icon without a loading principal."
This error only causes the icon is not set.
It is what we see in attachment 9106686 [details].
There is no icon on the left side of the tab.
Also, it won't stop restoring.

We may also want someone to take a look at other errors and exceptions in this case.

Comment 11

[Alphan Chen [:alchen]]

If QA can reproduce the symptom, please also attach the related log for investigating.
Thanks.

Comment 12

[Alphan Chen [:alchen]]

I load my reproduced sessionStore file in my local build and found that it is similar to bug 1500114.
The symptom is almost the same.
For my sessionStore file, the sessionHistory entry we want to restore doesn't have a "triggering principal".

Here we update FF from Beta 50.0b2 to 56.0b3. Then from 56.0b3. to 71.0b7.

Comment 13

[Alphan Chen [:alchen]]

I think it is a regression of bug 1521878.
By STR, the sessionStore we collect is from Beta 50.0b2 or 56.0b3.
There is a possibility that there is no "entry.triggeringPrincipal_base64".
In this case, we should assign a null principal to shEntry.triggeringPrincipal.

We have this logic before bug 1521878.

[Now]
https://searchfox.org/mozilla-central/rev/cce8b90aece0f42e5025e45282de16066eeaa662/toolkit/modules/sessionstore/SessionHistory.jsm#514

[before bug 1521878]
if (entry.triggeringPrincipal_base64) {
shEntry.triggeringPrincipal = E10SUtils.deserializePrincipal(entry.triggeringPrincipal_base64);
}
// Ensure that we have a null principal if we couldn't deserialize it.
// This won't always work however is safe to use.
if (!shEntry.triggeringPrincipal) {
debug("Couldn't deserialize the triggeringPrincipal, falling back to NullPrincipal");
shEntry.triggeringPrincipal = Services.scriptSecurityManager.createNullPrincipal({});
}

Comment 14

[Alphan Chen [:alchen]]

(In reply to Alphan Chen [:alchen] from comment #13)

[before bug 1521878]
if (entry.triggeringPrincipal_base64) {
shEntry.triggeringPrincipal = E10SUtils.deserializePrincipal(entry.triggeringPrincipal_base64);
}
// Ensure that we have a null principal if we couldn't deserialize it.
// This won't always work however is safe to use.
if (!shEntry.triggeringPrincipal) {
debug("Couldn't deserialize the triggeringPrincipal, falling back to NullPrincipal");
shEntry.triggeringPrincipal = Services.scriptSecurityManager.createNullPrincipal({});
}

By the way, I've verified my sessionStore with the original logic.
The tab works normally.

Comment 15

[:Gijs (out for now; he/him)]

Is 72 actually not affected (which is what the status flag says) ?

Comment 16

[Jonathan Kingston [:jkt] he/him]

Attachment: Bug 1594162 - Fix missing triggering principal from session restore. r?Gijs

Comment 17

[Alphan Chen [:alchen]]

(In reply to :Gijs (he/him) from comment #15)

Is 72 actually not affected (which is what the status flag says) ?

I would say it is also affected.

Comment 18

[Jonathan Kingston [:jkt] he/him]

You are right that if condition shouldn't have ever been there. Checking in try, it's probably safe enough for an uplift also.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:mikedeboer, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

:jkt, since this bug is a regression, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.

Comment 21

[Jonathan Kingston [:jkt] he/him]

Did you see my comment in Phab?

Comment 22

[:Gijs (out for now; he/him)]

I responded on phab.

Comment 23

[Jonathan Kingston [:jkt] he/him]

We may wish to uplift this patch as it shouldn't have any adverse impacts and reduces the chance of unrestorable tabs.

Comment 24

[:Gijs (out for now; he/him)]

(In reply to Jonathan Kingston [:jkt] from comment #23)

We may wish to uplift this patch as it shouldn't have any adverse impacts and reduces the chance of unrestorable tabs.

I think if you land on nightly now, it'll be in 73; 72 has already had RC's spun. I don't think this issue (restoring from really old versions of Firefox) is common enough to warrant spinning another RC. Also, 72 is actually marked unaffected, though I have no idea why that is...

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2b6c32f8991e
Fix missing triggering principal from session restore. r=Gijs

Comment 26

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/2b6c32f8991e

Comment 27

[Pablo]

Retested issue on Firefox Release, Beta , and Nightly
Using windows 10 64bit, Ubuntu 18.04 64bit and MacOs 10.14

Release:
Installed version 49 (zh-CN ) then updated to version 56, then updated to version 71 (showed blank tabs)> then updated to version 72 (showed blank tabs)

Beta:
Installed 50.0b2 (zh-CN ) > updated to 56.0b3 > then updated to v72 beta and shows blank tabs . Then updated to> 73.0b1 beta and shows tabs correctly.

Nightly:
Installed 51.0a1 (zh-CN ) then updated to> 56.0a1 > then updated to 74.0a1 : all tabs were always visible.