1548508 - Gmail in a pinned tab fails to load on browser startup

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect, P1)

Description

[Sören Hentzschel]

Attachment: screenshot.png

+++ This bug was initially created as a clone of Bug #1510619 +++

According to #1510619 it should be fixed but I still have the issue after every Firefox Nightly update (macOS 10.11.6)

STR:

1. have Google Mail as pinned tab
2. wait for a Firefox update
3. use the "restart Firefox to apply updates" buttons in the main menu to restart Firefox
4. open the Google Mail tab

Expected:

You should see your inbox.

Actual:

White page, see attached screenshot. Also note the low quality favicon.

Comment 1

[Gabriela [:gaby2300]]

I can reproduce using Windows 7 64 bit and the latest nightly. It happens always with or without update.

Comment 2

[:Gijs (he/him)]

Any errors in the browser console? Does it work in safe mode?

Comment 3

[Gabriela [:gaby2300]]

It doesn't happen in Safe Mode, nor when I enable the addons again.

Comment 4

[Jim Mathies [:jimm]]

Hey all, I've seen this twice over the last few days: after a cold startup, opening the browser early after login, wait for all my tabs to load. Didn't see this for a few weeks but now it seems to be back. Probably just random luck I didn't get it for a while there.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Gabriela [:gaby2300] from comment #1)

I can reproduce using Windows 7 64 bit and the latest nightly. It happens
always with or without update.

Same os for me as well. I have not seen this on Windows 10.

Comment 6

[:Gijs (he/him)]

Andrew said "that specific type of issue could be quickly assigned to the addons team if a particular bug is not reproducible in safe mode", so pinging them here...

Comment 7

[Andrew Swan [:aswan]]

Gabriela, which extensions do you have installed? (if its easier, you can paste the about:support contents into an attachment here)

Comment 8

[Gabriela [:gaby2300]]

