Outline takes up space when applied to floated element with parent having overflow: auto set

VERIFIED WORKSFORME

Status

()

Core
Layout
--
major
VERIFIED WORKSFORME
8 years ago
2 years ago

People

(Reporter: Kyle Jacobson, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: dupeme, URL)

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
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.
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
Created attachment 405934 [details]
testcase 1

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.
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
Blocks: 521503
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")
Created attachment 405940 [details]
reference case 1

Here's a reference case, using "overflow: hidden" instead of "overflow: auto".  This shows expected behavior.

Comment 6

6 years ago
I don't see this on a current Firefox build. Can you retest?

Comment 7

5 years ago
I can't reproduce this vs. latest mozilla-central either.
As far as I can tell, this is WFM too. Daniel, can you verify?
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WORKSFORME
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.