Closed Bug 1122643 Opened 10 years ago Closed 10 years ago

Regression: Occasionally after a tab switch, images in the active tab turn black; corrects itself on reload

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Version:
36 Branch
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla37
Tracking Flags:
Tracking Status
firefox35 --- unaffected
firefox36 + fixed
firefox37 --- affected
firefox38 --- affected
firefox39 --- affected
fennec 36+ ---

People

(Reporter: jan.manthay, Assigned: seth)

References

Details

(Keywords: regression, reproducible)

Attachments

(3 files)

Problem on the Moto G with all pictures black
194.74 KB, image/png
Details
Problem on the Asus Memopad with some pictures black
672.42 KB, image/png
Details
Problem on Asus with complete broken page
123.41 KB, image/png
Details
Firefox for Android 36 Beta Devices: Asus Meopad HD7 and Motorola G , both affectetd. After loading a webpage, klicking a link, loading the new page, I navigate back to the previous page. Result: Often, but not always, some, or all pictures are black. On one specific site sometimes everything is a mess. A reload of the pages fixes the issue. It looks like open a link that opens a new tab causes the problem more often than a simple link within the same website. Also the problem appears way more often on the Asus, then on the Motorola. While on the Asus the problem apperas on nearly every site, I experienced it on the Motorola only 3-4 times so far. Example sites: tagesschau.de heise.de tomshardware.com/ I wanted to add a log, but I can’t get any log app to work.
One more: I deinstalled Firefox, rebooted the device, and reinstalled Firefox Beta fresh from the play store. The problem is still there.
I take it Firefox 35 (Release) works for you? Would you be willing to help find a regression-window?
35 Release is OK, 35 Beta was also OK. I just installed 38 Nightly, which is also effected. What should I do?
It would be helpful if you could dive into our FTP and try out older (Nov/Dec) mozilla-aurora builds (APK's) to try and nail down a particular date and build that fixes the problem (good) and introduces the problem (bad). http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/ You can also try another method of using http://mozilla.github.io/mozregression/ which automates the download, install and launch of builds on your device.
status-firefox35: --- → unaffected
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
I wonder if this is related and or the same as bug 1084711 tracking 36+. Although the screenshots in that bug showcase entire pages being glitchy. Kevin mentioned other devices are affected too.
See Also: → 1084711
Jan, there is also a testcase here: http://people.mozilla.org/~mwargers/tests/layout/largeimage_parentframes.htm - can you reproduce against this testcase page?
I have no problems opening this page on beta or nightly. But this problem never appears on the first load of a page. Everything is OK on the first load. Only if I came back to the page via the "back" button after click on a link, the pictures are black. It also doesn’t matter it I use the browser-back-arrow, or the android-back-arrow Also something I just realized: When I have such a site with broken pictures, the go to the Android homescreen, then back to Firefox, I can see the black pictures short, but after about a second they are displayed. I will try to find a working version like you asked. But that will take I while. Not today for sure.
1. Someone with a Samsung Galaxy Tab 3 is also affected 2. I found something, but I don’t know if this is helpfull. I downloaded the "mozilla aurora android" apk, but it showed that the error comes with the switch from Version 25 to 26. While the version from 27. November (35) is OK, the version from 28. Nobvember (36) is the first with the problem. Maybe testing Nightly would be more usefull?
Just an edit: Unlike I said, it DOES also happen on the first load of pages, but only very rare, and it looks like only on picture heavy pages.
I was seeing this yesterday on a lot of pages on my HTC One M8, although I wasn't using the back button. I was opening links in background tabs, and when I switched to them a lot of them had black images.
We need a regression-window.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
tracking-firefox36: --- → ?
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
(In reply to Jan Manthay from comment #10) > 1. Someone with a Samsung Galaxy Tab 3 is also affected > > 2. I found something, but I don’t know if this is helpfull. > I downloaded the "mozilla aurora android" apk, but it showed that the error > comes with the switch from Version 25 to 26. I assume you mean version 35 to 36. > While the version from 27. November (35) is OK, the version from 28. > Nobvember (36) is the first with the problem. > Maybe testing Nightly would be more usefull? Yes, if you have the time testing nightly would be more useful. The first bad nightly would probably be between october 13 and november 27, as that's when Firefox 36 was on the nightly channel.
I started seeing it on mg GS3 as per comment #12 on nightly starting less than a week ago-ish.
Spotted intermittently on my Samsung Galaxy Note 2 (4.4) Visit http://techmeme.com Open a few links in background tabs Switch back and forth between them Eventually or on some instances on first attempt on switch it happens https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cef590a6f946&tochange=17de0f463944 Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1060869? CC'ing Seth
Summary: After navigating back on a website, all or some pictures are black → Regression: Occastionally after a tab switch, images turn black
Blocks: 1060869
Summary: Regression: Occastionally after a tab switch, images turn black → Regression: Occasionally after a tab switch, images in the active tab turn black; corrects itself on reload
Desktop twitter seems to do this rather quickly on a nexus 5. Load Twitter using request desktop site, visit a link and then press back. Repeat until problem appears.
Hmm, not great that we first hear about this on beta. I'll see if I can reproduce this locally.
Assignee: nobody → seth
tracking-fennec: ? → 36+
Do we have an update here? I don't think we can ship Firefox 36 with this embarrassing bug.
Flags: needinfo?(seth)
Any luck with the regression range? Also, any possible relation to bug 1084711?
(In reply to Milan Sreckovic [:milan] from comment #20) > Any luck with the regression range? Also, any possible relation to bug > 1084711? Comment #16.
(In reply to Aaron Train [:aaronmt] from comment #19) > Do we have an update here? I don't think we can ship Firefox 36 with this > embarrassing bug. There's no update yet, but as of today this is my highest priority.
I tried extensively to reproduce this on my device (a Galaxy Note 10.1 2014 Edition) and have had zero luck so far. I certainly hit bug 1084711 constantly, though. Usually the images on the page are the only things that *aren't* turned black. Tomorrow I'm going to get a phone and try to reproduce there. (In reply to Aaron Train [:aaronmt] from comment #16) > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=cef590a6f946&tochange=17de0f463944 > > Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1060869? Aaron, there's something that concerns me about this regression range. The very previous commit before bug 1060869 is bug 1057904. Bug 1057904 temporarily locked all images, all the time, and forbid any image from ever being optimized or turned into a GPU texture. You'll see it's discussed in the comments how because of this issue, it could not land apart from bug 1060869, which restored things to the previous situation where images weren't locked all the time and could be uploaded to the GPU. Is there any possibility that bug 1057904 actually temporarily _fixed_ the problem, causing bug 1060869 to be wrongly identified as the culprit?
Flags: needinfo?(aaron.train)
If you're referring to the blocking bug number, that was a speculative block. All I know is that the range I get is that where I can reproduce the problem.
Flags: needinfo?(aaron.train)
(In reply to Aaron Train [:aaronmt] from comment #24) > If you're referring to the blocking bug number, that was a speculative > block. All I know is that the range I get is that where I can reproduce the > problem. I'm asking if you can reproduce this *before* bug 1057904/bug 1060869. This is very important information to have, and I cannot check, as I currently cannot reproduce this bug.
Flags: needinfo?(seth) → needinfo?(aaron.train)
Mentioned in channel that this is proving difficult to reproduce, I'm not sure if it's particular content or under certain device constraint or what. Kevin, are you able to take a look too?
Flags: needinfo?(aaron.train) → needinfo?(kbrosnan)
It's possible that bug 1126490 is related. I just pushed it; it might be interesting to try to reproduce this once that patch ends up in Nightly. That issue *did* cause similar symptoms on Windows, though it honestly doesn't make sense that we'd hit it in the course of a normal browsing session on Android. But there's something going on here that we don't understand, so who knows?
Important regression, tracking
tracking-firefox36: ? → +
I just downloaded the lastest nightly, and it looks like it is fixed. I am browsing for a while now and try to provoke it. No effect. Looks good so far.
Jan, thanks for letting us know. That's exciting news; maybe bug 1126490 was indeed the culprit! Given how hard this was to reproduce, though, it'd be great if we can get confirmation from others that they can also no longer reproduce the problem. I'll try to find some more people to test.
Depends on: 1126490
Kevin confirmed that he cannot reproduce as well. I'm going to leave this open for another 24 hours and then close it if no one else can reproduce. I've gone ahead and requested uplift for bug 1126490.
Flags: needinfo?(kbrosnan)
Just had this happen on Aurora 2015-02-03 build.
(In reply to Kevin Brosnan [:kbrosnan] from comment #32) > Just had this happen on Aurora 2015-02-03 build. We discussed this on IRC, but for the benefit of other people reading the bug: bug 1126490 is only on Nightly right now. My first priority is to get it on Beta, and after that we'll get it on Aurora too.
The fix for this has landed on Beta, which means that currently this is expected to be fixed everywhere but Aurora. Uplift to Aurora is currently blocked on some other bugs but I expect it to come within a day or two.
From comment #34, 36 can be marked as fixed.
status-firefox36: affected → fixed
Should this be fixed in todays Beta? If yes, bad news, it’s not.
(In reply to Jan Manthay from comment #36) > Should this be fixed in todays Beta? > If yes, bad news, it’s not. By today, do you mean the update we pushed to Google Play yesterday and your Beta build updated?
Actually I don't think everything has uplifted according latest comment in bug 1126490.
Flags: needinfo?(seth)
No, everything has been uplifted. Nobody could reproduce anymore after bug 1126490, so we believed this was fixed. If this still isn't fixed now, realistically we don't have time anymore to fix this for 36. Sorry. It's just too late at this point.
Flags: needinfo?(seth)
Well, it is definitly not fixed in the latest Beta. But I still think it is fixed in Nightly. And one more thing: There is something I experienced while testing the different Versions today. It looks like the problem is way more harder to reproduce, if there are multiple channels on the device. On my smartphone I use Beta, and was able to reproduce it easy. I then installed Nightly to test, and from this moment on, it was was harder, if not impossible to provoce on Beta. On my Tablet I use Aurora, and installed Beta for testing, and it was nearly not possible to provoe it there. Then I deleted everything, restarted the devices, installed Beta, and, bang, the error was there from the first moment on. I mean, this was really obvious, but of course it could still be a coincidence. But maybe that should be done if this bug should appear: Delete all Fx Versions, restart the device, and only install one Version to test.
So I used nightly extensive the last 3 days, and I think it is save to say it is fixed there indeed. After a short test on the beta (date from 12. february on the play store) it is not fixed there.
We were unable to reproduce this for Desktop Firefox using examples from the bug. However we did get white images during GPU driver update with heise.de open, using Nightly from January 27 on Windows 8.1 x64. The issue did not show on the latest Nightly 38 (could not verify on 36 Beta 10 due to bug 1116812). This verification was part of bug 1126490.
Has this definitely been fixed for Firefox 36? On my Galaxy S3 Mini, I'm experiencing this problem with images turning black after having updated to the 36 release version. The Nightly (2015-02-28) on the other hand seems fine, although I only did a quick test there.
(In reply to JanH from comment #43) > Has this definitely been fixed for Firefox 36? On my Galaxy S3 Mini, I'm > experiencing this problem with images turning black after having updated to > the 36 release version. > > The Nightly (2015-02-28) on the other hand seems fine, although I only did a > quick test there. That seems to agree with comment 40.
(In reply to JanH from comment #43) > Has this definitely been fixed for Firefox 36? No, it definitely hasn't been fixed for 36. At this time we don't know why the patch that worked for 37+ didn't work for 36, unfortunately.
Pretty sure this affects Windows too. Moving this into Core.
Component: Graphics, Panning and Zooming → ImageLib
Product: Firefox for Android → Core
Target Milestone: --- → mozilla37
Version: Firefox 36 → 36 Branch
I've also had the same recurring problem over the last couple of weeks (since the new look update) where what should be images on a website all appear as black oblongs. Affects numerous websites that I visit. Fyi, I often have many tabs open. Have this problem on Galaxy Note 3 and Galaxy Tab 4
Not sure if related, but with 36.0.1 I've noticed black flickering while playing Flash videos where the video is.
[Tracking Requested - why for this release]: noticeable regression
status-firefox39: --- → affected
tracking-firefox37: --- → ?
tracking-firefox38: --- → ?
tracking-firefox39: --- → ?
Florin, can you file a new bug for the issue you mention in Comment 42? Kevin you mention another issue in comment 32 but that seems to be addressed already. Aside from those two comments, what problem are we actually seeing on 37+? Are we sure later versions are affected?
Flags: needinfo?(kbrosnan)
Flags: needinfo?(florin.mezei)
This happens on release for sure. We need to make sure that this has been resolved in 37. Which I am not 100% sure on.
Flags: needinfo?(kbrosnan)
OK. I'll track this for 37 for now. It seems a bit entangled with issues reported (and maybe fixed) in other bugs. So it sounds like we need to find a reproducible case on 37.
tracking-firefox37: ? → +
I will test 37 exclusive the next days, stay tuned.
(In reply to Liz Henry :lizzard from comment #51) > Florin, can you file a new bug for the issue you mention in Comment 42? There is nothing to file here really as the white images issue was reproduced on Firefox 38 from January 27, but did not reproduce on Firefox 38 from February 19, so it looked fixed for 38. Additionally I've tried the same scenario today, with the same exact environment, but also could not reproduce the issue with Firefox 37 Beta 4 (tried two GPU driver updates with heise.de open). In conclusion I cannot reproduce any issue related to this bug in Desktop Firefox 37 or 38.
Flags: needinfo?(florin.mezei)
OK, if you see this come up again as an issue in 37, please re-nominate it for tracking.
tracking-firefox37: + → ---
tracking-firefox38: ? → ---
tracking-firefox39: ? → ---
There is no sign of this Bug on Beta 37 on my devices. That’s after many hours of browsing.
Agreed works for me.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
How I got around the pesky black placeholders. At least it works for me. about:config accessibility.accessfu.skip_empty_images Toggle to "false" Samsung Galaxy Tab 2 7" cyanogenmod 11 Firefox 36.0.4
(In reply to Dennis Murdock from comment #59) > How I got around the pesky black placeholders. At least it works for me. > > about:config > accessibility.accessfu.skip_empty_images > > Toggle to "false" > > Samsung Galaxy Tab 2 7" > cyanogenmod 11 > Firefox 36.0.4 Whoops! Errantly left out second config setting to Toggle. browser.display.show_image_placeholders Also Toggle to false.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: