1588093 - Twitter scrolls on its own, images fail to load when multiple Service Worker tabs are opened

Status: NEW

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

Description

[miralobontiu]

Attachment: twitter-issue.gif

Environment:
Device: Nexus 6P (Android 8.1), OnePlus 5T (Android 9)
Build: Firefox Preview Nightly 191010 (#12830611), Gecko 71.0a1

Steps to reproduce:

1. Open multiple service worker pages (I had 21 tabs opened: youtube, Pinterest, proxx.app, serviceworkers.rs, bergfreunde.eu, facebook, gmail, united.com, whatwg.org, twitter.com, etc).
2. Navigate on Twitter opening some videos, browse it in every posible manner.

Expected result:
Twitter should load correctly, be scrollable; video contents are being loaded, can be paused, resumed; pictures are displayed, can be zoomed, downloaded; navigation is done without issues; no rendering issues presented, no glitches, no interruptions.

Actual result:
Twitter loads correctly, but, after some navigation, it starts scrolling on its own, images aren't loading, there are interruptions.

Notes:

• I will attach a short GIF and the logcat.
• It doesn't matter if the dom.serviceWorkers.parent_intercept pref is "true" or "false" (about:config).
• Not reproducible on Firefox Preview Nightly 10/04 (#12771805).

Comment 1

[miralobontiu]

Attachment: logcat.txt

Comment 2

[Chris Peterson [:cpeterson]]

Mirabela, since you can reproduce this bug in Firefox Preview Nightly 191010 (#12830611) but not in Nightly 10/04 (#12771805), can you please test Nightly builds 10/05 through 10/09 until you find the build that first has the bug? That will be help the GeckoView engineers narrow the regression range they need to debug.

Comment 3

[miralobontiu]

Hi Chris,
I've tested with Nexus 6P (Android 8.1) on the Nightly builds you've mentioned, and it turns out that on the latest build from 10/07 (#12801804) Twitter was working as expected, but on the latest build from 10/08 (#12811814), the issue is reproducible.
I had about 19 tabs opened.
Please let me know if there is anything else I can do.

Comment 4

[Chris Peterson [:cpeterson]]

Thanks, Mirabela! Knowing this is a regression in Fenix Nightly build 10/08 (#12811814) is a big help.

I'll try to determine which GeckoView versions were used in Fenix Nightly 10/07 and 10/08.

Comment 5

[Chris Peterson [:cpeterson]]

Moving to Service Workers' Bugzilla component. This problem seems like Gecko or GeckoView are swamped with work by the background Service Worker tabs and can't keep up with input events.

QA says this is an apparent regression between Fenix Nightly 10/07 and 10/08. To determine which GeckoView and Gecko Nightly versions are used by those Fenix Nightly builds, you'll need to install the builds and check Fenix's About screen.

Comment 6

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

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

Comment 7

[Pascal Chevrel:pascalc (PTO until April 26)]

fix-optional for our 71 release given that we are in RC week and this only seems to impact Fenix which has a different release schedule than desktop and fennec.

Comment 8

[Stefan Deiac]

Hello, the Fenix build from 10/7 was Gecko 71.0a1-20191004094656 and for the 10/8 was the same build version.
Please let me know if there is anything else I can do.

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix in 72 but we could still take a patch for 74 and possibly 73.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Jens, this seems like a fairly serious problem, do you want to keep it at P2 or is this something your team can investigate now?

Comment 11

[Jens Stutte [:jstutte]]

:perry, can you please give it a look?

Comment 12

[Jens Stutte [:jstutte]]

Switching ni to :echuang.

Comment 13

[Eden Chuang[:edenchuang]]

I will try to reproduce this problem with current nightly first.

Comment 14

[Julien Cristau [:jcristau]]

Eden, do you have an update on this?

Comment 15

[Eden Chuang[:edenchuang]]

Sorry for the late response.
I successfully reproduced the issue with the emulator only once, but have no idea what's going on for the case.
I probably need a real device for that.

According to the description, it seems that the input event probably finishes before the SW updates the page. Will try to figure the root cause in these two days.