Last Comment Bug 286368 - overflow:auto gets scrollbar on focused link outline
: overflow:auto gets scrollbar on focused link outline
Status: RESOLVED FIXED
: regression, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 normal with 8 votes (vote)
: mozilla2.0b7
Assigned To: David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch)
:
Mentors:
: 261897 263749 294130 311150 366308 367732 478069 478313 491663 606434 (view as bug list)
Depends on: 240276 542595
Blocks: 261897 324045
  Show dependency treegraph
 
Reported: 2005-03-16 00:14 PST by pete
Modified: 2010-10-31 09:05 PDT (History)
37 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
minimal testcase (81 bytes, text/html)
2005-03-16 00:15 PST, pete
no flags Details
Testcase2 (314 bytes, text/html)
2005-03-22 00:29 PST, Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( )
no flags Details
testcase 3 (273 bytes, text/html)
2005-03-23 12:52 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
no flags Details
testcase4 (378 bytes, text/html)
2005-09-19 22:41 PDT, Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured)
no flags Details

Description pete 2005-03-16 00:14:24 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050306 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050306 Firefox/1.0+

See attached testcase, there is no scrollbar when the page loads but when you
make the link focused so there is a focus rectangle around it, a scrollbar
appears and is pretty much useless (clicking the arrows does nothing). I've seen
this on a lot of message boards because they generate this kind of code, the
nexted DIVs are important to reproduce it.

The left side of the focus rectangle is cut off too but I guess that's another bug.

Reproducible: Always

Steps to Reproduce:
Comment 1 pete 2005-03-16 00:15:10 PST
Created attachment 177586 [details]
minimal testcase
Comment 2 Anne (:annevk) 2005-03-16 00:19:32 PST
This works correctly in Gecko 1.7.5, but it doesn't seem to work on trunk builds.
Comment 3 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-21 18:34:47 PST
There's another bug about this but I can't remember what it is.

Basically what we're doing here is entirely as per spec.

> a scrollbar appears and is pretty much useless (clicking the arrows does
> nothing)

Well, no, you can use it to scroll down one pixel (bringing the bottom of the
outline into view).

I agree that this behaviour is annoying but I'm not sure what we can do. Any
suggestions?
Comment 4 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-03-22 00:29:01 PST
Created attachment 178217 [details]
Testcase2

This is probably the same as bug 263749.
See this testcase. I've set the first link already to have an outline. In that
case, no scrollbar appears. Shouldn't both cases react the same (on first load
compared to dynamically changing style)?
Comment 5 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-22 21:42:10 PST
The first rendering is really a bug. The overflow:auto element should be exactly
as high as it would be if it wasn't overflow:auto. In my opinion, the standards
require that if an overflow:auto element has any overflowing children, you can
only see that overflow by scrolling to it.
Comment 6 Anne (:annevk) 2005-03-23 00:03:28 PST
The first thing I read in CSS2.1 about outlines[1]:

# Outlines do not take up space.

Doesn't that imply that they can't cause a scrollbar or "overflow"?


[1]<http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines>
Comment 7 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-03-23 00:06:28 PST
Lots of things that don't influence layout (which is what was meant) cause overflow.
Comment 8 pete 2005-03-23 11:08:58 PST
Robert: on my machine/build the srollbar does nothing at all.

The second testcase is odd and behaves differently for the top example if you
have browser.display.focus_ring_on_anything enabled or disabled and use the tab
key to change focus.

From my reading of the outline section, I don't get why you consider the
overflow to be per spec. It looks like the intent is for the outline to be some
magical render element that just renders on top of the element in question and
doesn't change anything at all to the page layout.
Comment 9 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-23 12:52:52 PST
Created attachment 178397 [details]
testcase 3

Outlines have to be clipped in general. Consider this testcase. Which outlines
do you think should be clipped?

There is one thing we could do --- in theory --- if it's permissible according
to the standards, and that is to make overflow:auto behave like
overflow:visible when no scrollbars are showing (currently it behaves like
overflow:hidden when no scrollbars are showing). We'd also have to do some work
(pretty painful work actually) to keep track of the overflow area of the
scrolled content excluding the effect of outlines, and not add scrollbars if
they're only to be used to see outlines.

Some results from testing this stuff on other browsers would be useful.
Comment 10 Hixie (not reading bugmail) 2005-03-23 17:41:04 PST
Our rendering seems correct to me. However, per appendix E we can render the
outlines much later than we do now. If we did that, it would render on top of
the overflow box, and thus not cause overflow.
Comment 11 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-23 17:58:24 PST
I talked through this with Hixie on IRC and he agrees that what we're doing is
the only reasonable thing. (correct me if I'm wrong, Hixie!)

One way of working around this problem would be to change our UA rule for
focused links to use an outline-offset of -1px. This would raw the outline
tighter around the link (visually identical to FF1.0.1, in fact) and avoid
inducing a scrollbar.
Comment 12 Hixie (not reading bugmail) 2005-03-23 18:06:12 PST
IE does seem to be hugging the outline closer to the text, but I'm comparing IE6
Windows to FF trunk on Debian on a different machine so who knows.
Comment 13 Aaron Leventhal 2005-03-23 18:13:09 PST
Actually I set the outline at the same as IE, in the tests I performed.
Previously we had the outline inside the link, which is the same as what
outline-offset: -1 would return us to. That would undo the entire reason I
worked on outline in the first place, which is that they were really hard to see.
Comment 14 Aaron Leventhal 2005-03-23 18:16:56 PST
BTW, after outline globbing is fixed I eventually plan to improve focus outline
appearance quite a bit. We just can't assume anything about what the focus
outline size will be later in the game.

For example I currently run with following rules which look pretty nice, with
the exception of some flaws:

*:focus { -moz-outline: 3px solid #70cfff; -moz-outline-offset: 1px;
-moz-outline-radius: 5px; }
textarea:focus, button:focus, select:focus, input:focus { -moz-outline-offset:
-1px; }
input[type="radio"]:focus {-moz-outline-radius: 12px; -moz-outline-offset: 0px; }

Comment 15 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-23 19:25:30 PST
I think there are only two options:

1) Keep the current behaviour. Web authors will have to deal with the problem,
e.g., by adding padding inside overflow:auto elements.

2) Change the CSS standard so that my approach in comment #9 is allowed.
Comment 16 Anne (:annevk) 2005-03-23 23:45:22 PST
The option mentioned in comment 10 is not valid anymore?
Comment 17 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-24 12:23:22 PST
No, I convinced Hixie that it doesn't make sense. Changing the z-order of
outline should not affect what gets clipped. There's also the question of what
rendering you would choose for my testcase 3.
Comment 18 Hixie (not reading bugmail) 2005-03-24 13:26:05 PST
You're proposing saying that 'outline' doesn't affect overflow except is there
already is overflow? That seems very complicated and bug prone.
Comment 19 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-03-24 14:13:10 PST
I'm not really proposing anything, but if I did, I'd propose this:

-- overflow:auto may be treated as overflow:visible when no scrollbars are required

-- outlines do not contribute to overflow in section 11.1
Comment 20 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-04 22:51:29 PDT
The upcoming patch in bug 240276 fixes the issue I mentioned in comment #5, so
the  outline on the first link always causes a scrollbar to appear.
Comment 21 Hixie (not reading bugmail) 2005-04-05 09:45:37 PDT
CSSWG discussed this and came up with the following resolution:

   Add "or overflow" to the end of "The outline created with the outline
   properties is drawn "over" a box, i.e., the outline is always on top,
   and doesn't influence the position or size of the box, or of any other
   boxes. Therefore, displaying or suppressing outlines does not cause
   reflow." in 18.4.

...which I guess solves your problem as you were hoping. 'outline' doesn't cause
overflow, so it just gets painted on top.
Comment 22 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-05 14:28:04 PDT
Thanks for that. There's still the question of whether
overflow:auto/scroll/hidden should clip such
not-causing-overflow-but-really-overflowing outlines. Any thoughts on that?
Comment 23 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-04-05 14:34:27 PDT
I think the answer is probably no...
Comment 24 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-05 15:03:17 PDT
Can you define this behaviour? E.g., should an element that is completely
clipped away still show its outline? See comment #9.
Comment 25 Hixie (not reading bugmail) 2005-04-05 18:02:25 PDT
IMHO the outline should only be visible for those parts of the element that are
themselves not clipped.

For example, in the following:

      +----------------------------------+
      |            ..................... |
      |            : AAAAAAAAAAAAAAAAA : |
     ..............: AAAAAAAAAAAAAAAAA : |
     :|AAAAAAAAAAAAAAAAA :'''''''''''''' |
      +----------------------------------+

...assuming the lines of the A inline are two ASCII lines high (as it were), the
outline is visible where the edge that it is closest to is not clipped (as in
the dots that overflow the right edge) but not visible where the edge that is
closest is clipped (as in the bottom case).

Does that makes sense?

I doubt CSS2.1 will define this in more detail than it does now (in fact
overlapping cases like this are explicitly undefined) but maybe for CSS3 we can
get something into the drafts when CSS3 UI fails to exit CR...
Comment 26 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-05 18:40:27 PDT
Wow. That's moderately insane but I guess it can be made to work.
Comment 27 Hixie (not reading bugmail) 2005-04-05 19:42:25 PDT
I don't really see an alternative. Well, I see two: Clip the outline (which
seems bad from a UI perspective) and always show it (which seems even worse from
a layout perspective).
Comment 28 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-06 00:29:12 PDT
I don't think I'm going to have time to implement this new behaviour, and the
changes would be large and somewhat risky in any case. Unless someone else steps
up, we'll either have to ship with this behaviour, or go back to not supporting
the official 'outline' property (and use negative -moz-outline-offset to stop
our focus outlines from causing overflow).
Comment 29 Steve England [:stevee] 2005-04-28 18:37:21 PDT
With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3 I get no scrollbars when clicking on links in all three test cases.

However, I get scrollbars with:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;rv:1.8b2) Gecko/20050422
Firefox/1.0+ 
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;rv:1.8b2) Gecko/20050428
Firefox/1.0+ (after landing of bug 240276)

I see no change in behaviour between 20050422 (pre-240276) and 20050428
(post-240276) - Is this bug's dependency on bug 240276 still valid?
Comment 30 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-28 19:17:21 PDT
Yes. See comment 20.
Comment 31 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-04-29 02:39:38 PDT
*** Bug 263749 has been marked as a duplicate of this bug. ***
Comment 32 neil@parkwaycc.co.uk 2005-04-30 14:37:04 PDT
Comment 9 would be nice, but I guess it's unrealistic.

Is it possible to make it so that a dynamic outline change doesn't resize?
Comment 33 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2005-04-30 20:36:33 PDT
I don't think that's possible or desirable.
Comment 34 Boris Zbarsky [:bz] 2005-07-26 21:09:59 PDT
*** Bug 294130 has been marked as a duplicate of this bug. ***
Comment 35 Wevah 2005-08-26 21:06:28 PDT
-> All/All
Comment 36 Masayuki Nakano [:masayuki] (Mozilla Japan) (working slowly due to injured) 2005-09-19 22:41:11 PDT
Created attachment 196750 [details]
testcase4
Comment 37 Ulrik Sverdrup 2005-10-04 19:38:50 PDT
*** Bug 311150 has been marked as a duplicate of this bug. ***
Comment 38 Gérard Talbot 2005-10-04 19:45:51 PDT
I believe this bug blocks bug 261196. Marking as such.
Comment 39 Boris Zbarsky [:bz] 2005-10-04 19:53:55 PDT
No, this isn't an incremental reflow bug
Comment 40 Martijn Wargers [:mwargers] (gone per 2016-05-31 :-( ) 2005-11-20 13:07:43 PST
I think this also causes the issue at http://www.nosheadlines.nl/
Focusing any of the "meer" links (red colored links), cause a horizontal scrollbar to appear, which disappears again when unfocusing.
Comment 41 James Crompton 2006-01-04 04:23:26 PST
The current behaviour is clearly counter to the specs (http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines). Some quotes:

1. "The outline created with the outline properties is drawn "over" a box, i.e., the outline is always on top, and doesn't influence the position or size of the box, or of any other boxes. Therefore, displaying or suppressing outlines does not cause reflow."

2. "Note. Since the outline does not affect formatting (i.e., no space is left for it in the box model), it may well overlap other elements on the page."

3. "Scripts may be used to dynamically change the width of the outline, without provoking a reflow."

The suggestion in Comment 32 is thus clearly desirable, even if not currently possible (pace Comment 33).
Comment 42 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-01-08 14:12:40 PST
Trying to treat "dynamic" changes in a special way is undesirable because it will lead to situations where the rendering of the same DOM+style tree differs depending on whether you arrived at that DOM+style tree via dynamic changes or not. That would be really bad.

The suggestions in comment #9 or comment #25 are possible ways to go.

Something else that would help here is if someone analyzed exactly how IE or Opera behave, in particular in the difficult situations discussed in comment #9 and comment #25.
Comment 43 James Crompton 2006-01-08 22:42:47 PST
The points about dynamic changes in the specification underline and emphasise the basic point that also applies for the static case: outlines do not take up any space, and so do not affect the size, flow, position, clipping, scrolling or politics of anything on the page (including the element they are applied to). Therefore changes to an outline should not change anything else either.
Comment 44 John A. Bilicki III 2006-04-11 03:50:51 PDT
The only reason there is debate about a bug like this (and so many others) is because some people just don't want to fix it.

Outlines do not take up space.

border + margin + padding + width = total width of a block element.

Outlines as per W3C spec clearly state, "1# Outlines do not take up space."

A live testcase can be seen on my own site with anchors set to display as block level elements for a clean presentation on the right sidebar...
http://www.jabcreations.com/home/home-news.php

I've tested Opera 7+ and IE 5.01+ and this bug does not exist in those browsers.  If CSS2 related bugs like this are going to liger around because stupid arguements are in the mix what should we expect when CSS3 becomes an official standard?

It's a bug and it needs to be fixed.
Comment 45 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-04-11 04:08:03 PDT
> Something else that would help here is if someone analyzed exactly how IE or
> Opera behave, in particular in the difficult situations discussed in comment #9
> and comment #25.
Comment 46 James Crompton 2006-04-20 07:48:13 PDT
(In reply to comment #45)
> > Something else that would help here is if someone analyzed exactly how IE or
> > Opera behave, in particular in the difficult situations discussed in comment #9
> > and comment #25.
> 
I don't think either Explorer or Opera are examples to follow:

Internet Explorer: renders the outline in the outermost pixels of the element, therefore clipped as and when the element itself is. No effect on size, nothing drawn outside the element and so no difference between #9 and #25.

Opera 8.54: Outline is rendered in the first pixel outside the element and clipped wherever the element is clipped or would be clipped if it were shifted/expanded one pixel in that direction. Thus no difference between #9 and #25. Outline is not used for focus as default and support for :focus is buggy, outline can affect layout and dynamic application of outline can cause reflow, which is a BUG in Opera as it is in Firefox.
Comment 47 quinn 2006-08-29 16:58:19 PDT
Hi, this is the firs time using bugzilla for me. I am a bit confused but hope this is the right thread. I noticed this bug when Firefox1.5RC was coming up. Back then, I just wrote about this in my blog. Anyways, I think it didn't appear to be a bug since the outline border was showing right on the edge of the active element before Firefox1.5. Then, it was changed to show on the right outside of the active element, and now you know what's going on.. I think outline should not cause reflow, otherwise it's almost like borders.
Comment 48 shawn 2006-10-10 07:46:09 PDT
I still see this in Firefox 2.0RC2.
Comment 49 Jeffrey Riaboy 2007-01-08 06:25:38 PST
*** Bug 366308 has been marked as a duplicate of this bug. ***
Comment 50 Mats Palmgren (:mats) 2007-02-05 03:27:23 PST
*** Bug 367732 has been marked as a duplicate of this bug. ***
Comment 51 Gary Turner 2007-03-05 13:46:43 PST
That outline acts as another border on the outer edge of the border box is a layout breaking bug that should be fixed.
Comment 52 John A. Bilicki III 2007-06-05 14:43:10 PDT
Here is a test case that I use to explain this bug to people...
http://www.jabcreations.com/web/browser-bugs_gecko_286368.php
Comment 53 Jonathan Bruder 2007-08-25 13:46:45 PDT
I need to know whether I should post a test case here or create a new bug. 

I read this bug, I'm noticing similar behavior (focus-highlighting causing scroll bars) on links that are being activated. These are the basic conditions:

1. The bounding box is automatically generated, e.g. by content + padding
2. The links are using a block-level display, either set through css or by containing an image
3. The links have at least 1 border side missing (mixed border-style or no border)
4. The links are focused by activation, tab-focus, or as a cached relic of activation when returning to a previously visited page (via back button).

This sounds like a complicated use-case, but it's pretty typical when using semantic markup on lists of links to create horizontal navigation. 

Whaddyathink?
Comment 54 philippe (part-time) 2009-02-11 15:22:03 PST
*** Bug 478069 has been marked as a duplicate of this bug. ***
Comment 55 philippe (part-time) 2009-02-12 18:11:35 PST
*** Bug 478313 has been marked as a duplicate of this bug. ***
Comment 56 Nochum Sossonko [:Natch] 2009-05-07 12:27:01 PDT
*** Bug 491663 has been marked as a duplicate of this bug. ***
Comment 57 don't use this account! 2010-01-22 12:25:13 PST
The same thing happens when you give focus to a flash movie object. If you set the movie width and height to 100% and give focus to the flash movie scroll bars are going to appear.

It started happening on Firefox 3.6 beta and still exist on the current version [Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6]. It didn't happened on previous versions of Firefox (1.5 - 3.5.7).

The way to fix it is adding the CSS rule: object{outline:none} - but as other people said before, outline shouldn't take space.
Comment 58 j.j. 2010-10-22 02:44:16 PDT
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101019 Firefox/4.0b8pre

fixed with bug 542595.
Comment 59 j.j. 2010-10-22 02:45:54 PDT
*** Bug 606434 has been marked as a duplicate of this bug. ***
Comment 60 j.j. 2010-10-22 14:49:28 PDT
*** Bug 261897 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.