DIV with 'overflow' has margin-left added to left float's position

RESOLVED WORKSFORME

Status

()

Core
Layout: Block and Inline
--
major
RESOLVED WORKSFORME
13 years ago
12 years ago

People

(Reporter: Jonathan G., Unassigned)

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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.
Assignee: general → roc
Component: General → Layout: View Rendering
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Version: unspecified → Trunk

Comment 1

13 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

13 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"
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 ?
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/
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
Created attachment 199075 [details]
Testcase showing inappropriate (?) behavior
Keywords: testcase
OS: Windows XP → All
Hardware: PC → All

Comment 8

12 years ago
Created attachment 199079 [details]
Clearer testcase

Updated

12 years ago
Attachment #199075 - Attachment is obsolete: true
-> 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.
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!).
(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?
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.