Closed Bug 1446239 Opened 6 years ago Closed 6 years ago

Images turn black while scrolling twitch.tv on Android

Categories

(Core :: DOM: Core & HTML, defect, P3)

Unspecified
Android
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox-esr52 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- affected

People

(Reporter: rbarker, Unassigned)

References

Details

(Whiteboard: [gfx-noted][geckoview:crow])

Attachments

(1 file)

When visiting twitch.tv on android with Fennec or a GeckoView based application. The preview image tiles on the main page turn black when the page is scrolled. This affects all Current version of fennec (Release, Beta, and Nightly) as well as GeckoView.
Attached video blacktiles.mp4
Video of image tiles turning black while scrolling.
Moving this bug to Core::Graphics for triage because this is a gfx bug, not a GeckoView bug.
Component: GeckoView → Graphics
Product: Firefox for Android → Core
Assignee: nobody → aosmond
Whiteboard: [gfx-noted]
Whiteboard: [gfx-noted] → [gfx-noted][geckoview:crow]
Andrew, do you have any updates or questions regarding this Android bug? It's a really bad user experience, especially in the Crow VR browser, which uses GeckoView.
Flags: needinfo?(aosmond)
It happens on desktop Linux too if I switch the user agent to Android. Investigating.
At first I thought it was the interaction between the src and srcset attributes on the img elements, but that was a red herring. Despite the repeating pattern of a LoadImage call for one size, followed by a dispatched LoadImage call (via ImageLoadTask) for a larger size, the nsImageFrame doesn't even get created before the second call comes in. As for potential redecoding, the image cache is preserved, so the decoded results are still available as we scroll/flicker, so we aren't waiting on the decoder.

My guess is it is driven by the recreation of the HTMLImageElement and associated nsImageFrame objects representing the thumbnails. There is a script on the page which causes them to get recreated when we scroll. Chromium handles this case better from my testing.
Component: Graphics → DOM
Flags: needinfo?(aosmond)
Assignee: aosmond → nobody
overholt, can we get this DOM bug triaged? It is a pretty bad user experience on Android.
Flags: needinfo?(overholt)
OS: Unspecified → Android
Summary: Images turn black while scrolling twitch.tv → Images turn black while scrolling twitch.tv on Android
Hmm, maybe Henri has a thought or two on the creation of the HTMLImageElement?
Flags: needinfo?(overholt) → needinfo?(hsivonen)
In general, we do better (in terms of platform consistency--I don't mean the visuals seen here) than Blink at having consistently async behavior even when data is synchronously available so as to not change the event flow when data happens to be cached. I suspect that that's what's happening here, but I'm not familiar with the code or this area of the spec, which has a lot of legacy baggage going back to Netscape 2 behavior but then that has been conditionally amended in various ways.

Since bz reviewed a lot of this code, redirecting the ni to bz.
Flags: needinfo?(hsivonen) → needinfo?(bzbarsky)
What sort of image URLs are involved?  Are we hitting the imagelib cache?

The one case I know where we have more async behavior than Chrome is never-before-loaded data: URIs, but I somehow doubt that's what's going on here.
Flags: needinfo?(bzbarsky)
An additional data point is the images do not turn black in GeckoView when the desktop page is requested so they are doing something "different" for the mobile site.
Priority: -- → P3
(In reply to Randall Barker [:rbarker] from comment #10)
> An additional data point is the images do not turn black in GeckoView when
> the desktop page is requested so they are doing something "different" for
> the mobile site.

Does this mean we need to do some evangelism? Do we have reason to believe this behaviour is wider spread than just Twitch?
(In reply to Andrew Osmond [:aosmond] from comment #4)
> It happens on desktop Linux too if I switch the user agent to Android.
> Investigating.

aosmond, you said you see this problem on desktop Linux when spoofing an Android UA string. Does the scrolling look good on Linux when using the default desktop UA string?

I see flickering black images when scrolling https://m.twitch.tv/ quickly in Firefox, Chrome, and Edge on Windows desktop. Those black images seem like a typical checkerboarding issue. In Firefox, however, I can reproduce image flickering even when scrolling slowly up or down.

(In reply to Andrew Osmond [:aosmond] from comment #5)
> My guess is it is driven by the recreation of the HTMLImageElement and
> associated nsImageFrame objects representing the thumbnails. There is a
> script on the page which causes them to get recreated when we scroll.
> Chromium handles this case better from my testing.

Does Twitch only serve this image scrolling script if you spoof an Android UA string? If there is some code change we'd like them to make, I can pass it on to our dev contacts at Twitch.
Flags: needinfo?(aosmond)
(In reply to Randall Barker [:rbarker] from comment #10)
> An additional data point is the images do not turn black in GeckoView when
> the desktop page is requested so they are doing something "different" for
> the mobile site.

In the desktop case, they specify a bunch of relatively low-res images by src. In the mobile case, they specify even lower-res images by src but also specify significantly higher-res images via srcset in a script-filled infinite scroll (we load the higher-res ones).

I don't see Chrome handling this any better than we do. On my Pixel, both Chrome and Firefox show black placeholders if I scroll more quickly than the image loads can keep up.

I think this is a site design tradeoff and not a browser bug. Resolving as INVALID as in "not our bug"--the behavior is as alleged.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
I still think there is a desktop Firefox issue. The images flicker in Firefox even when scrolling very slowly. They don't flicker in Chrome, Edge, or IE11 on Windows or Chrome or Safari on macOS, so this problem is unique to Firefox.

Instead of morphing this Android bug into a desktop bug, I filed new bug 1460032.
Flags: needinfo?(aosmond)
See Also: → 1460032
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: