Bug 1662925 Comment 26 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

This is not a new issue.  It also is recoverable if the user goes to the URL bar and hits enter again, etc.  That said, bug 1663125 which impacted Firefox 80 would have made the problem disappear because ServiceWorkers were not having their registrations loading from disk on startup.  That regression was fixed late in the 81 cycle (81.0rc2) as well, so it might appear like a new regression for some set of users.

See the blockers and see also's for potentially related bugs.  Note that there's a separate twitter issue which is more concerning and getting some awareness and that's the one that involves the corrupted content UI.  That is likely unrelated to this bug.

In terms of regressions, I think we'd notice it pretty quickly because the failure modes for a screw-up would be:
1. Crash.  We should see a ton of crashes on twitter.com for those that report the URL if so.
2. Hangs forever / displays about:blank.  This is actually the problem that the bug fixes, but if that didn't get fixed right or increased the incidence, I'd still expect us to hear about it because of twitter.
3. Increased corrupted content error rate.  We actually may see this in the success case because whatever's happening with the twitter SW throwing a rejection might happen more because the set of successfully launched ServiceWorkers with FetchEvents dispatched at them would increase.

Note again that the Twitter corrupted content error (bug 1665368) is a separate bug I'm working on a fix for and that one is definitely not suitable for immediate uplift.  So maybe it makes sense to wait to for that fix to land and both to ride the beta train.  I just wanted to make sure this potential fix was known to release management for consideration.
This is not a new issue.  It also is recoverable if the user goes to the URL bar and hits enter again, etc.  That said, bug 1663125 which impacted Firefox 80 would have made the problem disappear because ServiceWorkers were not having their registrations loading from disk on startup.  That regression was fixed late in the 81 cycle (81.0rc2) as well, so it might appear like a new regression for some set of users.

See the blockers and see also's for potentially related bugs.  Note that there's a separate twitter issue which is more concerning and getting some awareness and that's the one that involves the corrupted content UI (bug 1665368).  That is likely unrelated to this bug.

In terms of regressions, I think we'd notice it pretty quickly because the failure modes for a screw-up would be:
1. Crash.  We should see a ton of crashes on twitter.com for those that report the URL if so.
2. Hangs forever / displays about:blank.  This is actually the problem that the bug fixes, but if that didn't get fixed right or increased the incidence, I'd still expect us to hear about it because of twitter.
3. Increased corrupted content error rate.  We actually may see this in the success case because whatever's happening with the twitter SW throwing a rejection might happen more because the set of successfully launched ServiceWorkers with FetchEvents dispatched at them would increase.

Note again that the Twitter corrupted content error (bug 1665368) is a separate bug I'm working on a fix for and that one is definitely not suitable for immediate uplift.  So maybe it makes sense to wait to for that fix to land and both to ride the beta train.  I just wanted to make sure this potential fix was known to release management for consideration.

Back to Bug 1662925 Comment 26