When viewing a frameset document, there is currently no indication of which frame has the focus, and thus no way for the user to tell which frame keyboard commands (e.g. page up/down) will apply to. We need to draw a (CSS-controlled) focus ring around the focussed frame.

Mark, can you please triage this from Clayton's list.

Sounds like a feature request...

attinasi@netscape.com, feature requests shouldnt get dumped to the black hole of Browser General. Add the helpwanted keyword if there isn't a developer ready to tackle the issue.

Sorry, Asa, I really thought it was a browser general issue! It is not clear to me what component would be responsible for this, and I didn't know that browser general was a 'black hole'. It sounds like this starts with the Frame, so I'll send it to the HTML Frames component and see if the owner has any ideas. My guess is that there are many areas impacted by this request: the frame has have some kind of focus-attribute, something has to apply some styling to the frame to render the focus-border, and something has to manage tabbing across frames and tracking focus.

not just mac... is this really an enhancement request? it's 4xp, and i feel it's pretty important...

Hey Ben, did you know if a frame can show a focus ring via style yet, or is there more work to be done here?

I found the easiest way is to use the BORDER property since outline properties are not working well... In a test document this works: :root {border: 2px solid transparent; } :root:hover {border: 2px solid black; } Of course the hover is just to make an easy test. A better approach would be to use an attribute on the :root element, so we could use rules in html.css like: :root {border: 2px solid transparent; } :root[focus] {border: 2px solid black; } Some code has to set and clear the attribute to make this work, however. I have heard that the outline property will not be fixed for first release, so we probably need to use the outline (see bug 9809).

Okay, no problem then. This is just another style rule to add (see the other focus ring rules for what to key off of)

Not sure if it is that easy... I tried using the :focus like the other focus ring rules use and it does not seem to work on the :root pseudo-element. Something probably has to be changed to make the root element think that it has focus at the right time, then we could use :root:focus as the selector, however it currently fails for me.

Chris, or Marc, is this bug in your area? It seems like Marc has made some progress on it - so I'm handing it off. :) If I can help, let me know!

Teach me to volunteer information......

Nominating for nsbeta3 - PDT, how important is this?

Milestone set.

Implementing this would be a big usability win...

oops. Note however that in 4.x, this was more than just a border. The border was drawn over the content rather than indenting it by 2-3 px. Just using a border would have the effect of shifting the document's content around as focus shifted. The other thing to consider is that in 4.x, this focus ring was not drawn on pages that had disabled frame borders (for cosmetic reasons). That said, the border idea is a good start :)

Ben, the way I suggested the style rules the content would not shift as the non-focused frame gets the same border width, it is just that the border is transparent. Shifting the content when focus shifted would be way-wrong. That said, introducing a 2px 'margin' for non-focused frames is probably a waste of real estate, albeit minor. I cannot imagine we would ever want to draw the focus indicator *over* the content (maybe in QuirksMode we _could_, but is it really desirable to obliterate content?), however using an outline instead of a border is the correct solution - it is just that outlines don't work yet. Also, if there is a style rule in the document disabling borders on the root element then there will be no border drawn, thanks to the magic of the cascade. So, as Ben suggested, the border solution will pass for now, at least there will be some indication that the frame is selected. Future enhancements include: - use outline instead of border to avoid the 2px 'margin' for non-focus frames - NavQuirk mode: possibly draw the selection over the content (eech) Another additional consideration is that we probably don't need to put the focus indicator (border) around non-frameset pages, something that the style rules I proposed currently will do (if the FrameStateManager actually set the focus at all, that is).

[nsbeta3-] and FUTURE.

Note that this may also be important in mail. In the mail 3-pane, keyboard commands are focus-sensitive, so you have to be able to see which pane has focus.

I think Andrew was working on a bug to implement this in mailnews for us using xul and CSS for the mail 3-pane. cc'ing him.

The mail/news bug was bug 28519, and Andrew has just fixed it. Various comments ... * This should probably apply to all documents, and not just framesets. Otherwise I'll have no way of telling (for example) whether focus is in the content area or whether it is in the sidebar. * This should apply to all document types (including text/plain, text/xml, and image/whatever), because the contents of an HTML frame could be any of these. So just changing html.css probably isn't going to fix the bug entirely. * A 2px border might be too large, especially for frames which have margins of size 0. Didn't 4.x use 1px instead? * In a perfect browser, when I put focus in a text field, the focus ring would disappear from the frame as a whole, and appear around only the text field.

Nominating for Mozilla 0.9

hi Marc --any progress/status on this recently? thx!

I haven't been looking at it this at all. I am relegated to memory footprint issues now... Please feel free to reassign if you know of a candidate. Sorry :(

Clearing target milestone to get back on radar, setting to blocker severity. Marc, according to our new accessibility lead, Aaron Leventhal, this work is needed to make Gecko accessible, which is a very high priority requirement.

Future to blocker in one wave of the mouse - OK, I'll dig in. Marking Mozilla 0.9 and clearing old cruft from the Status Whitebread, er, Whiteboard. Notice the HELPWANTED keyword here? I could use some help because I do not have a clue how to make a frame become focused...

Hmmm. I question the prioritization of this bug as a blocker. It's also tricky to fix, since you need a way to draw a focus ring on top of the view and not as a border around the view. CSS provides no mechanism for doing something like this. The closest thing I can think of is CSS's concept of outline, but I don't see how drawing outside your frame will help you here, since with frames in framesets there's no room to draw the outline.

Fixing this bug will be vital to allow sensible editing in framesets. The user * has* to be able to see which has focus.

My earlier idea was to just use a border to simulate the Nav behavior. It is not perfect, but it will allow users to see which frame has the focus. However, there is still the problem of figuring out how to make the frame know that it has focus, and for that I am at a loss. Another possibility for the focus indication is to introduce a new mechanism (non-standard) for drawing a rect into the padding area, but that will take a lot longer and is probably better left for later.

Doesn't our existing focus mechanism already know which frame has focus? Saari should be able to provide enlightenment here.

Yes, you can get the focused window from nsIFocusController.

yeah, rods and I discussed this a while ago. The issue ultimately boiled down to how do you associate the nsFrameFrame from a walk up the frame tree in nsEventStateManager::PostHandleEvent when we first set focus; the nsFrameFrame lives in the parent doc and there is no direct connection that I'm aware of so where do you go to get the nsFrameFrame to set style on? Can we get to that nsFrameFrame from the nsDOMWindow instead?

What about the FRAME content element itself? Can we put an attribute on that (e.g. 'focus') and then use that to style the frame? (please excuse my complete ignorance obout how frames/framesets work in terms of layout)

We'd have the same problem as I understand it: finding the right frame element.

OK, I tried a few things out and this is mostly working now. I'm not sure if it is correct, but the frame with the focus shows a focus indicator. I used rules on the HTML element like (in html.css): HTML { -moz-user-focus: normal; border: 2px solid transparent; } HTML:focus { border: 2px solid black; } and then I had to remove a check in nsCSSStyleSheet that prevented focus indications on the HTML element (nsCSSStyleSheet.cpp): [...] } else { // selector is not global, so apply the event pseudo to everything except // BODY return PRBool (/*(nsHTMLAtoms::html != aContentTag) && */ (nsHTMLAtoms::body != aContentTag)); } So now when I click in a frame it shows focus, and when I click in another frame it shows focus, however the first one does not erase its focus until I hover over it again(!). The TAB-key does not switch focus between the frames either. I need help on this part since it is definitely NOT an area I am familiar with. I'm feeling like I can take care of the Style issues, now we need to fully resolve the remaining focus issues.

Ack, this won't work. (1) user-focus is an inherited property, so you can't do this. Making it non-inherited would be the sensible thing, but then many chrome style rules will have to be fixed, because they were relying on the inheritance. The inheritance totally prevents you from doing this on the root, since elements within <html> will start becoming focusable as well. (2) You've (for the first time) created a hierarchical focus situation, which Tantek was opposed to (remember the discussion at Houlihan's in Boston). :focus is not currently hierarchical, which means clicking in a form field like a text field will cause the frame to incorrectly lose its focus border. (3) Tabbing cannot deal with this kind of hierarchical situation, and you'll need to patch the tabbing code or all kinds of tabbing confusion will result. This bug is a nightmarish rathole. You could keep going with this approach, in which case the things I mention will have to be patched, or we could try something else. :)

I think that if a textbox within a frame is focused, the frame itself shouldn't appear to have focus, since it won't recieve most keyboard events (such as scrolling keys). See also bug 5693 for discussion about what should be hierarchical and what shouldn't.

Thanks for the _slap_, David. I wanted a simple solution so bad that I stopped thinking. OK, who wants this bug now? Seriously, if it is really blocker-class then it is in the wrong hands. Event State management is not my area and I have a bunch of important layout and style problem to tend to for Moz 0.8.1 and 0.9. I am very happy to help out on the styling end (and wherever else I can) but I cannot drive this - it impacts too many areas that I have no clue about. Someone throw me a bone here, please.

>however the first one does not erase its focus until I hover over it again (!) This problem may be related to bug 70255, "tab/shift+tab to message pane doesn't blur thread/folder pane correctly (selection remains blue)". It might also be related to a problem mentioned on bug 64150 where clicking on a prefs panel doesn't make the category tree appear to lose focus (and vice versa).

mpt pointed out in bug 59887 that it might make sense to fix this bug and 59887 together.

Jumping back to my comments of finding the associated nsFrameFrame, Brendan pinged me and noted that there might be a list of nsFrameFrames in the PresShell, so we may be able to do a lookup in that list and then set style on the nsFrameFrame, giving the visual focus ring, but none of the nasty side effects. Of course the same code would unset the previous nsFrameFrame :focus when blured.

Marc, I'll take this off your hands.

QA Contact update

This is blocking MSAA work ,we need an early ETA date in the status whiteboard ASAP.

rods is looking into this one.

fixed

Any pointers to how this was done?

I don't remember the bu number now, but I checked in the fix as part of the entire nav of panes/frames. The focus "ring" is now hard coded in nsHTMLFrame.cpp (the canvas frame)

Is the focus ring stylable?

I wanted to, but I didn't have time to do that. But I am sure bryner wouldn't mind someone doing it though.

Build: * 2001061305, Mac OS 9.1 * either Classic or Modern theme (not that it should matter, if the focus ring isn't stylable) To reproduce: * Choose `Debug' > `Verification' > `Frames', or go to <http://msdn.microsoft.com/library/default.asp>, or <http://www.ecnet.net/users/gas52r0/Jay/>, or any other framed page. * Click in each of the frames in turn. What you should see: * The focus ring which rods sez he put in. What you actually see: * Nothing. Reopening.

I am closing this and opening a Mac specific bug. Bug 85877 Remarking this as fixed.

i'm not seeing any focus ring on linux 2001061408 either..

Not showing up on Mac and now Linux, seems like a regression from what I had working.

Since it's not working anywhere, reopening.

The focus ring is only shown if you navigate into the frame with tab, not with a click. I've got an idea how to fix it but the frame navigation code is fairly complex and I'm still trying to understand how it's all intended to work.

tentatively reassigning to bryner... bryner, feel free to punt as needed!

Sounds like that may be good enough for accessibility. Given our bug load, and the fact that this is not blocking anything needed for 0.9.2, I think this will have to take its chances in 'limbo'. ->0.9.3

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

lowering severity based on this being ok for accessibility requirements.

Adding fcc508 keyword (FCC Section 508 accessibility regulations). We cannot legally sell Mozilla-based products to the US Federal Goverment without having a visual indication of the current keyboard focus. If you click in a frame, there is no visual indication that the keyboard focus is there. Resetting severity to Major.

moving these out to 0.9.5 since it doesn't look like I will have time for 0.9.4.

Can I point out that it is posible to disable this feature in 4.x using the frameborder=0 element of the <frame> tag. This version *MUST* be able to be disabled in the same manor. First, because the HTML standard says so and secondly because I hate those focus boxes all over the place ;)

um, the idea of fcc508 should be that user.css should be able to !important overrule the page either way, so the user could decide to per fcc508 force the focus ring, or the user could decide like Ian Kennedy that there's no need to ever show it (for his profile)

I was talking about the web page designer being able to hide the focus ring for their frames layout, rather than making it a user option. In 4.x the focus ring used the frame border to show it's highlight, if the border was disabled with a <frame frameborder=0> tag then it didn't show.

removing nsenterprise keyword

Ian Kennedy: http://www.w3.org/TR/html401/present/frames.html#adef-frameborder talks about drawing separators/resizers between frames, not about showing focus. I don't think showing a focus border would violate the HTML4 standard. It might look a little strange to show a focus ring around an otherwise borderless frame, but keyboard users need to be able to see focus. One possible solution is to only show the focus ring if the user focuses the frame using the keyboard (tab or ctrl+tab). IE does that on *all* frameset pages (with and without frameborder set), but mpt and aaronl don't seem to like that solution.

i too would have to disagree with the IE solution. i think the focus ring should be displayed regardless of how the user focuses a frame [be it by mouse or keyboard]. using 2001.08.28.0x-comm bits, i can only see the focus ring when i use ctrl+tab/shift+ctrl+tab or f6/shift+f6, not when clicking w/mouse. [per bryner's 2001-06-18 01:30 comments.] moreover, the focus ring disappears when i start to navigate in the frame [again, by design]. in comm 4.7x [at least on linux and win32], as well as IE5.5 on win32, the focus ring persists while navigating. chatted to bryner about implementing this, but as things stand now, it'd result in a bad perf hit and perhaps even a jittering focus ring. alas.

What about non-frameset documents? It would be ugly to show the focus ring all the time, but keyboard-only users need to be able to tell when they've focused the document.

I think we're good enough for accessiblity concerns here. Can we open other bugs for requested different behavior please? I'm closing this since we do actually show the focus in framesets the way IE does (right or not this bug isn't representative of the debate over when to show it).

okay, i've filed new bugs for the following issues: bug 102052 - implement mouse click to display focus ring for frame bug 102053 - focus ring shouldn't disappear while scrolling

I don't see any focus indication in current trunk build in modern or classic themes.

this wfm on linux and mac os x: i can see the active frame [as a dotted outline] when i use keyboard navigation [tabbing or ctrl+tabbing]. once i start to scroll, however, the dotted outline goes away [which is by design].

Charley: the idea is that frameset focus is supposed to show up when you tab into a frame, but not click (which, to me, is stupid, but there you go).

yes, bug 102052 was wontfix'd. but bug 102052 comment 9 sounded rather nifty. :)

re-marking fixed per sairuh's comments.

I agree with Simon - showing focus when you tab but not click seems stupid!