Closed Bug 279579 Opened 21 years ago Closed 21 years ago

Absolutely positioned image shrinks in size when viewport is smaller than image

Categories

(Core :: Layout: Positioned, defect)

Product:
Core
Component:
Layout: Positioned
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: MatsPalmgren_bugz)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(3 files, 1 obsolete file)

img for testcase
10.66 KB, image/gif
Details
Testcase
278 bytes, text/html
Details
Patch rev. 1
2.17 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
See upcoming testcase. An absolutely positioned image, like: <img src="bk1.gif" style="position: absolute; top: 0pt; left: 0pt;"> that is larger than the viewports gets shrinked in current trunk builds. That should not happen, since right and bottom are auto. The bug does not occur in: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041205 Firefox/1.0+ 8:00am But the bug does occur in: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a6) Gecko/20041206 Firefox/1.0+ 8:04am Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-12-05+07%3A00%3A00&maxdate=2004-12-06+08%3A00%3A00&cvsroot=%2Fcvsroot I suspect "Patch rev. 10" from bug 201897 might be the cause of this bug, that's why I cc-ed you Mats.
Attached image img for testcase —
Attached file Testcase (obsolete) —
To reproduce the bug: Resize the window till the viewport is smaller than the image, the image should not shrink to fit in the viewport, but it does that in current trunk builds.
Comment on attachment 172253 [details] Testcase ><HTML><HEAD><TITLE>Testcase bug - Absolutely positioned image shrinks in size when viewport is smaller than image</TITLE></HEAD> ><BODY> ><IMG style="position: absolute; top: 0pt; left: 0pt;" src="https://bugzilla.mozilla.org/attachment.cgi?id=172252"/> ></BODY></HTML>
Attached file Testcase —
Sorry, typo in the previous testcase. I tried to repair it, but that didn't work.
Attachment #172253 - Attachment is obsolete: true
Keywords: regression, testcase
This is definitely a regression from the followup fix for bug 201897. The problem is that this code clobbers kidReflowState.mComputedMaxWidth to be no more than the availWidth. But images actually follow the mComputedMaxWidth, unlike some other frames, apparently. So the image sizes itself to be no wider than the computed max width. Note that the MEW for images is just the computed width, whatever that is, so the SHRINK_TO_FIT_MEW thing is never triggered. Also note that this code is possibly setting mComputedMaxWidth to be less than mComputedWidth (which seems wrong; I thought I'd commented on that in bug 201897). To mats. We really want to fix this for 1.8...
Assignee: nobody → mats.palmgren
Severity: normal → major
Flags: blocking1.8b?
OS: Windows 2000 → All
Hardware: PC → All
Oops, nice catch Martijn, thanks.
Status: NEW → ASSIGNED
Attached patch Patch rev. 1 — — Splinter Review
This take care of the replaced elements regression (CSS 10.3.7 does not apply), (the code path is now exactly the same as before bug 201897 for them).
Comment on attachment 172273 [details] [diff] [review] Patch rev. 1 Looks reasonable. Land it. ;)
Attachment #172273 - Flags: superreview+
Attachment #172273 - Flags: review+
(In reply to comment #5) > Also note that this code is possibly setting mComputedMaxWidth to be less than > mComputedWidth (which seems wrong; I thought I'd commented on that in bug > 201897). I think I did address it: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsAbsoluteContainingBlock.cpp&mark=567-570#560 which can result in mComputedMaxWidth < mComputedWidth only if mComputedMinWidth > mComputedMaxWidth but I think David pointed out somewhere that 'min-width' should have priority over 'max-width'? Or did you mean some other code?
In that block (SHRINK_TO_FIT_AVAILWIDTH) and during the first reflow kidReflowState.mComputedWidth is always NS_SHRINKWRAPWIDTH (and was so also before bug 201897). I'm guessing this is one of the reasons for the remaining problem (bug 275179) - we shouldn't use an unconstrained mComputedWidth and use a "fake" mComputedMaxWidth to limit the reflow, but I don't dare change it at this point without *a lot* of thinking/testing. I hope you're not too dissappointed if I deflect that issue to bug 275179 ... I'll check in the current patch, which is low risc.
Checked in 2005-01-24 13:45 PDT. -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Oh, definitely. I'm not suggesting we try to fix that now. Doing it in the 1.9 timeframe, esp. if the reflow refactoring branch lands, sounds like a much better idea.
Verified. (In reply to comment #6) > Oops, nice catch Martijn, thanks. Well, I didn't discover this bug, it was Brent Silby in bug 234233, comment 39.
Status: RESOLVED → VERIFIED
*** Bug 277644 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: