Closed Bug 363675 Opened 18 years ago Closed 16 years ago

reflow branch landing changed width behavior of abs/fix pos iframes

Categories

(Core :: Layout: Positioned, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 412679

People

(Reporter: dbaron, Assigned: dbaron)

References

Details

Attachments

(9 files)

695 bytes, text/html; charset=UTF-8
Details
664 bytes, text/html; charset=UTF-8
Details
603 bytes, text/html; charset=UTF-8
Details
572 bytes, text/html; charset=UTF-8
Details
4.57 KB, patch
Details | Diff | Splinter Review
656 bytes, text/html; charset=UTF-8
Details
625 bytes, text/html; charset=UTF-8
Details
564 bytes, text/html; charset=UTF-8
Details
533 bytes, text/html; charset=UTF-8
Details
The reflow branch landing changed the width behavior of absolute and fixed positioned iframes -- at least those with left:0 and right:0, so that they use their intrinsic size (i.e., follow the rules for replaced elements) rather than stretching (following the rules for non-replaced elements).  This caused bug 363154.

Testcases to follow, then analysis of behavior of other browsers.
This is whether the following browsers expand the positioned elements to fill their containing block.  I have not found any differences between the position:absolute and position:fixed cases.

Firefox 2: expands both height and width
WinIE7: expands neither
Konqueror: expands neither
Opera: expands only height
Firefox trunk (post reflow branch): expands only height
The quirks mode results are the same.

So I conclude we should probably keep the changed behavior, and make the same change for height, since I think the new behavior agrees both with the spec and with other browsers.
Yeah, agreed.
(That said, there are advantages to the old behavior.  The 300*150 stuff is completely arbitrary and it would be nice to have it show up in fewer cases.  Maybe I should try to find a way to get back to it.  But if we do, we should probably try to change the spec.)
I'd have thought implementing ComputeAutoSize on nsLeafFrame would fix this; turns out it doesn't.
David, while sticking to the spec is generally a good thing - is there any other way to stretch a frame vertically to window size while keeping offsets on both sides? position:absolute;left:0;margin:10px;width:100%; stretches the document and introduces scrolling so it cannot be a replacement for position:absolute;left:10px;right:10px;. Unless I am missing an obvious way to do this I would rather vote for keeping the behavior from Firefox 2 and changing the spec.
The issue with changing the spec is that it involves convincing all the other browsers to change their behavior (which currently complies with the spec).  So it's not so much a matter of "we should follow the spec" as "we should have compat with the way every single other UA does it"....

I agree that the use case you describe is useful, and there should be a way to achieve it (say a -moz property that says to not use replaced element sizing or whatever).
The issue from comment 11 can probably be addressed by using the calc() property from CSS3. I agree though that the behavior from Firefox 2 was much more what you would expect. I suppose the main problem with that one is convincing IE to do the same, as you say...
I don't think this works at all in IE7, see: http://wargers.org/mozilla/abspos.htm
That shows it's not even working for a <div>.
So it's probably not useful to look at what IE is doing.
WinIE7 gets the standards mode baseline testcases correct but not the quirks mode ones.  The other browsers tested get all the baseline testcases correct.
Looks like Boris has a patch for this n bug 412679.
Hmm... And it's pretty identical to the one you had here.  I wonder why it didn't work for you?

Anyway, I'm happy with taking the assertion changes here that explain things in a little more detail than the assertions in my patch.  I do think we should make the nsFrame.h comment change in my patch...
So should we mark this duplicate of bug 412679?
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.