Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 97695 - Images with percent (%) width/height nested inside an inline element should scale relative to containing block
: Images with percent (%) width/height nested inside an inline element should s...
: testcase
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: P1 major with 3 votes (vote)
: mozilla1.7alpha
Assigned To: David Baron :dbaron: ⌚️UTC-7
: Hixie (not reading bugmail)
: Jet Villegas (:jet)
: 101926 110358 115544 119581 159666 209065 221398 (view as bug list)
Depends on:
Blocks: 194804 217817 226954
  Show dependency treegraph
Reported: 2001-08-30 16:48 PDT by Will Small
Modified: 2014-04-26 03:26 PDT (History)
22 users (show)
dbaron: blocking1.6-
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase, html file (549 bytes, text/html)
2001-08-31 15:18 PDT, gavin long
no flags Details
testcase, gif image to go with html - save as b1.gif (418 bytes, image/gif)
2001-08-31 15:19 PDT, gavin long
no flags Details
Patch v1.0 (882 bytes, patch)
2002-06-14 12:54 PDT, Christopher Aillon (sabbatical, not receiving bugmail)
no flags Details | Diff | Splinter Review
patch (1.80 KB, patch)
2003-11-19 14:22 PST, David Baron :dbaron: ⌚️UTC-7
roc: review+
roc: superreview+
Details | Diff | Splinter Review
patch (1.81 KB, patch)
2003-11-19 23:15 PST, David Baron :dbaron: ⌚️UTC-7
no flags Details | Diff | Splinter Review

Description Will Small 2001-08-30 16:48:24 PDT
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:
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.
Comment 1 gavin long 2001-08-31 15:17:21 PDT
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.
Comment 2 gavin long 2001-08-31 15:18:08 PDT
Created attachment 47877 [details]
testcase, html file
Comment 3 gavin long 2001-08-31 15:19:07 PDT
Created attachment 47879 [details]
testcase, gif image to go with html - save as b1.gif
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2001-09-25 09:50:19 PDT
is this still happening in recent builds?
Comment 5 gavin long 2001-09-25 15:10:39 PDT
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
Comment 6 gavin long 2001-09-25 15:15:26 PDT
Apologies for the spam, should have checked this before adding the last comment.
  Still present in 2001092403, win98SE, also.
Comment 7 Christopher Aillon (sabbatical, not receiving bugmail) 2001-09-28 08:13:13 PDT
*** Bug 101926 has been marked as a duplicate of this bug. ***
Comment 8 Christopher Aillon (sabbatical, not receiving bugmail) 2001-09-28 08:16:53 PDT
Please see 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...
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2001-12-16 21:28:06 PST
*** Bug 115544 has been marked as a duplicate of this bug. ***
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2001-12-16 21:29:03 PST
to attinasi -- this is not table-specific
Comment 11 Christopher Aillon (sabbatical, not receiving bugmail) 2002-01-11 17:37:34 PST
*** Bug 119581 has been marked as a duplicate of this bug. ***
Comment 12 Randell Jesup [:jesup] 2002-01-11 19:11:28 PST
Nominating; it should be an easy fix.

Bug 119581 also has a testcase w/ no table.
Comment 13 Marc Attinasi 2002-02-25 15:44:22 PST
Moving Mozilla 1.01 bugs to 'future' milestone with priority P1

I will be pulling bugs from 'future' milestones when scheduling later work.
Comment 14 Leif Jensen 2002-04-27 05:31:31 PDT
It does not have to be within links. Try 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.
Comment 15 Leif Jensen 2002-04-27 05:39:34 PDT
Konqueror 2.2.2 loads it nicely.
Comment 16 Randell Jesup [:jesup] 2002-04-29 14:41:17 PDT
mozilla1.0 -> mozilla1.01

There's a testcase with no tables in my dup of this.  We're definitely laying
this out incorrectly.
Comment 17 Leif Jensen 2002-05-20 02:11:03 PDT
I was hoping this bug was fixed in Mozilla 1.0rc2, but it's still there.
Comment 18 Leif Jensen 2002-05-20 02:18:48 PDT
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!)
Comment 19 Christopher Aillon (sabbatical, not receiving bugmail) 2002-06-14 12:54:19 PDT
Created attachment 87711 [details] [diff] [review]
Patch v1.0

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:
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.
Comment 20 David Baron :dbaron: ⌚️UTC-7 2002-06-15 17:11:02 PDT
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.
Comment 21 David Baron :dbaron: ⌚️UTC-7 2002-06-15 17:13:13 PDT
I suspect it was for bug 38396 / bug 39901.
Comment 22 David Baron :dbaron: ⌚️UTC-7 2002-06-15 17:17:32 PDT
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 23 David Baron :dbaron: ⌚️UTC-7 2002-06-15 17:18:58 PDT
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
Comment 24 Michael Lefevre 2002-11-01 06:34:25 PST
*** Bug 159666 has been marked as a duplicate of this bug. ***
Comment 25 Randell Jesup [:jesup] 2002-11-13 14:27:28 PST
attinasi->dbaron, since he produced a patch
Nominating for 1.3
milestone -> ---
Comment 26 David Baron :dbaron: ⌚️UTC-7 2002-11-13 17:16:17 PST
I didn't produce a patch.  I marked a patch as "needs work".
Comment 27 Randell Jesup [:jesup] 2002-11-14 16:57:14 PST
Oops, misread.  Feel free to reassign.  Attinasi seemed a bad choice...
Comment 28 Christopher Hoess (gone) 2003-04-06 11:16:46 PDT
->block & inline
Comment 29 David Baron :dbaron: ⌚️UTC-7 2003-04-06 11:19:22 PDT
I think I want this, actually.
Comment 30 Boris Zbarsky [:bz] (still a bit busy) 2003-04-22 01:01:11 PDT
*** Bug 110358 has been marked as a duplicate of this bug. ***
Comment 31 jonathan chetwynd 2003-04-22 08:54:57 PDT
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...
looks damn silly your way.

Comment 32 David Baron :dbaron: ⌚️UTC-7 2003-06-12 10:49:49 PDT
*** Bug 209065 has been marked as a duplicate of this bug. ***
Comment 33 Greg Noel, Unix Guru 2003-06-12 11:02:23 PDT
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>
Comment 34 Christopher Aillon (sabbatical, not receiving bugmail) 2003-06-12 11:31:51 PDT
Yes, the bug summary already notes that the image needs to be within an inline.
Comment 35 Leif Jensen 2003-07-26 11:13:31 PDT
Congratulations !!  Mozilla 1.4 works with my homepage placing a relative
picture as it should.
Comment 36 Boris Zbarsky [:bz] (still a bit busy) 2003-10-06 13:09:42 PDT
*** Bug 221398 has been marked as a duplicate of this bug. ***
Comment 37 David Baron :dbaron: ⌚️UTC-7 2003-11-19 14:22:00 PST
Created attachment 135953 [details] [diff] [review]

I think this is the right fix, and it doesn't regress bug 38396.
Comment 38 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-11-19 20:21:23 PST
Comment on attachment 135953 [details] [diff] [review]

Comment 39 Boris Zbarsky [:bz] (still a bit busy) 2003-11-19 20:27:58 PST
Is there a reason we no longer need to pass "reason" the the new reflow state?
Comment 40 David Baron :dbaron: ⌚️UTC-7 2003-11-19 23:13:49 PST
Oh, right, I added |reason| back.
Comment 41 David Baron :dbaron: ⌚️UTC-7 2003-11-19 23:15:18 PST
Created attachment 135974 [details] [diff] [review]
Comment 42 Stefan Pietschmann 2003-12-13 01:36:14 PST
could somebody check this in, if it works?
Comment 43 Christopher Aillon (sabbatical, not receiving bugmail) 2003-12-13 01:53:22 PST
It will get checked in when the tree opens for 1.7alpha.  Patience, young
Comment 44 David Baron :dbaron: ⌚️UTC-7 2003-12-18 21:42:14 PST
Fix checked in to trunk, 2003-12-18 21:41 -0800.
Comment 45 Hermann Schwab 2003-12-19 06:39:52 PST
working fine, BuildID 2003121823
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7a) Gecko/20031218

checked with failed yesterday, ok now

Is it too risky to fix this in the branch?
Comment 46 David Baron :dbaron: ⌚️UTC-7 2004-01-13 11:00:43 PST
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.
Comment 47 chris hofmann 2004-03-14 18:45:14 PST
anyone figure out if this fix cause the regression in ?
Comment 48 Boris Zbarsky [:bz] (still a bit busy) 2004-03-14 18:51:12 PST
It probably did, but our current rendering looks correct (and the old rendering
rather broken)...
Comment 49 Wayne Woods 2004-04-24 23:29:34 PDT
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.


Note You need to log in before you can comment on or make changes to this bug.