Closed
Bug 289577
Opened 19 years ago
Closed 19 years ago
DIV with 'overflow' has margin-left added to left float's position
Categories
(Core :: Layout: Block and Inline, defect)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: gilardijd05, Unassigned)
References
()
Details
(Keywords: regression, testcase)
Attachments
(1 file, 1 obsolete file)
777 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Build Identifier: Mozilla 1.8b If overflow-x:hidden is applied to a <div> tag such that an overflow actually occurs, Mozilla will shift the div's contents downward significantly. The actual shift is dependant on the contents of the div, however, in all cases it is significant enough to cause problems. Reproducible: Always Steps to Reproduce: This bug occurs in all default installations of any Mozilla 1.8b version. This but does NOT occur in Mozilla 1.7.x. Code to reproduce error. Note, the <em> tag causes the overflow such that "overflow-x" is needed. <div style=width:200px;> <div style=overflow-x:hidden;> <em> Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test Test </em> </div> </div> Expected Results: overflow-x:hidden should prevent the div's contents from manipulating it's size. If the contents happen to overflow, they will not be drawn. This bug occurs in all default installations of any Mozilla 1.8b version. This but does NOT occur in Mozilla 1.7.x. My apologies if this is a duplicate- your bug search doesn't display any results for the Mozilla Suite. I also classified this bug as "Major" becuase it breaks core CSS techniques that are globally used.
Updated•19 years ago
|
Assignee: general → roc
Component: General → Layout: View Rendering
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Version: unspecified → Trunk
Comment 1•19 years ago
|
||
Why would the EM element cause 'overflow'? Are you talking about an IE bug that Mozilla does not have or so? I think this is invalid.
Reporter | ||
Comment 2•19 years ago
|
||
(In reply to comment #1) > Why would the EM element cause 'overflow'? Are you talking about an IE bug that > Mozilla does not have or so? > I think this is invalid. EM/Itallic shifts the font over to the right- this isn't the bug. I just used it to cause an overflow- it doesn't matter how it happens. You could throw a picture in there with a width of 250pixels- if it overflows, the bug occurs.
"works for me"
Comment 4•19 years ago
|
||
Works for me too. Jonathan, can you please attach an HTML page showing the bug using https://bugzilla.mozilla.org/attachment.cgi?bugid=289577&action=enter ?
Comment 5•19 years ago
|
||
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 6•19 years ago
|
||
I'm guess this is the same problem I'm having. I've tracked it down to occuring between the 2004-09-04 and 2004-09-05 builds (breaking on the latter one). This could have been caused by the checkin for bug 72747. A testcase will follow. Confirming as a regression.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8rc1?
Keywords: regression
Summary: Mozilla 1.8b incorrectly interprets the "overflow-x:hidden" property in a CSS.` → Mozilla 1.8b incorrectly interprets the "overflow-x:hidden" property
Comment 7•19 years ago
|
||
Updated•19 years ago
|
OS: Windows XP → All
Hardware: PC → All
Comment 8•19 years ago
|
||
Updated•19 years ago
|
Attachment #199075 -
Attachment is obsolete: true
Comment 9•19 years ago
|
||
-> Style System (CSS)
Assignee: roc → dbaron
Component: Layout: View Rendering → Style System (CSS)
The overflow property actually should sometimes affect layout (especially in the presence of floats), because a DIV with 'overflow' non-visible establishes a new block formatting context. That said, the testcase above does look wrong.
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: Block and Inline
QA Contact: ian → layout.block-and-inline
Summary: Mozilla 1.8b incorrectly interprets the "overflow-x:hidden" property → DIV with 'overflow' has margin-left added to left float's position
That said, the underlying layout bug is almost certainly not a regression from the bug you site: the regression would be that adding support for 'overflow-x' means that the DIV in question now counts as having overflow.
Comment 12•19 years ago
|
||
The layout of Simon's testcase (and Samuel's too) is affected by CSS 2.1, section 9.5, which says: The margin box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. The only possible bug on that testcase is that there is not "sufficient space" and so we should be clearing, not shifting to the right. In any case, in my opinion these testcases should go in a separate bug if we consider that to be a problem. This bug, as filed, is worksforme and I'd really rather we didn't morph bugs because we think we have a testcase similar to the one in the bug.... (or confirm bugs while putting them in the wrong component, for that matter!).
Comment 13•19 years ago
|
||
(In reply to comment #12) > In any case, in my > opinion these testcases should go in a separate bug if we consider that to be a > problem. This bug, as filed, is worksforme and I'd really rather we didn't morph > bugs because we think we have a testcase similar to the one in the bug.... (or > confirm bugs while putting them in the wrong component, for that matter!). I apologize for filing on the wrong bug and have opened bug 311935 for the issue I reported here. Closing this bug as WFM.
Flags: blocking1.8rc1?
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•