Rollover images disappear on www.remisehaarlem.nl image map

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: frodo, Assigned: justin.lebar+bug)

Tracking

({regression})

13 Branch
x86
All
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox14- affected, firefox15- affected, firefox16- affected)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 630933 [details]
image-truncated-corrupted.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2

Steps to reproduce:

Upgrade to Firefox 13 and visited www.remisehaarlem.nl. On the homepage there is an image map (bird eye) which changes images when you hover above certain areas of the image.




Actual results:

The image which should show, doesn't show.

Firefox tells me: "Image corrupted or truncated". It doesn't happen all the time, sometimes you have to hover a little bit or switch pages a bit. 

It's not always the same image that gets "corrupted or truncated", as you can see in the attach screenshot.

This works in Firefox 12 and downward, this works in ie6-ie10, this works in Opera, Safari etc. This works in development (localhost) and production (online).

I've tested this on 2 macs (10.6 and 10.7) and windows XP (virtual box).


Expected results:

The images(s) should have been shown.

What I suspect is that there is something wrong with caching in combination with javascript. Because The first time the image is downloaded it is shown correctly, when it is retrieved from cache it doesn't always work.


Some technical background:

- images are served from assets.remsisehaarlem.nl and www.remisehaarlem.nl
- nginx is webserver with future expiries
- gzip is enabled
(Reporter)

Comment 1

6 years ago
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)
(Reporter)

Comment 4

6 years ago
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.
(Reporter)

Comment 6

6 years ago
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
Blocks: 731419
(Assignee)

Comment 8

6 years ago
As I bisect it, e372bfbf40c5 (bug 733872) is the first bad revision.  No idea why that might be, but I checked a few times...
Blocks: 733872
No longer blocks: 731419
That's .. really odd.
tracking-firefox14: --- → ?
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
Component: ImageLib → XPConnect
Keywords: regression
QA Contact: imagelib → xpconnect
I wait with bated breath to find out how that broke image rendering.
Ms2ger, can you investigate?

Comment 12

6 years ago
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
(Assignee)

Comment 13

6 years ago
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.

Comment 14

6 years ago
About #2 regression, setting image.mem.discardable = false helps

Updated

6 years ago
Blocks: 731419

Comment 15

6 years ago
I filed Bug 763935 about #1 regression
(Reporter)

Comment 16

6 years ago
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
(Assignee)

Updated

6 years ago
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
(Assignee)

Comment 20

6 years ago
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)

Updated

6 years ago
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
(Assignee)

Comment 23

6 years ago
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.
(Assignee)

Comment 25

6 years ago
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.
(Reporter)

Comment 26

6 years ago
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.
(Assignee)

Comment 27

6 years ago
> 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.
(Reporter)

Comment 28

6 years ago
Firefox Aurora: Works (with flicker)
Firefox Nightly: Doesn't work (Image corrupted or truncated)
(Assignee)

Comment 29

6 years ago
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/...".
(Assignee)

Comment 31

6 years ago
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?
(Reporter)

Comment 32

6 years ago
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.
(Assignee)

Comment 33

6 years ago
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.
(Assignee)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Resolution: FIXED → WORKSFORME

Updated

6 years ago
tracking-firefox14: + → -
tracking-firefox15: + → -
tracking-firefox16: + → -
You need to log in before you can comment on or make changes to this bug.