370629 - Large Images rescale to nothing - cannot be displayed

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070216 Minefield/3.0a3pre Firefox
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070216 Minefield/3.0a3pre Firefox

Click the url and note that the large image is resized into 'nothing', disappears and cannot be displayed. 

Its not just this url, but any have large images hosted on various image host url's do not display.

Reproducible: Always

Steps to Reproduce:
1. Go to url
2. Note that the large image starts to display then disappears with note: Image has been resized to fit screen, click to enlarge.
3. Nothing to click, its collapsed into nothing.
Actual Results:  
Nothing to click to re-enlarge/display the image.

Expected Results:  
Image should be expandable

Some large images will collapse/resize into a stretched/wrapped image, then on click to resize really gets stretched out of shape. 

This happened after the landing of:
https://bugzilla.mozilla.org/show_bug.cgi?id=177805

Comment 1

[Ryan VanderMeulen [:RyanVM]]

A reduced testcase would probably be quite useful for this bug

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

Its been discovered that turning off javascript allows the full-size to load.  As expected I would guess, no resizing takes place at all in fact.

I have no idea how to create a reduced test case.. someone will have to help out.

Comment 3

[Volkmar Kostka]

Basically there are two problems involved:
a) auto-scaling for very tall images.
If the ratio of the image is very far off (e.g. 400x30000) then the automatic rescaling will result in a width of zero. 30000/600 = Limiting this to a minimum width like 100 pixel prevents this.
Example image:
http://www.mrc-lmb.cam.ac.uk/dhoworth/f208c50af8a68669c364c22849f1d1de.png
Don't know how long this image is available.

b) fault in JavaScript
This code is taken from an imageshack page:
var actualWidth = 1280;var actualHeight = 800; ... what.width = tableWidth(); what.height = (actualHeight/actualWidth) * what.width;
...
function tableWidth() { return windowWidth()-100; }
function windowWidth() { if (navigator.appName=="Netscape") return window.innerWidth; return document.body.offsetWidth; }

The height property is calculated to zero. If the code is changed to:
what.height = actualHeight/(actualWidth * what.width);
the scaling works as intended. A regression in the JS engine?

Comment 4

[Volkmar Kostka]

Attachment: Very tall image (820x36654)

If loaded with auto-scaling on this image will not be visible. The width will be (theoretically) 13 pixel.

Comment 5

[Volkmar Kostka]

Oops. Forgot to mention the imageshack page.
http://img293.imageshack.us/my.php?image=tosca07yg8.png

My browser:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070217 Minefield/3.0a3pre ID:2007021704 [cairo]

Comment 6

[Eli Friedman]

Do you know exactly when this regressed?

Comment 7

[Volkmar Kostka]

No. I do not paid attention to this until i found the discussion at mozillazine.

Tested for the JS issue:
Works:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070206 Minefield/3.0a2pre

Fails:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070207 Minefield/3.0a3pre

Did not check every hourly.

Comment 8

[Jim Jeffery not reading bug-mail 1/2/11]

I'm pretty sure it regressed with bug noted in comment #0 
[url=http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaSourceWin&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-06+00%3A00%3A01&maxdate=2007-02-07+23%3A59%3A59&cvsroot=%2Fcvsroot]Bonsai[/url]

Comment 9

[Volkmar Kostka]

Don't think this is related to the units bug.
What has "what.height = (actualHeight/actualWidth) * what.width;" (which fails) and "what.height = actualHeight/(actualWidth * what.width);" (which works) with the units bug to do?
Unless something changed unintentionally in the JS engine i do not see anything related.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #9)
> What has "what.height = (actualHeight/actualWidth) * what.width;" (which
> fails) and "what.height = actualHeight/(actualWidth * what.width);" (which
> works) with the units bug to do? Unless something changed unintentionally in
> the JS engine i do not see anything related.

"(actualHeight/actualWidth) * what.width;" and "actualHeight/(actualWidth * what.width);" are not the same calculation. The latter most likely "works" only because it usually results in a much smaller number given the constraints.

Nothing in the JS engine changed in the regression window.

Comment 11

[Volkmar Kostka]

You are right. I misinterpreted the results i got and i definitely did the change in the JS wrong.

I rechecked what i did and found that if i add a height property to the image it always works, regardless which initial value i set for the height property in DOMi. Without the height property the image seems to be always sized to a height of zero.
There is nothing wrong with the JS engine.

Comment 12

[Volkmar Kostka]

Additional info:
It also works if i remove the width property from DOMi. So either both properties must be present in the code or none if you want to scale the image with JS.

Comment 13

[Eli Friedman]

Okay, figured it out; taking.

Comment 14

[Eli Friedman]

Attachment: Patch

Wonderful bug; the computed height code multiplied 1050 pixels (or whatever it was) by 720 pixels and divided the result by 733 pixels.  The final answer? -596 pixels!

The only reason nobody was running into this before is that number of app units per pixel increased, and 4000x4000 pixel images are rare.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 255612 [details] [diff] [review]
Patch

r=dbaron.

But what is this going to do in cases where the final result has integer overflow?  Do we need another bug to follow up?

Comment 16

[Volkmar Kostka]

Just curious: Why does it work when both or neither width and height properties are there? Does the bug only trigger if only one dimension is "auto" ?

Comment 17

[Eli Friedman]

(In reply to comment #15)
> (From update of attachment 255612 [details] [diff] [review])
> r=dbaron.
> 
> But what is this going to do in cases where the final result has integer
> overflow?  Do we need another bug to follow up?

Bug 265084?  There isn't much else we can do...

(In reply to comment #16)
> Just curious: Why does it work when both or neither width and height properties
> are there? Does the bug only trigger if only one dimension is "auto" ?

That's right.  When both dimensions are auto or both dimensions are fixed, we don't do the calculation to figure out the ratio.

Comment 18

[Eli Friedman]

Checked in.

Comment 19

[Robert Sayre]

this definitely should have landed with a reftest, imho

Comment 20

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070218 Minefield/3.0a3pre ID:2007021815 [cairo]

verified/fixed

Comment 21

[Eli Friedman]

(In reply to comment #19)
> this definitely should have landed with a reftest, imho
> 

Added reftests.  (I wasn't sure if it was the policy to recommend all checkins include reftests).

Comment 22

[Volkmar Kostka]

Is the fix already pushed? I still can not see the image from comment #4.