Closed Bug 1306971 Opened 8 years ago Closed 7 years ago

images sometimes appear black [regression]

Categories

(Core :: Graphics: ImageLib, defect, P3)

50 Branch
Unspecified
Android
defect

Tracking

()

RESOLVED DUPLICATE of bug 1380649

People

(Reporter: linuxhippy, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [gfx-noted])

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20160929120120 Firefox for Android Steps to reproduce: When browsing the web with FF 50b1 on Android (Nexus 5x), somtimes images appear black and stay that way until the page is reloaded (looks like a texture upload problem). This seems to be a regression, as I haven't experienced it wiith earlier FF builds (pre 50-beta) and I didn't change settings or the FW of my device.
OS: Unspecified → Android
Attached image youtube (deleted) —
Attached image another website showing the issue (deleted) —
forgot to mention: although the screenshots show all images as black, sometimes only a few images are black while all the others are loaded correctly. The issue can't be reproduced reliable - on my device it happens about once in 15-60min browsing time and various websites, so the issue doesn't seem to be dependent on the content.
Hey Clemens Is this still happening on the second 50 Beta?
Component: Untriaged → Graphics, Panning and Zooming
Product: Firefox → Firefox for Android
Flags: needinfo?(linuxhippy)
Component: Graphics, Panning and Zooming → ImageLib
Product: Firefox for Android → Core
Keywords: regression
Priority: -- → P3
Whiteboard: [gfx-noted]
sure 50b4 is also affected
Flags: needinfo?(linuxhippy)
images seem alsoto disapear when zooming in/out: https://youtu.be/SGkpUKegwfk
Attached image Similar (or same) issue on OS X (deleted) —
I'm pretty sure I'm hitting this same issue on my mac (5K iMac running Sierra), every so often when switching tabs or windows I end up with some missing images. It also leads to repainting issues, hovering over the results on Google shows the info bar that sometimes isn't cleared properly (And can end up painted multiple times getting progressively darker)
If anyone can find reliable steps to reproduce, or can reproduce reliably enough to bisect this that would be very helpful.
at last on android I experienced the issue from time to time when switching tabs and/or bringing firefox to foreground - so maybe it is some timing related issue which can not reproduced reliably. However, I am quite sure it is a regression introduced recently, I've never experienced this issue with FF-48 (not 100% sure about 49).
I am not sure if this bug is somehow related to an issue I see on my linux desktop with OpenGL enabled - it also only shows up from time to time: bug 1306974 It started to appear at about the same time as this issue on Android, so maybe the opengl pipeline has been broken in the not-so-distant-past. Maybe it would make sense to take a look at the opengl related commits in the mentioned time-frame (firefox 48-50), as normal bisecting would be very cumbersome due to the sporadic nature of this bug.
just experienced this issue on a Snapdragon-410 powered low-end phone running Android-4.4.4
Andrew, can you reproduce this?
Flags: needinfo?(aosmond)
I haven't found a surefire way to reproduce this on Android, either, however I've noticed that when it occurs: - Just zooming the page around doesn't fix it - the affected images remain black - Neither does switching to a different tab and back again - However momentarily sending Firefox into the background (if necessary followed by zooming the page around to trigger a repaint) *does* fix it
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Jan Henning [:JanH] from comment #13) > I haven't found a surefire way to reproduce this on Android, either, however > I've noticed that when it occurs: > - Just zooming the page around doesn't fix it - the affected images remain > black After I've encountered it again, I have to correct myself: it doesn't immediately fix it. The images might appear when zooming in and then turn black again after zooming back out to the original zoom level, however after repeatedly changing the zoom level and scrolling around, the black images eventually disappeared again.
finally cought this on cam - Nexus 5x, Android 7.1.1 (1.2017 update): https://youtu.be/eDgRs7KgZWo
Is it reproducible on the same page at all after restarting?
no of course not reproducible - it some timing issue or race condition somewhere. As can be seen the same page is rendered correctly after clicking a ling and using "back" to get back to the problematic page again. otherwise i guess it would have been fixed a long time ago.
The video reminds me strongly of bug 1292290. The result of that bug was backing out the regression patch, it wasn't obvious why the patch had caused that, and no one ever investigated why it caused the bug. So it's quite possible that the same underlying bug still exists. So one point of attack (since bug 1292290 was reproducible) would be to investigate bug 1292290 to understand it's full cause.
FWIW I see this on a daily basis on my n5x viewing mobile.twitter.com.
In case it gives somebody a clue, the relevant bit about momentarily backgrounding Firefox is probably that this triggers a heap minimisation (https://dxr.mozilla.org/mozilla-central/rev/ffe6cc09ccf38cca6f0e727837bbc6cb722d1e71/widget/android/nsAppShell.cpp#185). Going to about:memory and pressing "Minimize memory usage" also has the same effect and restores image rendering back to normal.
FWIW, I trigger this without backgrounding. Typically it happens when I click a link in twitter and then go back to my twitter feed. The previously viewable images are all black.
The upcoming nightly should contain the fix. Please reopen this bug if it continues to happen after build >= 20170919220202.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(aosmond)
Resolution: --- → DUPLICATE
Glad to hear a possible solution has been found, thanks very much. (In reply to Ben Kelly [:bkelly] from comment #22) > FWIW, I trigger this without backgrounding. No, what I meant is that once this bug happens, triggering a heap minimisation (either via backgrounding, or about:memory) restores image rendering back to normal.

Removing regressionwindow-wanted keyword because this bug has been resolved.

Removing regressionwindow-wanted keyword because this bug has been resolved.

Removing regressionwindow-wanted keyword because this bug has been resolved.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: