From #developers: <KaiRo> aaronlev: hi... is it intended that webpage areas with overflow:auto and no shown scrollbars (nothing to actually scroll) are getting a dotted focus outline when clicked with the mouse? <aaronlev> KaiRo, I couldn't code it perfectly to know when there was a scrollbar <aaronlev> KaiRo, I suppose that part needs work <aaronlev> KaiRo, I don't think it should get focus if there are no scrollbars For an example of this behaviour, load http://home.kairo.at/ and click on the main page area.

We discussed this. I think they should get focus.

Roc, forgive me for going senile. Remind me what our logic was?

It produces a more consistent tabbing setup. If tabbing depends on how tall the overflow:auto element's content is, then tabbing ends up depending on things like the current text size and possibly even what state DHTML is in.

Do we need to show a focus outline on the div even when we klick anywhere in the div with the mouse? I agree that it's good to show the focus ring when tabbing there by keyboard, but it looks quite disturbing...

I think the use of overflow:auto on http://home.kairo.at/ is already quite disturbing :-) Are there other higher-profile sites where this is a problem?

> I think the use of overflow:auto on http://home.kairo.at/ is already quite > disturbing :-) Yeah, I can guess that ;-) Well, this is actually fallout from having a system behind it should show a vertical scrollbar when the contents get too wide, and I made up that personal page with the same system... > Are there other higher-profile sites where this is a problem? I don't know, I just thought we'd better think this out before it catches up on us on any higher-profile sites (I only have a few lower-profile sites using such techniques). BTW, how do IE, Opera, Safari etc. handle that?

We have thought it out. We now need more feedback on what the impact is for real-world sites.

I cross-checked one of my pages in Konqueror 3.3, IE 6, and Opera 7.51, and all of them show no focus outline when I click the overflow:auto area of the page.

That's interesting but not really what I asked... An alternative to focusing the overflow:auto element is to make keyboard scrolling scroll the nearest scrolling element that contains the caret. This is what I suggested originally but for some reason we decided that focusing the scrolling element was better, I can't remember why.

(In reply to comment #9) > That's interesting but not really what I asked... Opera, Safari and IE fall down in their Section 508 compliance on this. > > An alternative to focusing the overflow:auto element is to make keyboard > scrolling scroll the nearest scrolling element that contains the caret. This is > what I suggested originally but for some reason we decided that focusing the > scrolling element was better, I can't remember why. You have to be able to navigate to the item and scroll it, all without using the mouse. The area where the keyboard is acting is called the focus. The focus must always be visible. I suggest that the tab order doesn't need to be consistent between viewing it on different form factors. In my opinion we should fix it so the element should only be focusable when scrollbars are visible. As a corollary the scroll bars should only be visible when they're really necessary. Right now they seem to appear at times that they shouldn't.

(In reply to comment #10) > You have to be able to navigate to the item and scroll it, all without using > the mouse. The area where the keyboard is acting is called the focus. The > focus must always be visible. But you could do that with caret browsing. > I suggest that the tab order doesn't need to be consistent between viewing it > on different form factors. In my opinion we should fix it so the element > should only be focusable when scrollbars are visible. As a corollary the > scroll bars should only be visible when they're really necessary. Right now > they seem to appear at times that they shouldn't. It's not just different form factors. It's also dynamic effects that change the amount of content in a container, including incremental page loading. I'm OK with switching to depending on scrollbar visibility and seeing how it goes.

(In reply to comment #11) > (In reply to comment #10) > > You have to be able to navigate to the item and scroll it, all without using > > the mouse. The area where the keyboard is acting is called the focus. The > > focus must always be visible. > > But you could do that with caret browsing. We could, but I don't want to rely on caret browsing for this. Caret browsing is really a last resort. Normally a scrollable pane inside another document takes focus. From the user's point of view it's no different from an iframe. They don't know exactly what code is being used by the author to do it. > It's not just different form factors. It's also dynamic effects that change the > amount of content in a container, including incremental page loading. Right, understood. > > I'm OK with switching to depending on scrollbar visibility and seeing how it goes. Okay. I think I had 2 problems doing that: 1) trouble reliably knowing when there was a scroll bar 2) scrollbars showing up when the information didn't really overflow the area

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

> 1) trouble reliably knowing when there was a scroll bar Did you file the bug about margins being included in GetActualScrollbarSizes? If so I lost the bug number. > 2) scrollbars showing up when the information didn't really overflow the area That'd be reflow bugs which we'll just have to squash one by one.

No, the only spinoff bugs from bug 254966 so far are this one and bug 257672.

This outline "breaks" the presentation of my own Web site: http://www.dante.com/users/jasonb Seeing the outline appear in the left of right hand pane (given the rest of my content, it only shows as a dotted line at the top of either pane) makes it look terrible. Note that I'm using overflow:auto AND have scrollbars but the outline still appears. (Granted, I'm using nested DIVs.) Is this a different bug that I should file or is it actually covered here?

Jason, the outline is supposed to appear when you have scrollbars. Aaron insists that elements with scrollbars should visibly take focus. The only possible compromise would be to indicate focus in a way that's less annoying to you but still visually consistent with other focusable elements. I don't see what that could be.

What is really the benefit of showing the focus on an element with scrollbars (overflow:auto)? For keyboard navigation I see the point, but not when scrolling an element with the mouse. It doesnt look good.

> For keyboard navigation I see the point, It's important to show what is focused *before* the user presses any keys, so they can see what will be acted on if they do press a key. It'd be hard to know in advance whether the user is going to use the keyboard :-)

