Let me clarify what I mean with "this works" It means www.remisehaarlem.nl + the image map hover works all major and older browsers except for FF 13.
Component: General → Networking: HTTP
QA Contact: general → networking.http
Could you try to find a regression range for this ? https://github.com/mozilla/mozregression/ helps with this.
I get the js console corrupted or truncated messages even with ff 10. (the oldest I have available)
I tried to run a regression range for this, all gave the same problem (which is weird because the test also includes ff 12, which doesn't have these problems): test with my current user account (osx 10.7) mozregression --bad=2012-06-05 --good=2012-04-23 --app=firefox mozregression --bad=2012-04-24 --good=2012-04-1 --app=firefox test with freshly created user account (osx 10.7) mozregression --bad=2012-06-08 --good=2012-04-1 --app=firefox I just retested it with ff 3.6.15, site works (empty cache) I just retested it on another mac with osx 10.6 and firefox 12 no problems (empty cache)
You can't use the release date as starting point since a release branches earlier from the trunk builds that mozregression is using. Example: The trunk is currently Firefox16 and there are currently branches for Firefox 14 and Firefox15. note: mozregression starts the test build with an empty and new Firefox profile unless specified.
I reran the tests, with results: Last good nightly: 2012-03-11 First bad nightly: 2012-03-12 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6737b6762eb8&tochange=5ec9524de1af
no networking change in that pushlog but an imagelib one with the fix for bug 731419
Status: UNCONFIRMED → NEW
Component: Networking: HTTP → ImageLib
Ever confirmed: true
OS: Mac OS X → All
QA Contact: networking.http → imagelib
As I bisect it, e372bfbf40c5 (bug 733872) is the first bad revision. No idea why that might be, but I checked a few times...
That's .. really odd.
tracking-firefox14: --- → ?
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
Component: ImageLib → XPConnect
QA Contact: imagelib → xpconnect
I wait with bated breath to find out how that broke image rendering.
Ms2ger, can you investigate?
Umm i have different regression range and there are 2 regression window.: #1 :Error(Warning) "Image corrupt or truncated", BUT image does not disappear #2 :Error "Image corrupt or truncated", AND image disappears and replaced text "Birdseye" finally. Error: Image corrupt or truncated: http://www.remisehaarlem.nl/kontenta_assets/photos/full/416/blok7.jpg Source file: http://www.remisehaarlem.nl/kontenta_assets/photos/full/416/blok7.jpg and so on #1 regression window(m-c) No Error: http://hg.mozilla.org/mozilla-central/rev/1107ae661cc6 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101026 Firefox/4.0b8pre ID:20101027180940 Error(Warning) "Image corrupt or truncated", BUT image does not disapear http://hg.mozilla.org/mozilla-central/rev/fe4898e97431 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101028 Firefox/4.0b8pre ID:20101028042244 Pushlpg: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1107ae661cc6&tochange=fe4898e97431 Suspected: Bug 607882 #2 RegrssionWindow(m-i) Error "Image corrupt or truncated", BUT image does not disappear http://hg.mozilla.org/mozilla-central/rev/c33438bd5706 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120311 Firefox/13.0a1 ID:20120311005632 Error "Image corrupt or truncated",AND image disappears and replaced text "Birdseye" finally. http://hg.mozilla.org/mozilla-central/rev/5ec9524de1af Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120312 Firefox/13.0a1 ID:20120312031136 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c33438bd5706&tochange=5ec9524de1af #2 RegrssionWindow(m-i) Error "Image corrupt or truncated", BUT image does not disappear http://hg.mozilla.org/integration/mozilla-inbound/rev/d09b4e60bb09 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120309 Firefox/13.0a1 ID:20120309215132 Error "Image corrupt or truncated", AND image disappears and replaced text "Birdseye" finally. http://hg.mozilla.org/integration/mozilla-inbound/rev/9e3fc01c33bc Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120309 Firefox/13.0a1 ID:20120309232632 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d09b4e60bb09&tochange=9e3fc01c33bc Suspected: Bug 731419
FWIW I was looking only at error #1 (error in the console). I really did see the error with e372bfbf40c5 (just tested again); maybe this happens intermittently, and we somehow tickle the error into happening more often. Or maybe it has to do with the fact that I was using my own debug build, instead of a build from tinderbox. I did have to move my mouse over the images for a while (30s) before I got the error.
About #2 regression, setting image.mem.discardable = false helps
I filed Bug 763935 about #1 regression
I created a couple of test which might be helpful. Using the Loop links gives the quickest results. http://presentatie.medid.nl/firefox-bug-762460/
As always, thanks a lot for your help, Alice!
Since this is a suspected regression from bug 731419, sending over to you Justin to investigate.
Assignee: nobody → justin.lebar+bug
Summary: Image corrupt our truncated → Rollover images disappear on www.remisehaarlem.nl image map
Updating version / platform, as I can reproduce this in Trunk w/ Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0a1 Built from http://hg.mozilla.org/mozilla-central/rev/b1a0fb2bdbf7 Also, this probably belongs back in ImageLib, per comment 14 & comment 18, right? (I suspect the error console message's apparent connection to the XPConnect cset e372bfbf40c5 was coincidental, as jlebar suggests in comment 13.)
Component: XPConnect → ImageLib
QA Contact: xpconnect → imagelib
Hardware: x86 → All
Version: 13 Branch → Trunk
I've been investigating bug 763593, and I think I understand what's going on there; see bug 763593 comment 8. This is likely the same bug.
Component: ImageLib → XPConnect
Hardware: All → x86
Version: Trunk → 13 Branch
Assignee: justin.lebar+bug → nobody
Component: XPConnect → ImageLib
Tracking this regression, do we need to look into backing out bug 731419 or will a forward fix be investigated for this and bug 763593?
status-firefox14: --- → affected
status-firefox15: --- → affected
status-firefox16: --- → affected
tracking-firefox14: ? → +
tracking-firefox15: ? → +
tracking-firefox16: ? → +
Joe I'm assigning to you to determine what next steps should be.
Assignee: nobody → joe
The next steps are landing bug 763593 and seeing if that solves the problem. I haven't been able to reproduce this problem on machine, but if anyone wants to use the try builds from that bug, they're welcome to.
Assignee: joe → justin.lebar+bug
(In reply to Justin Lebar [:jlebar] from comment #23) > The next steps are landing bug 763593 and seeing if that solves the problem. > I haven't been able to reproduce this problem on machine, but if anyone > wants to use the try builds from that bug, they're welcome to. We're getting pretty close to FF14's end game. I think it makes the most sense to back out bug 731419 out of caution.
I already backed out the relevant code for Beta 14, in bug 763593. Or at least, I think that the code I backed out should fix this bug; I would really appreciate some help from someone who can reproduce.
I used Firefox from the beta channel and it seems to fix "Image corrupted or truncated" However it introduces a new visual hiccup, which isn't present in any other browser, also not firefox 3.6.15. When you have the following HTML <div style="width: 100px; height: 100px; background: transparent url("bg.jpg") top left no-repeat;"> <img src="fg1.jpg" height="100" width="100" /> </div> And you change the src value of the image the background "bg.jpg" is visible for a really short amount of time (during the switch). I setup this technique on www.remisehaarlem.nl to give users some info about the problem in case Firefox has problems with the image swapping.
> And you change the src value of the image the background "bg.jpg" is visible for a really > short amount of time (during the switch). That's likely due to lots of changes we've made in the meantime to make image decoding asynchronous. IOW, I doubt it's a regression per se. Feel free to file a bug, but I would not get your hopes up for a quick fix. I would appreciate if you'd test Firefox Aurora or Nightly on your site. Aurora and Nightly have a different fix than Beta.
Firefox Aurora: Works (with flicker) Firefox Nightly: Doesn't work (Image corrupted or truncated)
Hm, if you're on the latest nightly and aurora, the behavior should be the same. What's the build identifier of your Aurora build? See about:buildconfig, where it says "Built from http://hg.mozilla.org/...".
Nightly: Built from http://hg.mozilla.org/mozilla-central/rev/c3190d715044 Aurora: Built from http://hg.mozilla.org/releases/mozilla-aurora/rev/cc068ba06631
Hm. Those both have the same exact patch, from bug 763593. Are you positive you're not seeing some kind of intermittent behavior? Also, when you see "image corrupt or truncated" in nightly, do you see the error without any problems in the webpage, or do you see the error and some user-visible effects?
I'm 100% positive. Today I redid the test a couple of times with c3190d715044, it is exactly the same as why I submitted this bug. After that I updated nightly to: http://hg.mozilla.org/mozilla-central/rev/5c07a681371d - it seems to work, no messages about images corrupt or truncated. But now (I don't know if this intentional for testing purpose) It's very slow, because Nightly downloads images with every hover again and again from the webserver.
The fact that Nightly magically fixed itself suggests to me that this bug is not deterministic, but in fact appears and disappears based on some condition. That is, it seems unlikely that the latest nightly actually fixed this problem for you. But I don't have time to dig into this further, especially given that we don't have a handle on whether this bug is in fact intermittent or deterministic, and given that it seems to be working for you on all branches, at the moment. The issue you're seeing in nightly is separate from this bug. Without investigating it, my guess is that if Nightly is *actually* re-fetching images from the network, it's doing so intentionally, perhaps because of the site's cache headers. But feel free to file a separate bug. I'm closing this since the reporter says it's fixed on all branches. If we have follow-ups, let's track them in separate bugs, please.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
tracking-firefox14: + → -
tracking-firefox15: + → -
tracking-firefox16: + → -
You need to log in before you can comment on or make changes to this bug.