1656310 - Twitter would not load from bookmarks by click. It needs double click.

Status: RESOLVED DUPLICATE of bug 1662925

(Core :: DOM: Service Workers, defect, P1)

Description

[Alice0775 White]

Attachment: screenshot

STR:

1. Bookmark twitter(e.g. https://twitter.com/Firefox ) to bookmark toolbar
2. Quit browser. And re-start browser
3. Click on the bookmark
4. Follow next steps if website is successfully displayed
5. Quit browser. And re-start browser
6. Click on the bookmark

Actual Results:
The website would not be displayed.
It needs double click.

Console shows:
"Blocked by Devtools" GET https://twitter.com/Firefox

Expected Results:
The website should be displayed with mouse click.

#1 Regression window(content area becomes blank, tab label indicates "New Tab", address bar still indicate placeholder text):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6eedccd860c3735b00f7c6d6431484e7fc89eb82&tochange=78f1674d7bf020ca91f4517cb5d85b019e820898

#2 Regression window(nothing happens):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e7e487fbbaf08e13d2825f29df822761b661dbd2&tochange=30cde47f9364e5c7da78fd08fa8ab21737d22399

Regressed by: Bug 1626362

And this seems to be unexpectedly fixed in 80.
Fixed window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2b880e8d9143fee7badb103f965d461a4c1ceae8&tochange=fbcb0ee2d17a21e2065daf9b5186f3e51ab97613

Comment 1

[Alice0775 White]

WORKAROUND:
about:preferences#home > Set "Homepage and new windows" to "Blank Page"

Comment 2

[Alice0775 White]

Another str:

1. Set "Homepage and new windows" to "https://twitter.com/Firefox"
2. Restart browser (at least 2 times)

Actual Results:
The website would not be displayed.

Comment 3

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

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

Comment 4

[:Gijs (he/him)]

Luca, any idea about the fixed window in comment #0 and what is going on here?

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

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

Luca, any idea about the fixed window in comment #0 and what is going on here?

About the fixed window, I'm not yet sure exactly which part of Bug 1609920 patches may have affected the reproducibility of this issue ([1]), but the issue seem to be definitely related to the service workers and apparently I can still trigger it on Firefox 80 with a different STR:

• In Firefox 79, where the issue can still be triggered, in about:debugging I see that there is an https://twitter.com/sw.js service worker listed, its status is stopped and it is listening for fetch events:

  • the first time the twitter bookmark is clicked, the service worker is still marked as stopped, and twitter isn't loaded in the tab
  • the second time the bookmark is clicked, the service worker in about:debugging goes from stopped to running, and twitter does load as expected in the tab
  • if I wait for the service worker listed in about:debugging to go to the stopped status again, I can also retrigger the issue as the first time without even restarting the browser

• In Firefox 80, in about:debugging there isn't initially any service worker listed, then:

  • the first time the twitter bookmark is clicked, the service worker appears in the about:debugging list, it is marked as registering and then running, and the twitter url is being loaded
  • If I wait for the service worker listed in about:debugging to go to the stopped status again, I can trigger the issue as in Firefox 79

And so the issue doesn't seem to be really fixed, the issue with twitter not loading can still be triggered with a slightly different STR.

On the other end something in 80 (not sure yet if it is actually Bug 1609920) may have changed something related to the status of the workers on startup or at least their status as visible in about:debugging (which wasn't expected, and I want to dig into that more, those patches were not supposed to affect that).

I'm going to come back to this tomorrow and do some more digging, but I'm also needinfo-ing :asuth for his opinion about the possible underlying reasons for this issue, as well as about the difference that I spotted in about:debugging between 79 and 80 that I described above.

[1]: a very big chunk of the changes introduced in those patches is actually locked behind prefs and disabled by default on all channels (and enabled only for the related test cases at the moment), I would have been less surprised if the fixed window was pointing to Bug 1642676 which landed in the same release and it was a dependency of Bug 1609920 patches.

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

(set back the needinfo assigned to me, to do more digging into the underlying issues)

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

Follows some additional logs that I've collected by reproducing the issue on a nightly debug build, using the alternative STR (wait until the service worker listed in about:debugging is in the stopped state, then click on the twitter bookmark):

[Parent 623362, IPDL Background] WARNING: '!proxyManager', file /builds/worker/checkouts/gecko/dom/serviceworkers/FetchEventOpParent.cpp, line 36
[Parent 623362, Main Thread] WARNING: '!mInterceptedChannelHandled', file /builds/worker/checkouts/gecko/dom/serviceworkers/FetchEventOpChild.cpp, line 261
[Parent 623362, Main Thread] WARNING: Failed to handle intercepted network request; canceling interception!: file /builds/worker/checkouts/gecko/dom/serviceworkers/FetchEventOpChild.cpp, line 265

As I was assuming the issue is related to the service worker not handling the fetch request, the warnings logged in the debug build suggest that FetchEventOpParent is aborting the request because manager->GetRemoteWorkerParent is returning null (which based on the inline comment right above where we log that warning it should be happening if the manager's RemoteWorkerController has shutdown):

• https://searchfox.org/mozilla-central/rev/a315a1a0f09550e23e4590a77e74f36543315da3/dom/serviceworkers/FetchEventOpParent.cpp#34-40

Then FetchEventOpChild cancel the intercepted network request because it did fail to handle it:

• https://searchfox.org/mozilla-central/rev/a315a1a0f09550e23e4590a77e74f36543315da3/dom/serviceworkers/FetchEventOpChild.cpp#261-268

Hopefully these additional details may help us to look into the right direction to fix the underlying issue (which should be a preexisting issue and should have not been affected by Bug 1609920 patches, but I'd still like to dig a bit more to be sure that Bug 1609920 patches are not the ones that changed the behavior I observed in the about:debugging service workers section)

Comment 8

[Neha Kochar [:neha]]

Moving to Service Workers based on Comment 5.

Comment 9

[Kim Moir [:kmoir] ET]

:jstutte triaging as REO for 79, could you set a priority and severity for this bug?

Comment 12

[Tom S [:evilpie]]

This seems to a be pretty common issue. I am still not sure yet if this the only issue or if Firefox 79 introduced multiple similar problems (bug 1657651). I would raise the Severity of this.

Comment 14

[Mark Banner (:standard8)]

[Tracking Requested - why for this release]: Seems to be affecting a lot of users from the dupes we're getting.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

IIUC, this only affects 79 though?

Comment 16

[Mark Banner (:standard8)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #15)

IIUC, this only affects 79 though?

Hmm, yeah, I might have been wrong there. I was confused by the status fields which implies this is still a problem for 81 - maybe there's something underlying that still needs fixing.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Thanks. We can leave this open while the investigation continues but it doesn't sound like this is going to be biting users once 80 starts rolling out this week.

Comment 18

[Jan Manthay]

I also had this problem since Fx 79, and it is NOT fixed for me with Fx 80 or the new 80.1. Or rather, I am not shure if it was fixed with FX 80, but it is NOT with 80.1.

Comment 19

[Alice0775 White]

The problem is reproduced in Firefox81.0 and Nightly82.0a1.

Steps to reproduce:

1. Launch Firefox with new profile
2. Open New Tab
3. Click twitter icon in Top Sites
4. Relaunch the browser
5. Repeat steps 3 and 4.

Unregister service workers from about:serviceworkers will fix the bug temporary.

Comment 20

[Alice0775 White]

The problem re-appears as Comment 19.

The regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a4dccb7df26ef69e7fe86d3fcaa79fde8082bc8a&tochange=845077201b0c0f9632d21204392cba49cde2b9fb

Suspect:
478e4e145ab3f1d0667fdf1982ee47f52622813b Luca Greco — Bug 1663125 - Fix registered service workers missing after restart and cover it with a marionette test. r=asuth,whimboo,marionette-reviewers

Comment 21

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Alice0775 White from comment #20)

The problem re-appears as Comment 19.

The regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a4dccb7df26ef69e7fe86d3fcaa79fde8082bc8a&tochange=845077201b0c0f9632d21204392cba49cde2b9fb

Suspect:
478e4e145ab3f1d0667fdf1982ee47f52622813b Luca Greco — Bug 1663125 - Fix registered service workers missing after restart and cover it with a marionette test. r=asuth,whimboo,marionette-reviewers

Well, that was really expected, as described in comment 5 Bug 1609920 didn't actually fix the issue, it did just change the STR to reproduce it as a side effect of the issue fixed we fixed in Bug 1663125.
Similarly Bug 1663125 didn't regress this issue again, it does fix the regression from Bug 1609920 and as a side effect this issue is now reproducible with the original STR.

Given that the issue was there way before Bug 1609920, and that we already knew that Bug 1609920 was not actually fixing it, I don't think that Bug 1663125 can technically be classified as a regression for this bug.

Comment 22

[Ehsan Ch]

After solving Bug 1663125
Similar issue in Firefox for android 81.1.1 Build #2015764545 appear.
When click on installed PWA icon in Homescreen, or click on bookmarked icon of a PWA on Top sites , page will not load and show empty screen.
after refresh, it will be loaded but when loaded via home screen icon, there is no refresh button for standalone apps.

When typing URL manually, it will load normally.

Comment 23

[Michael Hohner]

Maybe the same issue here:

Twitter home page does not load. Web console shows:

Fehler beim Laden von 'https://twitter.com/'. Ein ServiceWorker hat eine mit 'TypeError: NetworkError when attempting to fetch resource.' abgelehnte Promise an FetchEvent.respondWith() übergeben.

No strings exist for error: corruptedContentErrorv2-title aboutNetError.js:229:13
setErrorPageStrings chrome://browser/content/aboutNetError.js:229
initPage chrome://browser/content/aboutNetError.js:283
<anonym> chrome://browser/content/aboutNetError.js:1302

This is with FF 81.0.1 on Win 10.

Comment 24

[Luca Greco [:rpl] [:luca] [:lgreco]]

I'm blocking this issue on Bug 1662925: this issue should be fixed by the patches attached to Bug 1662925, because the underlying issue is the same one (but likely something that can be triggered also with other STRs when fission is enabled).

Comment 26

[Alice0775 White]

https://m.twitch.tv/ is also affected.

Comment 28

[mub]

Having the same issue with reddit.com

When opening a fresh instance of firefox, if I enter the URL manually or click the link in my shortcuts bar the refresh page button does one single very quick spin but the page does not load. I have to click it again for the page to actually.

Have tried clearaing all cache/cookies etc, and disabled all addons. Same result.

Firefox Version: 81.0.1 (64-bit)

Please fix this issue it is annoying.

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

Duping to bug 1662925 which fixes this problem (and the fix was uplifted to beta 82).

To quickly recap the situation and why bug 1662925 fixes it:

• The problem was exactly as Luca describes in comment 7. When Firefox started it didn't have a "web" process spawned and when the first navigation triggered involved a ServiceWorker interception, the request was immediately aborted because the "web" process didn't exist yet. The fix was to enhance the queuing logic. See https://bugzilla.mozilla.org/show_bug.cgi?id=1662925#c18 for some more details.
• The apparent fix in Firefox 80 described in comment 0 is exactly as Luca describes in comment 21; we accidentally broke ServiceWorker registration loading at startup so a ServiceWorker wouldn't be used in navigations where it previously would have been used. This regression was addressed, but brought back this bug (which is the same bug as bug 1662925).

It's important to note that there was a different way twitter's ServiceWorker (and other ServiceWorkers) could fail to load, this time with a "corrupt content" page instead of a blank page. That is tracked by bug 1665368 and is being addressed on Firefox 81/release with a dot release uplift of bug 1663992.

Comment 30

[Powsin]

WHEN WILL THIS FUCKING PROBLEM BE FIXED ITS 2020
PEOPLE ARE DYING OUT THERE ANY MINUTE.
WHAT ADVANCED FUCKERY IS THIS? THE ONLY WAY THIS IS NOT GETTING
FIXED IS BECAUSE THEY USE CHROME IN THEIR OFFICE. IF THEY ARE USING FF
THEY SHOULD KNOW ABOUT THIS BUG.

Comment 31

[Powsin]

(In reply to Alice0775 White from comment #1)

WORKAROUND:
about:preferences#home > Set "Homepage and new windows" to "Blank Page"

YOU A GOOD MAN HOMIE. WORKAROUND SPLENDIDLY WORKS.