762460 - Rollover images disappear on www.remisehaarlem.nl image map

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[frodo]

Attachment: 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

Comment 1

[frodo]

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.

Comment 2

[Matthias Versen [:Matti]]

Could you try to find a regression range for this ?
https://github.com/mozilla/mozregression/ helps with this.

Comment 3

[Patrick McManus [:mcmanus]]

I get the js console corrupted or truncated messages even with ff 10. (the oldest I have available)

Comment 4

[frodo]

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)

Comment 5

[Matthias Versen [:Matti]]

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.

Comment 6

[frodo]

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

Comment 7

[Matthias Versen [:Matti]]

no networking change in that pushlog but an imagelib one with the fix for bug 731419

Comment 8

[Justin Lebar (not reading bugmail)]

As I bisect it, e372bfbf40c5 (bug 733872) is the first bad revision.  No idea why that might be, but I checked a few times...

Comment 9

[Boris Zbarsky [:bzbarsky]]

That's .. really odd.

Comment 10

[Joe Drew (not getting mail)]

I wait with bated breath to find out how that broke image rendering.

Comment 11

[Bobby Holley (:bholley)]

Ms2ger, can you investigate?

Comment 12

[Alice0775 White]

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

Comment 13

[Justin Lebar (not reading bugmail)]

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

[Alice0775 White]

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

Comment 15

[Alice0775 White]

I filed Bug 763935 about #1 regression

Comment 16

[frodo]

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/

Comment 17

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

As always, thanks a lot for your help, Alice!

Comment 18

[Alex Keybl [:akeybl]]

Since this is a suspected regression from bug 731419, sending over to you Justin to investigate.

Comment 19

[Daniel Holbert [:dholbert]]

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.)

Comment 20

[Justin Lebar (not reading bugmail)]

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.

Comment 21

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

Joe I'm assigning to you to determine what next steps should be.

Comment 23

[Justin Lebar (not reading bugmail)]

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.

Comment 24

[Alex Keybl [:akeybl]]

(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.

Comment 25

[Justin Lebar (not reading bugmail)]

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.

Comment 26

[frodo]

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.

Comment 27

[Justin Lebar (not reading bugmail)]

> 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.

Comment 28

[frodo]

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

Comment 29

[Justin Lebar (not reading bugmail)]

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/...".

Comment 30

[frodo]

Nightly: Built from http://hg.mozilla.org/mozilla-central/rev/c3190d715044
Aurora: Built from http://hg.mozilla.org/releases/mozilla-aurora/rev/cc068ba06631

Comment 31

[Justin Lebar (not reading bugmail)]

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?

Comment 32

[frodo]

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.

Comment 33

[Justin Lebar (not reading bugmail)]

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.