Closed
Bug 825999
Opened 12 years ago
Closed 12 years ago
REGRESSION: overflow: hidden; on <button>s hides text but doesn't change the button's overflow area or that of its parents
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
RESOLVED
FIXED
mozilla21
People
(Reporter: mcbain.asm, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: regression, testcase)
Attachments
(2 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
Bug ID for previous issue with similar effect (resolved in 2010): 541382 (I don't know how to / can't re-open issues). Regression of overflow handling on <button>s with a fixed width and overflow: hidden. Such buttons now behave as if their overflow was not hidden except that the overflow is not painted. I noticed this on an existing site I wrote where such a button was nested in a sidebar. The site was designed to fill the viewport if the viewport was less than a certain width. Thus it never had a horizontal scrollbar for the page until this regression. This regression causes space to appear to the right side of the sidebar with nothing in it and thus also cause a horizontal scrollbar for the page. Attached is a test-case, using outline, that shows the effective (layout-affecting) width of a fixed width button with overflow compared to a normal div with the same styles. If you view this test-case in Firefox the effective width of the button is much larger than the div, which was not the case in prior versions of Firefox. If you view this in Chrome or Opera, no extra space is reserved for the overflowing text as expected. In all browsers, the overflowing text is not actually painted (as expected).
Updated•12 years ago
|
Attachment #697123 -
Attachment mime type: text/plain → text/html
Comment 2•12 years ago
|
||
Hmm. Looks like this worked right in Firefox 11 but is already broken in Firefox 12. Looks like the overflow area for the button includes the text (hence the effects on ancestor scrollbars and outlines), which isn't right.
Keywords: regression,
regressionwindow-wanted
Comment 3•12 years ago
|
||
Last good nightly: 2012-01-19 First bad nightly: 2012-01-20 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=58e933465c36&tochange=5c2bc94d359c Bug 524925 ?
Comment 4•12 years ago
|
||
Last Good: 73eaf1199ff0 First Bad: a915d5820eb8 Triggered by: a915d5820eb8 Mats Palmgren β Bug 524925 - Consolidate overflow clipping checks to nsFrame::ApplyOverflowClipping(); and fix some code style nits. part=5/6 r=roc
Blocks: 524925
Keywords: regressionwindow-wanted
Updated•12 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 17 Branch → 12 Branch
Comment 5•12 years ago
|
||
Mats, could you take a look please? At first glance, it looks like nsIFrame::FinishAndStoreOverflow used to call IsTableClip() for all frames but now we no longer do the equivalent of that or something?
Assignee: nobody → matspal
Updated•12 years ago
|
Summary: REGRESSION: overflow: hidden; on <button>s hides text but doesn't change effective layout width → REGRESSION: overflow: hidden; on <button>s hides text but doesn't change the button's overflow area or that of its parents
Updated•12 years ago
|
OS: Windows 7 → All
Hardware: x86_64 → All
Not off the top of my head.
Flags: needinfo?(roc)
Updated•12 years ago
|
Flags: needinfo?(matspal)
Assignee | ||
Comment 9•12 years ago
|
||
(In reply to Boris Zbarsky (:bz) from comment #5) > At first glance, it looks like nsIFrame::FinishAndStoreOverflow used to call > IsTableClip() for all frames but now we no longer do the equivalent of that > or something? Exactly so. We now only do the overflow:hidden clipping for some frame types: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.h#594 adding "IsFrameOfType(nsIFrame::eReplacedContainsBlock)" there seems to fix it: https://hg.mozilla.org/try/rev/e0941f547a54 (iirc, we only handle the non-scrollframe case here) I'm going to investigate more to make sure I don't miss any cases this time... and write regression tests since we apparently don't have any covering this.
Flags: needinfo?(matspal)
Assignee | ||
Comment 10•12 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=2058283350fc
Attachment #705322 -
Flags: review?(roc)
Attachment #705322 -
Flags: review?(roc) → review+
Assignee | ||
Comment 11•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/d0b6aff97358
Flags: in-testsuite+
Keywords: testcase
Comment 12•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d0b6aff97358
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
You need to log in
before you can comment on or make changes to this bug.
Description
•