1641012 - BrowserTabChild.jsm fails to load twitter when refreshing

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Attachment: CORS failures.png

1. Open Twitter (and check everything works well)
2. Make your system very busy, for example by running a full Gecko build.
3. Try some features e.g. search and see it works

Expected: It still should work flawlessly
Actual: twitter.com suddenly can't access api.twitter.com

Comment 1

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Attachment: failure-from-twittercom.png

Comment 2

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Attachment: BrowserTabChild.jsm fails to load twitter when refreshing

Comment 3

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

:smaug, do you have an idea why it dies? This happens quite frequently on my machine as I have a pinned Twitter tab.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

My guess would be some timing issue on twitter side. Some racy script loading or flag setting or some such.
But that just a pure guess.

Comment 5

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

My last screenshot denies that, somehow even BrowserTabChild.jsm can't load twitter. I guess something inside Gecko dies and never revives.

Comment 6

[Eric Rahm [:erahm]]

Lets move this to Networking for now.

Comment 7

[Dragana Damjanovic [:dragana]]

Junior, can you take a look? I am not sure this is necko issue.

Comment 8

[Junior [inactive]]

I can't reproduce here.
What I can do is try to track why we got lots of CORS blocked requests, which don't make sense.

A bold guess is some service is broken, hence bails out the status check
https://searchfox.org/mozilla-central/rev/559b25eb41c1cbffcb90a34e008b8288312fcd25/netwerk/protocol/http/nsCORSListenerProxy.cpp#490

Hello :saschanaz, could you please collect the http log for us to move this forward?
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Thanks!

Comment 9

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

It's too big so here it is: https://1drv.ms/u/s!ArDhQNmhsUj04csQOsezgza5LeZDqQ?e=qDN27H

Comment 10

[Junior [inactive]]

The failure is during service worker redirection and we fail the check in the child process.
I check some of the failed requests. It turns out that those channels are intercepted.

:saschanaz, could you try to see if it's reproducable again without service worker?
That is, (a) turn off pref dom.serviceWorkers.enabled (b) restart

Thanks!

Comment 11

[Kagami Rosylight [:saschanaz] (they/them) (inactive until 2025-11-14)]

Attachment: log.txt-main.10008.moz_log

It repros:

Comment 12

[Junior [inactive]]

Hello Andrew,
Two questions:
(a) Please see comment 10.
Could you take a look since all the failure requests are intercepted here
i.e., the log has nsHttpChannel::Connect in line 747 but no nsHttpChannel %p tracking resource=%d, cos=%u in line 760

(b) This is minor. :saschanaz tried to disable service works but the those reqeusts are still go to the same code path.
i.e., Connect, Intercepted and redirection back, with AsyncAbort.

Does turning off dom.serviceWorkers.enabled fail to stop interception and redirection?
I check the code quickly and I see the only effect is disable the the webidl registration.
https://searchfox.org/mozilla-central/source/dom/webidl/ServiceWorkerRegistration.webidl#12

Comment 13

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

(In reply to Junior [:junior] from comment #12)

(a) Please see comment 10.

I still need to look at this and will leave the needinfo active but wanted to address the next one.

(b) This is minor. :saschanaz tried to disable service works but the those reqeusts are still go to the same code path.
i.e., Connect, Intercepted and redirection back, with AsyncAbort.

Does turning off dom.serviceWorkers.enabled fail to stop interception and redirection?
I check the code quickly and I see the only effect is disable the the webidl registration.
https://searchfox.org/mozilla-central/source/dom/webidl/ServiceWorkerRegistration.webidl#12

I believe you're right that this isn't actually disabling interception if there are ServiceWorkers that exist, which is insufficient for an emergency disabling switch. I believe there may have previously been a check in the propagation of ServiceWorkerRegistrations that might have effectively prevented interception with child-intercept, but I don't think that's present anymore. I've filed bug 1645054 to make the preference control interception and also purge existing registrations at the next startup. (I'm open to alternate proposals about how to handle things better though!)

Comment 14

[Valentin Gosu [:valentin] (he/him)]

I'm pretty sure this has been fixed already. Andrew can correct me if I'm wrong.