(In reply to Andrew Swan [:aswan] from comment #7)

Gabriela, which extensions do you have installed? (if its easier, you can paste the about:support contents into an attachment here)

I have Firefox Color and Pontoon Tools.

Comment 9

[Andrew Swan [:aswan]]

(In reply to Gabriela [:gaby2300] from comment #3)

It doesn't happen in Safe Mode, nor when I enable the addons again.

I missed this comment the first time around, but I'm not sure I understand it. Does this mean that if you disable and re-enable your extensions then the next startup is okay?

Can you paste the contents from the browser console during a browser startup where your tab fails to load?

Comment 10

[Jim Mathies [:jimm]]

(In reply to Andrew Swan [:aswan] from comment #9)

(In reply to Gabriela [:gaby2300] from comment #3)

It doesn't happen in Safe Mode, nor when I enable the addons again.

I missed this comment the first time around, but I'm not sure I understand
it. Does this mean that if you disable and re-enable your extensions then
the next startup is okay?

Can you paste the contents from the browser console during a browser startup
where your tab fails to load?

Next time I see this I'll grab whatever I can and post.

Comment 11

[Gabriela [:gaby2300]]

I'm very sorry for my delay, I had some family health issues to deal with.

Here are the contents from the browser console during a browser start up where my Gmail tab fails to load.

The first four entries are when the tab fails to load. The following ones are after reloading the tab.

Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: La configuración de la página bloqueó la carga de un recurso en inline ("script-src"). 0:166:298
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando ‘x-frame-options’ por la directiva ‘frame-ancestors’.
Content Security Policy: Ignorando "'unsafe-inline'" dentro de script-src o style-src: se especificó nonce-source o hash-source
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
El uso de Mutation Event es obsoleto. Use MutationObserver en su lugar. m=sm:271:180
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado

​

Comment 12

[Gabriela [:gaby2300]]

(In reply to Jim Mathies [:jimm] from comment #10)

(In reply to Andrew Swan [:aswan] from comment #9)

(In reply to Gabriela [:gaby2300] from comment #3)

It doesn't happen in Safe Mode, nor when I enable the addons again.

I missed this comment the first time around, but I'm not sure I understand
it. Does this mean that if you disable and re-enable your extensions then
the next startup is okay?

Yes, I mean just that!

Comment 13

[Gabriela [:gaby2300]]

Hello @Jim and Andrew! I answered your questions around 2 months ago, I would greatly appreciate your comment as I still see the issue! Thanks!

Comment 14

[:Gijs (he/him)]

Rob, any ideas as to how disabling/enabling add-ons as per comment #12 could be influencing session store here?

Comment 15

[Rob Wu [:robwu]]

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

Rob, any ideas as to how disabling/enabling add-ons as per comment #12 could be influencing session store here?

There are two different startup paths for an extension's background page.

If a browser is just starting up AND extensions.webextensions.background-delayed-startup is true (this is the default), then the background page is delayed until (1) sessionstore-windows-restored" has triggered, or (2) a primed event listener is triggered (=event listener persisted from a previous extension run). Otherwise, the background page is immediately started. Relevant code: https://searchfox.org/mozilla-central/rev/3366c3d24f1c3818df37ec0818833bf085e41a53/toolkit/components/extensions/parent/ext-backgroundPage.js#130-159

When the code path at (2) is triggered, the webRequest module will suspend any request until the background page has loaded. Our implementation should eventually clear persistent listeners to resume the request. In bug 1535674, a potential race was identified and fixed by immediately ignoring persistent events once clearPrimedListeners is called. That logic relies on the assumption that clearPrimedListeners is always be called.

Primed listeners are cleared when an event listener is registered again by the background page, or:

• Background page has fully loaded - https://searchfox.org/mozilla-central/rev/3366c3d24f1c3818df37ec0818833bf085e41a53/toolkit/components/extensions/parent/ext-backgroundPage.js#90
• Extension startup is being interrupted before the background page has started to load at all - https://searchfox.org/mozilla-central/rev/3366c3d24f1c3818df37ec0818833bf085e41a53/toolkit/components/extensions/parent/ext-backgroundPage.js#166

In theory, clearPrimedListeners would not be called if:

• Extension shut down before background page finished loading - https://searchfox.org/mozilla-central/rev/3366c3d24f1c3818df37ec0818833bf085e41a53/toolkit/components/extensions/parent/ext-backgroundPage.js#74
• Somehow one of the promises in context.listenerPromises rejected - https://searchfox.org/mozilla-central/rev/3366c3d24f1c3818df37ec0818833bf085e41a53/toolkit/components/extensions/parent/ext-backgroundPage.js#82

Another potential way for webRequest listeners to get stuck is when wakeup() is called in ext-webRequest.js, which in its turn is blocked on background page startup. If the background page startup is prematurely interrupted (which could theoretically happen at any of those lines, then wakeup() would never resolve.

The potential races that I identified need to be fixed, but they would only cause issues if extension startup is interrupted (e.g. when an extension that uses the webRequest API is unloaded/reloaded/updated on browser startup).
Out of the add-ons in comment 8, only the Pontoon Tools add-on uses webRequest. It does not have frequent updates, and neither contains forced reload logic in the add-on, so reloading/updating is not likely the trigger of the bug. That reduces the potential triggers to disabling - is it possible that (all) add-ons are disabled at browser startup (maybe as part of add-on manager shutdown and startup after a browser update)?

Comment 16

[Rob Wu [:robwu]]

Attachment: Bug 1548508 - Ensure that primed event listeners are eventually unregistered

Depends on D42670

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4a697b4bd644
Ensure that primed event listeners are eventually unregistered r=mixedpuppy

Comment 19

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/4a697b4bd644

Comment 20

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

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Comment 21

[Rob Wu [:robwu]]

Comment on attachment 9086707 [details]
Bug 1548508 - Ensure that primed event listeners are eventually unregistered

Beta/Release Uplift Approval Request

• User impact if declined: On startup, (pinned) tabs are sometimes not loading because network requests are suspended indefinitely. This only affects users who have installed extensions that use the webRequest extension API (e.g. ad blockers).

The bug is caused by a race condition, which appeared to occur more frequently when bug 1495072 landed. The issue was resolved in 68 by putting the feature behind a pref (https://bugzilla.mozilla.org/show_bug.cgi?id=1534806#c12).
In bug 1546145, the feature was re-enabled in Firefox 69, because bug 1535674 was expected to fix the original issue.
That fix turned out to be insufficient, and this patch is expected to fix the issue for real.

Since bug 1546145 has enabled the feature in 69, I'd like to land this patch in 69 too.

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See bug comment 0 and comment 1. This is a race condition, so it is possible that the issue is not easily reproducible.

I consider this bug verified if any of the people who were originally able to reproduce the bug can confirm that the issue doesn't occur any more in their setup.

• List of other uplifts needed: Bug 1575190
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The patch is small, well-understood and fully covered by unit tests.

The non-test parts of the patch are:

1. undo parts of the incomplete fix from bug 1535674.
2. resolve two potential deadlocks when an extension unexpectedly unloads during startup.

• String changes made/needed: none

Comment 22

[Rob Wu [:robwu]]

Comment on attachment 9087820 [details] [diff] [review]
Update

(this was spam)

Comment 23

[Julien Cristau [:jcristau]]

Comment on attachment 9086707 [details]
Bug 1548508 - Ensure that primed event listeners are eventually unregistered

we're in RC week, 69 is on mozilla-release.

Comment 24

[Sören Hentzschel]

(In reply to Rob Wu [:robwu] from comment #21)

I consider this bug verified if any of the people who were originally able to reproduce the bug can confirm that the issue doesn't occur any more in their setup.

I updated Firefox Nightly to today's build which should have this fix according to the revision in about:buildconfig. But Gmail in my pinned tab still failed to load directly after the update restart.

Comment 25

[Rob Wu [:robwu]]

To see if your problem is related to my fix at all, could you visit about:config , set extensions.webextensions.background-delayed-startup to false and try to reproduce?

If it still reproduces, then your problem is unrelated to what I described in comment 15.
If it does not reproduce, then the problem might be related to what I described in comment 15. An alternative explanation is that the overhead of loading the extensions immediately (instead of delaying it) could affect the timing characteristics that lead to your observed issue.

Comment 26

[Sören Hentzschel]

With extensions.webextensions.background-delayed-startup set to false it happened again after updating Firefox.

Comment 27

[Rob Wu [:robwu]]

Comment on attachment 9086707 [details]
Bug 1548508 - Ensure that primed event listeners are eventually unregistered

Canceling uplift request; this patch did not fix the bug.

Comment 28

[Gabriela [:gaby2300]]

WFM after setting extensions.webextensions.background-delayed-startup to false, at least using today's Nightly build:
Version: 70.0a1; ID Build 20190829094151; Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

Comment 29

[Rob Wu [:robwu]]

(In reply to Gabriela [:gaby2300] from comment #28)

WFM after setting extensions.webextensions.background-delayed-startup to false, at least using today's Nightly build:
Version: 70.0a1; ID Build 20190829094151; Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0

And if you set the pref to true, does the bug re-appear? If that is the case, then my patch would at least solve some of the reported issues (well, in theory it should definitely solve some of the issues, but I am not sure whether it is the issue that you experience in practice).

Comment 30

[Gabriela [:gaby2300]]

Resetting the pref to true, the bug does not reapear. I tried 2 times with the same result. Will try again later. Should the bug reapear in a while, tomorrow or even later, I'll add a new comment here.

Comment 31

[Gabriela [:gaby2300]]

Tried again today, 3 times in a row with the pref set to true. The bug did not re-appear.

Comment 32

[Gabriela [:gaby2300]]

It seems the change of true to false and back again works (the bug doesn't appear) when I restart the browser several times in a row.
I doesn't work at cold start up (when I start my PC).
I mean the following: when I started my PC today, the pref was set to true and the bug appeared. If I then set it to false, it doesn't and the same if I reset it several times.

Comment 33

[Rob Wu [:robwu]]

(In reply to Gabriela [:gaby2300] from comment #32)

I mean the following: when I started my PC today, the pref was set to true and the bug appeared.

Now, to see if this bug is related to the delayed background load (and persistent listeners), could you set the flag to false, and report whether the bug happens? (and if reproduced, please take a look at the global JS console and include log messages in your comment, if you see any).

Comment 34

[Gabriela [:gaby2300]]

Will do, sure!

Comment 35

[Gabriela [:gaby2300]]

The bug appeared when I started my PC just now, with the pref set to false.

Please tell me how to proceed to look at the global JS console and see and copy log messages.

Comment 36

[Rob Wu [:robwu]]

Ctrl-Shift-J
More info: https://developer.mozilla.org/en-US/docs/Tools/Browser_Console#Opening_the_Browser_Console

Could you also state your Firefox version? Today a version bump on Nightly occurred, from 70.0a1 to 71.0a1 buildID .....

Comment 37

[Gabriela [:gaby2300]]

Version 71.0a1, Build ID: 20190902094857, Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0

BadContentError: "C:\Users\Gabriela\AppData\Local\Mozilla\Firefox\Profiles\og3a7xhx.Rapido-1564614516624\settings\main\public-suffix-list\dafsa.bin content does not match server hash"
BadContentError resource://services-settings/Attachments.jsm:29
download resource://services-settings/Attachments.jsm:86
init resource://gre/modules/netwerk-dns/PublicSuffixList.jsm:29
promise callback*init resource://gre/modules/netwerk-dns/PublicSuffixList.jsm:27
_scheduleArbitrarilyLateIdleTasks resource:///modules/BrowserGlue.jsm:2184
PublicSuffixList.jsm:34:29
Error de seguridad: El contenido en chrome://browser/skin/browser.css no puede cargar o enlazar a moz-extension://bb4b72a7-108c-4942-8677-cde7797771fb/moz3.header.jpg.
Content Security Policy: Ignorando “'unsafe-inline'” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “https:” dentro de script-src: ‘strict-dynamic’ especificado
Content Security Policy: Ignorando “http:” dentro de script-src: ‘strict-dynamic’ especificado
Error de seguridad: El contenido en https://developer.mozilla.org/en-US/docs/Tools/Browser_Console#Opening_the_Browser_Console no puede cargar o enlazar a moz-extension://836ae48a-7d79-4811-a163-3244886ae115/packages/commons/img/pontoon-logo.svg.
Error de seguridad: El contenido en https://developer.mozilla.org/en-US/docs/Tools/Browser_Console#Opening_the_Browser_Console no puede cargar o enlazar a moz-extension://836ae48a-7d79-4811-a163-3244886ae115/packages/commons/img/bugzilla-icon.png.
Error de seguridad: El contenido en chrome://browser/skin/browser.css no puede cargar o enlazar a moz-extension://bb4b72a7-108c-4942-8677-cde7797771fb/moz3.header.jpg.
getScreenshot(https://developer.mozilla.org/static/img/opengraph-logo.72382e605ce3.png) failed: Error: page-thumbnail:error Screenshots.jsm:59
Error de seguridad: El contenido en chrome://browser/skin/browser.css no puede cargar o enlazar a moz-extension://bb4b72a7-108c-4942-8677-cde7797771fb/moz3.header.jpg.
Content Security Policy: Ignorando "'unsafe-inline'" dentro de script-src o style-src: se especificó nonce-source o hash-source 2
Content Security Policy: Ignorando ‘x-frame-options’ por la directiva ‘frame-ancestors’.
Exception { name: "NS_ERROR_NOT_AVAILABLE", message: "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsICacheInfoChannel.isRacing]", result: 2147746065, filename: "resource://devtools/server/actors/network-monitor/network-response-listener.js", lineNumber: 335, columnNumber: 0, data: null, stack: "NetworkResponseListener.prototype._getSecurityInfo<@resource://devtools/server/actors/network-monitor/network-response-listener.js:335:26\nexports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:111:22\nonStartRequest@resource://devtools/server/actors/network-monitor/network-response-listener.js:224:10\n", location: XPCWrappedNative_NoHelper }
ThreadSafeDevToolsUtils.js:90:13

Comment 38

[Rob Wu [:robwu]]

(In reply to Gabriela [:gaby2300] from comment #35)

The bug appeared when I started my PC just now, with the pref set to false.

This proves that the issue that you are experiencing is unrelated to persistent listeners.
And nothing in the log from comment 37 stands out.

I'm not sure if this issue is related to extensions at all.
You mentioned that only Firefox Color and Pontoon Tools were enabled.

Could you disable Pontoon Tools, and check if the issue disappears?
If it does not disappear, could you also disable Firefox Color?

Comment 39

[Gabriela [:gaby2300]]

(In reply to Rob Wu [:robwu] from comment #38)

(In reply to Gabriela [:gaby2300] from comment #35)

The bug appeared when I started my PC just now, with the pref set to false.

This proves that the issue that you are experiencing is unrelated to persistent listeners.
And nothing in the log from comment 37 stands out.

I'm not sure if this issue is related to extensions at all.
You mentioned that only Firefox Color and Pontoon Tools were enabled.

Could you disable Pontoon Tools, and check if the issue disappears?
If it does not disappear, could you also disable Firefox Color?

Will do!
Just a question: disable the addons with the pref set to true, false or try with both?

Comment 40

[Rob Wu [:robwu]]

(In reply to Gabriela [:gaby2300] from comment #39)

(In reply to Rob Wu [:robwu] from comment #38)

Could you disable Pontoon Tools, and check if the issue disappears?
If it does not disappear, could you also disable Firefox Color?

Will do!
Just a question: disable the addons with the pref set to true, false or try with both?

It shouldn't matter, but to simplify the scenario, set it to false.
Given the information below, I suggest to first try with all add-ons disabled.
Could you also describe the circumstances in which the problem occurs? For example, was the system idle or busy when you started Firefox? Did you already have a stable network connection when you started Firefox?

For the record: A different user shared the following information with me:

I tested with extensions.webextensions.background-delayed-startup set to false and to true, it happened after the update in both cases. It also happened with all add-ons disabled.

I don't know if these differences are relevant but there are two differences between my computer at work (where I can reproduce the bug) and at home (where I can't reproduce the bug).

My home computer runs with macOS 10.15 Beta and can be used very shortly after the update. My computer at work runs with macOS 10.11 and after a update it needs at least one minute until Firefox can open any website. So maybe it's only an issue with slow systems?

This suggests that the issue may be unrelated to add-ons.

Comment 41

[Gabriela [:gaby2300]]

(In reply to Rob Wu [:robwu] from comment #40)

(In reply to Gabriela [:gaby2300] from comment #39)

(In reply to Rob Wu [:robwu] from comment #38)

Could you disable Pontoon Tools, and check if the issue disappears?
If it does not disappear, could you also disable Firefox Color?

Will do!
Just a question: disable the addons with the pref set to true, false or try with both?

It shouldn't matter, but to simplify the scenario, set it to false.
Given the information below, I suggest to first try with all add-ons disabled.
Could you also describe the circumstances in which the problem occurs? For example, was the system idle or busy when you started Firefox? Did you already have a stable network connection when you started Firefox?

All addons disabled, pref set to false, I still see the bug.

My network is always stable and the bug is there whether the system is idle or busy.

Comment 42

[Rob Wu [:robwu]]

Thanks for the confirmation. There are two reports of this being unrelated to extensions, and jimm also mentioned that he's still observing this bug despite my patch.

The issue seems therefore unrelated to webRequest, and WebExtensions in general.

Gijs, could you investigate this? So far :gaby2300 has been very willing to help with debugging.

Comment 43

[:Gijs (he/him)]

(In reply to Rob Wu [:robwu] from comment #42)

Gijs, could you investigate this? So far :gaby2300 has been very willing to help with debugging.

I don't really have cycles, esp. this month, and I don't know the session store code very well. Maybe Barret has ideas here based on his work to move webnavigation / web progress into C++; it'd be helpful if we at least understood what part of the load was not happening and why. Maybe there's moz_log syntax that can help with this from the docshell side, or something.

bug 1554979 is on file on making this type of thing easier to debug, perhaps that needs prioritizing - Mike?

Comment 44

[Beth Rennie [:beth] (she/her)]

I also don't have cycles this month and I also don't know session store at all. My work with WebProgress really didn't touch it at all.

Comment 45

[:Gijs (he/him)]

Looks like Alphan has been doing some sessionstore work in bug 1549975, so perhaps they can help?

Comment 46

[Alphan Chen [:alchen]]

I tried to reproduce the symptom on Ubuntu and macOS, but failed.

(In reply to Gabriela [:gaby2300] from comment #1)

I can reproduce using Windows 7 64 bit and the latest nightly. It happens always with or without update.

If you still can reproduce the symptom consistently, could you use "duplicate tab" to duplicate the pinned tab(gmail)?
It is a way to force a session restore on a new tab.
Also, if gmail is not a pinned tab, do you still see the same symptom?

Comment 47

[Alphan Chen [:alchen]]

Attachment: how to duplicate tab

You can see the menu when using the mouse right-click on the tab.

Comment 48

[Gabriela [:gaby2300]]

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

I tried to reproduce the symptom on Ubuntu and macOS, but failed.

(In reply to Gabriela [:gaby2300] from comment #1)

I can reproduce using Windows 7 64 bit and the latest nightly. It happens always with or without update.

If you still can reproduce the symptom consistently, could you use "duplicate tab" to duplicate the pinned tab(gmail)?
It is a way to force a session restore on a new tab.
Also, if gmail is not a pinned tab, do you still see the same symptom?

I can still reproduce the bug.

No problem to duplicate the tab, it loaded as expected. The unpinned tab showed the bug though.

Comment 49

[Alphan Chen [:alchen]]

No problem to duplicate the tab, it loaded as expected. The unpinned tab showed the bug though.

Do you mean the new tab(the duplicated tab) is a white page?

Comment 50

[Sören Hentzschel]

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

If you still can reproduce the symptom consistently, could you use "duplicate tab" to duplicate the pinned tab(gmail)?

If I duplicate the pinned Gmail tab with the white page Gmail loads without any problems in the duplicated tab.

Also, if gmail is not a pinned tab, do you still see the same symptom?

No, this works without any problems but that's probably expected because Firefox only restores pinned tabs on restart. The unpinned tab will not be restored until I select the tab.

Comment 51

[Gabriela [:gaby2300]]

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

No problem to duplicate the tab, it loaded as expected. The unpinned tab showed the bug though.

Do you mean the new tab(the duplicated tab) is a white page?

No, the new (duplicated) tab loads as expected. The unpinned one is a white page and does not load when I select it as it should.

Comment 52

[Gabriela [:gaby2300]]

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

No problem to duplicate the tab, it loaded as expected. The unpinned tab showed the bug though.

Do you mean the new tab(the duplicated tab) is a white page?

No, the new (duplicated) tab loads as expected. The unpinned one is a white page and does not load when I select it as it should according to the expected behavior.

Comment 53

[Ryan VanderMeulen (PTO, back July 27)]

Whatever's going on here appears to be edge-case enough that we don't need to keep this on the Fx69 dot release radar. Let's keep the investigation moving with hopes of getting something landed for Fx70.

Comment 54

[Liz Henry (:lizzard)]

Andrei can you help find someone to look for consistent STR?
Alphan, any ideas? I'm not sure what else we can do here. If we aren't seeing a lot of duplicate reports it might really be an edge case.

Comment 55

[Andrei Vaida [:avaida]]

(In reply to Liz Henry (:lizzard) from comment #54)

Andrei can you help find someone to look for consistent STR?
Alphan, any ideas? I'm not sure what else we can do here. If we aren't seeing a lot of duplicate reports it might really be an edge case.

Cristian started looking into this, he'll follow up as soon as possible.

Comment 56

[Alphan Chen [:alchen]]

(In reply to Liz Henry (:lizzard) from comment #54)

Alphan, any ideas? I'm not sure what else we can do here. If we aren't seeing a lot of duplicate reports it might really be an edge case.
Just back from PTO.
No, I think it is not the problem of session restore itself.
"duplicate tab" can be considered a unit test of session restore.
From the result, I will think it depends on how or when to do the pinned restore.

Comment 57

[Cristian Fogel [:cfogel]]

No success with this either in trying to reproduce.
Only thing worth mentioning is that for Gmail the load timers where longer than on other websites.
For a more detailed report you can check this gdoc.

Comment 58

[Gabriela [:gaby2300]]

(In reply to Cristian Fogel, QA [:cfogel] from comment #57)

For a more detailed report you can check this gdoc.

This gdoc requires permission to access. I would appreciate if you could please give me access as I actually have this issue and I added several comments here.

Comment 59

[Cristian Fogel [:cfogel]]

(In reply to Gabriela [:gaby2300] from comment #58)

(In reply to Cristian Fogel, QA [:cfogel] from comment #57)

This gdoc requires permission to access. I would appreciate if you could please give me access as I actually have this issue and I added several comments here.

Done.

Prepared a section for you at the start of the document.
Anything that would help regarding the issue or the summary should still be posted on this thread for transparency.
Also, thanks again for still willing to help with debugging this issue!

Comment 60

[Gabriela [:gaby2300]]

(In reply to Cristian Fogel, QA [:cfogel] from comment #59)

(In reply to Gabriela [:gaby2300] from comment #58)

(In reply to Cristian Fogel, QA [:cfogel] from comment #57)

Prepared a section for you at the start of the document.
Anything that would help regarding the issue or the summary should still be posted on this thread for transparency.
Also, thanks again for still willing to help with debugging this issue!

Thanks and no problem! I always love to help as much

In my work’s PC WIndows 7 32-bit and yesterday's Nightly I had 3 Gmail accounts in 3 pinned tabs. I noticed the bug in my primary account but not in the other ones, nor in not Gmail related pinned tabs.

I will check later with my home PC to see if I get the same and I will then add my comment here and in the bug.
I seem to remember that in my home (PC Win 7 54-bit), I got different results when I started my machine for the first time than when I just restarted Nightly.
I will also recheck this later.

Yesterday, using my home PC I didn’t get the bug.

Comment 61

[Cristian Fogel [:cfogel]]

(In reply to Gabriela [:gaby2300] from comment #60)

[...]I had 3 Gmail accounts in 3 pinned tabs. I noticed the bug in my primary account but not in the other ones, nor in not Gmail related pinned tabs.

Where the tabs with the same account or different accounts in each tab?

Comment 62

[Gabriela [:gaby2300]]

(In reply to Cristian Fogel, QA [:cfogel] from comment #61)

(In reply to Gabriela [:gaby2300] from comment #60)

[...]I had 3 Gmail accounts in 3 pinned tabs. I noticed the bug in my primary account but not in the other ones, nor in not Gmail related pinned tabs.

Where the tabs with the same account or different accounts in each tab?

The 3 tabs were for different accounts.

Comment 63

[Cristian Fogel [:cfogel]]

Unfortunately still nothing on my part, in trying to reproduce.
What about the antivirus used in your case?

Comment 64

[Gabriela [:gaby2300]]

(In reply to Cristian Fogel, QA [:cfogel] from comment #63)

Unfortunately still nothing on my part, in trying to reproduce.
What about the antivirus used in your case?

Avast at home, McAfee at work

Comment 65

[Gabriela [:gaby2300]]

(In reply to Cristian Fogel, QA [:cfogel] from comment #63)

Unfortunately still nothing on my part, in trying to reproduce.
What about the antivirus used in your case?

I replied almost a week ago, any update on the issue?

Comment 66

[Liz Henry (:lizzard)]

LIkely too late to fix for 70 and we can't seem to reproduce reliably.
We can keep trying for 71/72 though.

Comment 67

[Marcia Knous [:marcia]]

Discussed during Platform triage. Adding a ni on Cristian - Were you able to reproduce this with the info that Gaby provided?

Are we able to ascertain when this started happening? Adding Regression Window wanted.

Comment 68

[Cristian Fogel [:cfogel]]

No success still.
This was one of the tests we ran during our last AV exploratory run(hence the inquiry on #c63) but we couldn't reproduce the issue at all.

@Gabriela sorry for the late reply.
When you have time mind doing a regression check with mozregression?

Comment 69

[Gabriela [:gaby2300]]

(In reply to Cristian Fogel, QA [:cfogel] from comment #68)

No success still.
This was one of the tests we ran during our last AV exploratory run(hence the inquiry on #c63) but we couldn't reproduce the issue at all.

@Gabriela sorry for the late reply.
When you have time mind doing a regression check with mozregression?

No problem!
The bug seems to be fixed in the latest builds

Comment 70

[Cristian Fogel [:cfogel]]

Closing the bug as WFM based on the previous comment and since there wasn't any other re-occurrence of the issue.
Feel free to reopen if the issue resurfaces.

@Gabriela,
Thanks again for the report and helping us try to debug!

Comment 71

[Gabriela [:gaby2300]]

(In reply to Cristian Fogel, QA [:cfogel] from comment #70)

Closing the bug as WFM based on the previous comment and since there wasn't any other re-occurrence of the issue.
Feel free to reopen if the issue resurfaces.

@Gabriela,
Thanks again for the report and helping us try to debug!

@Cristian,
No problem! I love to help as much as I can.