(In reply to comment #18) > It doesnt look good. Probably because we should show the outline inside the border when we do it for focus. Think of it similar to when an iframe gets focus. That's not considered ugly. Maybe give it the right look by using outline-offset (need to implement it first).

(In reply to comment #20) > Think of it similar to when an iframe gets focus. That's not considered > ugly. Difference is that when i click on the scrollarrows in a frame it doesnt focus it, only when i TAB into it. Now elements with scrollbars gets focused just by scrolling them.

> Aaron insists that elements with scrollbars should visibly take focus. I don't understand why this should happen unless the element that's being focused is an input element - something in which you'd type. Plus, if the method by which you've selected something is by *clicking* on it with your mouse, then it should be obvious that the keyboard is not being used and there need be no visual indication of where you are - it's obvious since you clicked there. IMHO, only if the user has used the keybard (Tabbed) to get to an *input* element should the outline be shown... > the outline is supposed to appear when you have scrollbars Okay, I've got that. (I should have read the bug more carefully.) But is it also supposed to appear when there *aren't* scrollbars (because it does) - or is that what this bug is debating specifically? So far, the discussion seems to be talking about outlining in general...

Well, it's not a high-profile site, but this site suffers quite heavy of this bug/feature: http://turkeybot.info/ (it also triggers quite a lot of incremental reflow bugs in Mozilla, I think. Click for example on the heading: "Welcome to Turkeybot")

Martijn: Yes, we seems to have quite a few interesting reflow bugs as well, the community site I'm working on as http://com.naddy.at/ suffers from this bug and some interesting reflow issues as well. We should try to narrow down simplified testcases of those, but I didn't manage to do that for the reflow bugs I see there :( (That's off-topic on this bug though, so I better shut up...)

Found a website that might be broken due to this, not sure, just guessing though. Filed it as bug 262104.

> You have to be able to navigate to the item and scroll it, all without > using the mouse. The area where the keyboard is acting is called the > focus. The focus must always be visible. I understand this with respect to focus when using keyboard navigation. But I still don't understand why we need an outline when clicking on something. In that case, I know exactly what has focus because I've explicitly selected it with my mouse. If this is off-topic for this bug, please respond to me offline or let me know in which forum / other bug this is being / has been discussed.

This bug has, as it seems, majorly broken the user experience at http://www.mysql.com. Clicking links within the navigation makes it jump up and down erratically, forcing the user to have to click the "jumped link" once again to be able to navigate through the site. It is sufficient to hold the tab button on the keyboard pressed down to navigate between links to see how the page elements jump around.

I don't know if the outlining is what's causing jumping links. It doesn't sound like an immediate correlation. However, the more I surf, the more sites I see that are "ruined" by this effect for me, and for no good reason (see my comment 26). It's quickly becoming less a curiosity and more a major annoyance.

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

Setting the pref browser.display.focus_ring_width to 0 seems to kill most similar borders (e.g. around textlinks, images) but the border around overflow:auto areas discussed here remains the same...

Thanks, Rob! This is definitely useful.

I just filed bug 262577 to address the specific situation where div:overflow elements do not honour the "browser.display.focus_ring_width" preference. I also filed bug 262578 to see if we can get elements outlined only when tabbing into them - not when navigating to them via mouse actions.

Could bug 262401 be related to this bug?

If we fix bug 262578, we don't have to fix this. Right?

> If we fix bug 262578, we don't have to fix this. Right? I believe that would be a fair assessment. Unless there's anybody who clicks on a DIV and still isn't aware of what they've clicked on? I can't think of any such circumstance, but don't want to rule it out blindly if somebody can think of such an example...

Some people have the habit of selecting text while they read it; sometimes this is even necesessary to get the text readable due to bad color selection by the website developer. So they would click on the div and get the outline. (of course they also get the inverted text, disturbing the layout anyway) IMHO the whole focus ring stuff should be made optional. There is a user pref (comment #30) for it, but I have found no UI for it. And not all code obeys it yet. Add some checkmark and/or focus-ring-width field somewhere in the preferences, turn it off by default, and those who need it can enable it without annoying others.

To be honest, I still think we should fix this. It's just nicer to have only keyboard actionable items in the tab order.

Mozilla Windows Trunk Nightly Build Regression Window Pass: 2004071609 Fail: 2004071808

I got to this bug as on my site I also use overflow:auto. More I use border-right: dotted 1px; When I clicked in this element in M1.8a4 I got dotted border around the whole element - I thought border is filled around whole element, but here I see it is not border itself but it is a focus outline. Seems fairly missleading to me. I do not think outline should be shown if focused with mouse.

Adam, you should be more interested in bug 262578. It's actually just waiting final approval.

I believe that the just checked in bug 262578 also fixed this bug. Going to http://home.kairo.at/ I no longer see any focus outline when clicking on the main frame. (The focus outline only appears when tabbing into it which, AFAIK, is what we want to happen.)

Most of the issue was taken care of by the checkin for bug 262578. However, this bug wasn't really just about clicking -- it was really about whether focus outlines should be shown on these elements at all. Changing summary to reflect the current state of things: focus outlines only show up on css scrollable items when the element is tabbed to. I don't think they should be in the tab order at all. Roc disagrees. I want to leave this bug open for feedback for now.

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

Simply right-clicking on the div with overflow:auto; is now showing the dotted border, and it's real nice how it can mess up a layout if a user simply wants to open up a context menu and do so clicking in a div with auto overflow. Aaron Lev, is that patch attached still usable?

(In reply to comment #45) I do not see any troubles with seamonkey 1.0a.

(In reply to comment #45) > Created an attachment (id=198767) [edit] > Aaron Lev, is that patch attached still usable? I'm on vacation until October 17.

I don't see this in Firefox trunk builds.

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

http://www.w3.org/TR/CSS2/visufx.html auto ... but should cause a scrolling mechanism to be provided for OVERFLOWING boxes. I have next form: <form> <div style="overflow: auto;">Label1</div><input> <div style="overflow: auto;">Label2</div><input> <div style="overflow: auto;">Label3</div><input> </form> DIV elements are not overflowed, so they should not provide scrolling mechanism, so they have no need to be accessible through keyboard, so they should not participate in tabordering and MUST NOT be FOCUSable unless overflowed (scroll bars are showed) If I want elements be focused I can do next: <form> <div style="overflow: auto;">Label1</div><input> <div tabindex=0 style="overflow: auto;">Label2</div><input> <div style="overflow: auto;">LabelX</div><input> </form>

so overflow: auto elements with no scrollbar still get tabbed to. that's cool. or is it lame? i'll go with lame. (In reply to comment #11) > I'm OK with switching to depending on scrollbar visibility and seeing how it goes. it sounds like everyone's on board with implementing aaron's patch. why hasn't it landed?

Aaron didn't ask review for his patch. Comment 43 says he wanted to wait for feedback on this. I agree that overflow:auto elements with no scrollbar being tabbable doesn't seem useful. Aaron, do you want to ask review on the patch? Or do you think current behavior is better?

I'm okay with it either way, and I don't have time to deal with it right now. If someone else wants to drive this issue that is fine with me.

+ nsMargin margin = scrollFrame->GetActualScrollbarSizes(); + if (margin.bottom || margin.right) { Should check margin.top and margin.left too; margin.left is certainly possible in RTL situations.

(In reply to comment #34) > Created an attachment (id=161097) [details] > CSS scrollable overflow not focusable unless there are scrollbasrs > This would certainly solve some accessibility issues we're finding with Orca and our caret navigation.

Sorry for the delay.

Checking in nsFrame.cpp; /cvsroot/mozilla/layout/generic/nsFrame.cpp,v <-- nsFrame.cpp new revision: 3.751; previous revision: 3.750 done Checked into trunk.