Closed
Bug 370629
Opened 18 years ago
Closed 18 years ago
Large Images rescale to nothing - cannot be displayed
Categories
(Core :: General, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jmjjeffery, Assigned: sharparrow1)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
dbaron
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•18 years ago
|
Reporter | ||
Updated•18 years ago
|
Version: unspecified → Trunk
Comment 1•18 years ago
|
||
A reduced testcase would probably be quite useful for this bug
Blocks: pixels
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
Keywords: regression
Updated•18 years ago
|
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general
Reporter | ||
Comment 2•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
If loaded with auto-scaling on this image will not be visible. The width will be (theoretically) 13 pixel.
Comment 5•18 years ago
|
||
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]
Assignee | ||
Comment 6•18 years ago
|
||
Do you know exactly when this regressed?
Comment 7•18 years ago
|
||
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.
Reporter | ||
Comment 8•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
(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•18 years ago
|
||
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•18 years ago
|
||
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.
Assignee | ||
Comment 14•18 years ago
|
||
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.
Attachment #255612 -
Flags: review?(dbaron)
Updated•18 years ago
|
Flags: in-testsuite?
Comment 15•18 years ago
|
||
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?
Attachment #255612 -
Flags: review?(dbaron) → review+
Comment 16•18 years ago
|
||
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" ?
Assignee | ||
Comment 17•18 years ago
|
||
(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.
Assignee | ||
Updated•18 years ago
|
Attachment #255612 -
Flags: superreview?(roc)
Attachment #255612 -
Flags: superreview?(roc) → superreview+
Assignee | ||
Comment 18•18 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 19•18 years ago
|
||
this definitely should have landed with a reftest, imho
Comment 20•18 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070218 Minefield/3.0a3pre ID:2007021815 [cairo] verified/fixed
Assignee | ||
Comment 21•18 years ago
|
||
(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).
Updated•18 years ago
|
Status: RESOLVED → VERIFIED
Comment 22•14 years ago
|
||
Is the fix already pushed? I still can not see the image from comment #4.
You need to log in
before you can comment on or make changes to this bug.
Description
•