Closed Bug 97695 Opened 24 years ago Closed 21 years ago

Images with percent (%) width/height nested inside an inline element should scale relative to containing block

Categories

(Core :: Layout: Block and Inline, defect, P1)

Product:
Core
Component:
Layout: Block and Inline
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.7alpha

People

(Reporter: nakedchaos, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: testcase, Whiteboard: [reflow-refactor][patch])

Attachments

(3 files, 2 obsolete files)

testcase, html file
549 bytes, text/html
Details
testcase, gif image to go with html - save as b1.gif
418 bytes, image/gif
Details
patch
1.81 KB, patch
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 Row of buttons along top of page is displayed incorrectly. They are variable-sized eg. 10% of windth, 14% of width. Mozilla handles this incorrectly. Reproducible: Always Steps to Reproduce: 1.visit http://linkx.spinrx.com/cgi-bin/advancesailing/index.html 2. Compare with other browsers 3. Email me if you don't see what I'm talking about Actual Results: The images are scrunched in mozilla. Expected Results: Images should not be scrunched.
Confirming, simplified test case to follow. This only happens if the images are inside links. It looks like, in that instance, the percentage width being used for each subsequent image is being calculated as a fraction of the remaining page width, rather than total page width.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Toolbar at 2" down across top should stretch across the page as it does in IE or NS but gets scrunched to the left instead → Images with %sizes inside links not scaling properly
Attached file testcase, html file —
is this still happening in recent builds?
Comment on attachment 47879 [details] testcase, gif image to go with html - save as b1.gif Yes, I'm still seeing it in 2001091508 win32
Attachment #47879 - Attachment description: testcase, gif image to go with html → testcase, gif image to go with html - save as b1.gif
Apologies for the spam, should have checked this before adding the last comment. Still present in 2001092403, win98SE, also.
*** Bug 101926 has been marked as a duplicate of this bug. ***
Please see http://www.usahistory.com/noframe.htm for another testcase from my duped bug 101926. The screenshot there is attachment 51055 [details]. This is 4xp and occurs on Linux as well. ------- Additional Comments From Christopher Hoess 2001-09-27 08:33 ------- The HTML 4.01 spec says of percentage image widths "Note that lengths expressed as percentages are based on the horizontal or vertical space currently available," a rather ambiguous definition. However, CSS width (which applies to replaced elements) says that percentages are calculated in terms of the containing block. Since HTML width="" is supposed to be replaced by the CSS equivalent, the change (fix?) proposed here makes sense...
Keywords: 4xp
OS: Windows 98 → All
Summary: Images with %sizes inside links not scaling properly → Images with %sizes inside links should scale relative to containing block
*** Bug 115544 has been marked as a duplicate of this bug. ***
to attinasi -- this is not table-specific
Assignee: karnaze → attinasi
*** Bug 119581 has been marked as a duplicate of this bug. ***
Nominating; it should be an easy fix. Bug 119581 also has a testcase w/ no table.
Keywords: mozilla0.9.8
Target Milestone: --- → mozilla1.0.1
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1 I will be pulling bugs from 'future' milestones when scheduling later work.
Priority: -- → P1
Target Milestone: mozilla1.0.1 → Future
It does not have to be within links. Try www.leifjensen.com. This works always (almost always, might need a reload) in NS 4.77/4.78. I can't make it load the picture at all in any Mozilla 0.9.x/1.0x nor NS6.x.
Konqueror 2.2.2 loads it nicely.
mozilla1.0 -> mozilla1.01 There's a testcase with no tables in my dup of this. We're definitely laying this out incorrectly.
Keywords: mozilla1.0 → mozilla1.0.1
I was hoping this bug was fixed in Mozilla 1.0rc2, but it's still there.
I noticed a comment that this was only within links. I'm not exactly sure about that phrase, but I have it also with: <img src=..... width=80% height=80%>. (Try www.leifjensen.com!)
Attached patch Patch v1.0 (obsolete) — — Splinter Review
Okay, this patch "works" but I'm thinking it is a little late in the game to fix it here (though I may be wrong). So I've debugged this last night and it appears that when we create our nsHTMLReflowState for an image frame, we're already passing in the wrong computed width of the containing block. The correct fix IMO would be probably in nsLineLayout::ReflowFrame() around here: http://lxr.mozilla.org/mozilla/source/layout/html/base/src/nsLineLayout.cpp?rev=3.135#979 or possibly before we get that far. When we get the containing block's width there, it keeps shrinking every time. That's about as far as I got last night. I'll try investigating more later on.
The real problem is what buster introduced in revision 3.81 of nsLineLayout.cpp. We need to figure out what he was really trying to fix.
So bug 38396 is really a bug about one of the fundamental flaws in the layout engine -- that we try to do min-size and pref-size calculations using the same Reflow method that does layout. It looks like buster fixed it first by breaking percentage widths on images, and then by implementing them incorrectly. Not that that really helped (see bug 115688 / bug 107873).
Comment on attachment 87711 [details] [diff] [review] Patch v1.0 This is going to break stuff like absolutely positioned elements, or anything that really *needs* to pass in the computed height/width rather than letting them be calculated (or is nsLineLayout::ReflowFrame the only caller of that constructor?!).
Attachment #87711 - Flags: needs-work+
*** Bug 159666 has been marked as a duplicate of this bug. ***
attinasi->dbaron, since he produced a patch Nominating for 1.3 milestone -> ---
Assignee: attinasi → dbaron
Keywords: mozilla1.0.1 → mozilla1.3
Hardware: PC → All
Target Milestone: Future → ---
I didn't produce a patch. I marked a patch as "needs work".
Severity: normal → major
Whiteboard: [reflow-refactoring]
Oops, misread. Feel free to reassign. Attinasi seemed a bad choice...
Summary: Images with %sizes inside links should scale relative to containing block → Images with % width/height nested inside an inline element should scale relative to containing block
->block & inline
Assignee: dbaron → block-and-inline
Component: Layout → Layout: Block & Inline
QA Contact: petersen → ian
I think I want this, actually.
Assignee: block-and-inline → dbaron
Whiteboard: [reflow-refactoring] → [reflow-refactor]
*** Bug 110358 has been marked as a duplicate of this bug. ***
Summary: Images with % width/height nested inside an inline element should scale relative to containing block → Images with percent (%) width/height nested inside an inline element should scale relative to containing block
Reassigning as dupe seems fine, but comments are not being copied across, is this a bugzilla bug? anyway here are my comments copied across: is work on this proceeding?? I was hoping to roll out a site using % and was just wondering... http://www.peepo.com/w3/svg-jpg/svg-jpg.html looks damn silly your way. thanks
Blocks: 194804
*** Bug 209065 has been marked as a duplicate of this bug. ***
It turns out that the IMG or IFRAME doesn't need to be inside an anchor to cause the bug. It also happens if it's simply inside a <span>...</span>
Yes, the bug summary already notes that the image needs to be within an inline.
Congratulations !! Mozilla 1.4 works with my homepage placing a relative picture as it should.
*** Bug 221398 has been marked as a duplicate of this bug. ***
Keywords: testcase
Attached patch patch (obsolete) — — Splinter Review
I think this is the right fix, and it doesn't regress bug 38396.
Status: NEW → ASSIGNED
Whiteboard: [reflow-refactor] → [reflow-refactor][patch]
Target Milestone: --- → mozilla1.7alpha
Attachment #135953 - Flags: superreview?(roc)
Attachment #135953 - Flags: review?(roc)
Comment on attachment 135953 [details] [diff] [review] patch sure
Attachment #135953 - Flags: superreview?(roc)
Attachment #135953 - Flags: superreview+
Attachment #135953 - Flags: review?(roc)
Attachment #135953 - Flags: review+
Is there a reason we no longer need to pass "reason" the the new reflow state?
Oh, right, I added |reason| back.
Attached patch patch — — Splinter Review
Attachment #135953 - Attachment is obsolete: true
Blocks: 226954
could somebody check this in, if it works?
It will get checked in when the tree opens for 1.7alpha. Patience, young grasshopper.
Fix checked in to trunk, 2003-12-18 21:41 -0800.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
working fine, BuildID 2003121823 Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20031218 checked with http://www.peepo.com/w3/svg-jpg/svg-jpg.html failed yesterday, ok now Is it too risky to fix this in the branch?
Flags: blocking1.6?
perhaps I should have put this on the branch a few weeks ago, but I'd rather not at this point. We've shipped many releases with this and one more won't hurt too much. It will be fixed in 1.7.
Flags: blocking1.6? → blocking1.6-
anyone figure out if this fix cause the regression in http://bugzilla.mozilla.org/show_bug.cgi?id=230332 ?
It probably did, but our current rendering looks correct (and the old rendering rather broken)...
Could someone who was involved with this bug please take a look at bug 239778 and let us know if the fix for this bug caused the regression in that one? It began at the same time this one was fixed, and I can't find a better candidate for the cause. thanks!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: