Closed Bug 286368 Opened 19 years ago Closed 14 years ago

overflow:auto gets scrollbar on focused link outline

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla2.0b7

People

(Reporter: pete_a90, Assigned: dbaron)

References

Details

(Keywords: regression, testcase)

Attachments

(4 files)

minimal testcase
81 bytes, text/html
Details
Testcase2
314 bytes, text/html
Details
testcase 3
273 bytes, text/html
Details
testcase4
378 bytes, text/html
Details 
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:
Attached file minimal testcase — 

    
    

    
  
This works correctly in Gecko 1.7.5, but it doesn't seem to work on trunk builds.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, 
          
            testcase

    
    

    
  
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?

    
    

    
  

      
      
      
      

        Attached file
          
        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)?

    
    

    
  
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.

    
    

    
  
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>

    
    

    
  
Lots of things that don't influence layout (which is what was meant) cause overflow.

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached file
          
        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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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; }



    
    

    
  
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.

    
    

    
  
The option mentioned in comment 10 is not valid anymore?

    
    

    
  
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.

    
    

    
  
You're proposing saying that 'outline' doesn't affect overflow except is there
already is overflow? That seems very complicated and bug prone.

    
    

    
  
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

    
    

    
  
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.
Depends on: 240276

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
I think the answer is probably no...

    
    

    
  
Can you define this behaviour? E.g., should an element that is completely
clipped away still show its outline? See comment #9.

    
    

    
  
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...

    
    

    
  
Wow. That's moderately insane but I guess it can be made to work.

    
    

    
  
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).

    
    

    
  
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).

    
    

    
  
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?

    
    

    
  
*** Bug 263749 has been marked as a duplicate of this bug. ***

    
    

    
  
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?

    
    

    
  
I don't think that's possible or desirable.
Summary: overflow:auto gets scrollbar on focused link → overflow:auto gets scrollbar on focused link outline

    
    

    
  
*** Bug 294130 has been marked as a duplicate of this bug. ***

    
    

    
  
-> All/All
OS: Windows 2000 → All
Hardware: PC → All

    
    

    
  
*** Bug 311150 has been marked as a duplicate of this bug. ***

    
    

    
  
I believe this bug blocks bug 261196. Marking as such.

Blocks: 261196

    
    

    
  
No, this isn't an incremental reflow bug
No longer blocks: 261196

    
    

    
  
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.

    
    

    
  
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).

    
    

    
  
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.

    
    

    
  
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.
Blocks: 261897

    
    

    
  
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.

    
    

    
  
> 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.

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
I still see this in Firefox 2.0RC2.
Blocks: 324045

    
    

    
  
That outline acts as another border on the outer edge of the border box is a layout breaking bug that should be fixed.

    
    

    
  
Here is a test case that I use to explain this bug to people...
http://www.jabcreations.com/web/browser-bugs_gecko_286368.php

    
    

    
  
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?
Blocks: 456497
Blocks: 446693
QA Contact: ian → layout.view-rendering

    
    

    
  
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.

    
    

    
  
Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101019 Firefox/4.0b8pre

fixed with bug 542595.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee: nobody → dbaron
Component: Layout: View Rendering → Layout
Priority: -- → P3
QA Contact: layout.view-rendering → layout
Target Milestone: --- → mozilla2.0b8

    
  
Target Milestone: mozilla2.0b8 → mozilla2.0b7

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: