Closed
Bug 517071
Opened 15 years ago
Closed 9 years ago
Outline takes up space when applied to floated element with parent having overflow: auto set
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: kjacobson, Unassigned)
References
()
Details
(Whiteboard: dupeme)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 the normal active link outline (whether or not specified explicitly in CSS) takes up space on an element set to "float: left" or "float: right" when that element's container has "overflow: auto", thus causing scrollbars to appear in cases where container has fixed dimensions. Seems that CSS spec (http://www.w3.org/TR/css3-ui/#outline1) stating "1. Outlines do not take up space." is not followed in the case of floated elements inside containers with overflow: auto. Reproducible: Always Steps to Reproduce: 1. Create page with parent div#parent, height: 50px, overflow: auto; 2. Create children, a#child1 a#child2, display: block, height: 100%. put text inside, so they take up space horizontally. Make sure #child1 and #child 2 are links, i.e. apply href attribute. 3. Apply float: left; to a#child1 and a#child2. 4. hold down mouse on either link. # demo at http://twelve8.net/outline_test.html Actual Results: scrollbar appears on div#parent when either link is active Expected Results: scrollbar should not have appeared, since outline should not have taken up space This is really important for keyboard navigation.
Comment 1•15 years ago
|
||
Confirmed using a local testcase (which I'll attach shortly). The testcase given in comment 0 is now a 404, though.
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
OS: Windows 7 → All
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Comment 2•15 years ago
|
||
Here's a testcase that triggers the problem for me. I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091012 Minefield/3.7a1pre Note that this bug is partly to blame for bug 521503 -- if outlines didn't take up space, that bug wouldn't be a problem.
Updated•15 years ago
|
Comment 3•15 years ago
|
||
This is a bug as far back as Firefox 2.0. Probably is a dupe of an existing bug. I tested these builds (& confirmed that they're broken): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.14) Gecko/2009090214 Ubuntu/9.10 (karmic) Firefox/3.0.14 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20091007 Ubuntu/9.10 (karmic) Firefox/3.5.3
Whiteboard: dupeme
Comment 4•15 years ago
|
||
Sorry, I forgot to document behavior of testcase 1 (attachment 405934 [details])
When I click the page...
* EXPECTED BEHAVIOR: ... orange dots appear down the right side of box "A".
* ACTUAL BEHAVIOR: ... expected behavior, PLUS, box "B" wraps to its own line, and a vertical scrollbar appears (to allow you to scroll down to "B")
Comment 5•15 years ago
|
||
Here's a reference case, using "overflow: hidden" instead of "overflow: auto". This shows expected behavior.
Comment 6•13 years ago
|
||
I don't see this on a current Firefox build. Can you retest?
Comment 8•9 years ago
|
||
As far as I can tell, this is WFM too. Daniel, can you verify?
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME
Comment 9•9 years ago
|
||
Yup, seems WFM. (I get EXPECTED BEHAVIOR from comment 4.) Thanks!
Status: RESOLVED → VERIFIED
Flags: needinfo?(dholbert)
You need to log in
before you can comment on or make changes to this bug.
Description
•