<embed width="100%" height="100%"> (or similar element) inside absolutely positioned <div> doesn't fill browser window

RESOLVED INVALID

Status

()

Core
Layout: R & A Pos
RESOLVED INVALID
13 years ago
13 years ago

People

(Reporter: David Changer, Unassigned)

Tracking

({testcase})

Trunk
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0

The following website is small when in fact it should resize as the browser is
resized. Netscape and Windows explorer handle this OK

http://www.aldingtoncraigandcollinge.co.uk/

Reproducible: Always
Steps to Reproduce:
enter http://www.aldingtoncraigandcollinge.co.uk/ in the browser
Actual Results:  
The resulting page is small

Expected Results:  
The page should have expanded to the size of the browser

Updated

13 years ago
Assignee: firefox → nobody
Component: General → Layout
Keywords: qawanted
Product: Firefox → Core
QA Contact: firefox.general → core.layout
Version: unspecified → Trunk
Created attachment 168349 [details]
minimal testcase

Outer div is position:absolute. Inner div (yellow) has width:100% and
height:100%.
In IE, the inner and outer divs are displayed at 100% height and width of the
viewport (minus margins).
In Firefox (and Safari), the inner div shrink-wraps it's content (and the outer
div shrink-wrpas the inner one).

Updated

13 years ago
Component: Layout → Layout: R & A Pos
Keywords: qawanted → testcase
OS: Windows XP → All
QA Contact: core.layout → core.layout.r-and-a-pos
Hardware: PC → All

Comment 2

13 years ago
Rewrote summary.

This appears to be correct CSS2.1 behaviour.  According to section 10.3.7 of the
standard

   http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width

the absolutely positioned <div> element should have shrink-to-fit width with
left margin as for static positioning, and it does.  Ditto for its height.

In the original URL, the inner element was an <embed> with width and height
attributes (of 100%) rather than another <div> with CSS width and height, which
makes things a little more ambiguous, but a little experimentation suggests that
these attributes are being interpreted, reasonably enough, as a percentage of
available space within the previously constructed <div> box (with width forced
to be at least the minimum for embeds of 240 pixels).

So, there's probably no bug to fix here, unless it's a new "quirk", though Tech
Evangelism might be in order.

I'm going to mark this bug NEW, since the issue is clearly real and verifiable.
 Can someone with some more layout expertise confirm my assessment and mark this
bug INVALID, reassign it to Tech Evangelism, or take some other appropriate
action?  Thank you!
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: http://www.aldingtoncraigandcollinge.co.uk/ behaves wrongly when displayed in the browser → <embed width="100%" height="100%"> (or similar element) inside absolutely positioned <div> doesn't fill browser window
The thing is, we have a quirks-mode only thing to emulate IE's behavior.  And
the problem is that on other testcases, it looks like IE's percent heights don't
cross absolutely positioned element boundaries (see bug 221784 and testcases
therein).

So what exactly is IE's behavior?  How to reconcile the testcase in this bug
with the testcases in bug 221784?

Comment 4

13 years ago
Created attachment 168387 [details]
page showing buggy IE6 behaviour on this issue

Turns out IE6 (version 6.0.2900.2180.xpsp_sp2_rtm.040803-2158) behaviour is
buggy on this issue.  Try rendering the attached HTML in IE6.  The grey
<applet>'s width is 75% of the white <div>'s width which is 75% of the browser
window.  (<applet> can be replaced with <img> with same results.)

That is, IE appears to be taking the missing width for the absolutely
positioned element from the *child* element, taking it to be "75%" verbatim
(and so 75% of the browser window).  Since the applet width is also "75%", it
becomes 75% the width of its containing element and so 75% of 75% of the
browser window.

If I add additional <applet> elements with fixed or percentage sizes, things
get even more bizarre, so I can't guess what IE's algorithm is ultimately
doing.
Hmm... so a 50% width/height <applet> in an abs pos div with auto width/height
will end up 25% of the width/height of the viewport in IE6?

Comment 6

13 years ago
Yes for width, but height is handled differently.  For example,

<html><body style="background: black">
<div style="position: absolute; height: 90%; background: white; border: solid red">
<applet height="50%" width="50%">
</div>
</body></html>

produces an applet that's 25% the width of the viewport and 45% the height. 
However, change "height: 90%" to "height: auto" and the border shows the box has
collapsed to zero height.

This resembles the height:auto and width:auto calculations for absolutely
positioned elements from CSS2 (revision 0), where the width and height were
supposed to expand to the size of the initial containing block (here, the width
of the viewport but the height of zero, since there's no other content to grow it).
Created attachment 168398 [details]
improved testcase

This is the same as my first testcase, but retaining the "height:90%" on the
outer div. This demonstrates that this bug is actually about width (whereas bug
221784 was about height).
Still seems to me that there is no need for an embed/applet to demonstrate this
- the issue is basically the same with a simple div, using CSS height/width.
Attachment #168349 - Attachment is obsolete: true
So... in the testcase in comment 1, what is IE's rendering?  Is it 100% height?

Frankly, the width thing is not so interesting to me; we don't plan to try to
emulate that brokenness.  But I'd like to sort out exactly what's going on with
height.
Yes, in the first testcase, IE5/Mac renders 100% height (with white margins). I
don't have access right now to a Windows machine, so you might want to ask
someone to verify that on IE/Win (or I can do it next week).

However, as I said, the problem with the site on which this bug was originally
filed is the width, not the height.

Comment 10

13 years ago
Ha ha ha...

Well, on the first testcase attachment (id=168349), the version of IE6 for
Windows XP mentioned in comment #4 renders a yellow box with 100% (except for
small white margins) width and just high enough for the text.

(On the testcase attachment (id=168398), the yellow box is (nearly) full width
and about 90% height with white margins.)
Oh.  IE/Mac.  IE/Mac has a totally different rendering engine from IE/Win...

Marking invalid, since our rendering is correct.  As Kevin points out, IE is
implementing an old CSS proposal that's since been superceded.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID

Comment 12

13 years ago
To the original reporter, David Changer:

If you'd like a temporary workaround for this site, you can create a
"userContent.css" containing the following lines:

/* temporary fix for http://www.aldingtoncraigandcollinge.co.uk/ */
div[style="position: absolute; top: 5%; height: 90%;"] {
  left: 2%;
  right: 2%;
}

The "userContent.css" file, assuming it doesn't already exist (and it shouldn't,
unless you've created one), should go in the "chrome" folder of your Firefox
profile folder.  That's probably in:

   C:\Program Files\Mozilla\Firefox\Defaults\Profiles\chrome

Alternatively, you can just search for the "userContent-example.css" file, and
put your new "userContent.css" file in the same directory.

You'll need to restart Firefox for this to take effect.
You need to log in before you can comment on or make changes to this bug.