Need to show focus within frameset documents

RESOLVED FIXED in mozilla0.9.5



Layout: HTML Frames
18 years ago
16 years ago


(Reporter: Simon Fraser, Assigned: Brian Ryner (not reading))


(Blocks: 1 bug, {helpwanted, polish, sec508})

helpwanted, polish, sec508
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
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.

Comment 1

18 years ago
Mark, can you please triage this from Clayton's list.
Assignee: clayton → attinasi

Comment 2

18 years ago
Sounds like a feature request...
Assignee: attinasi → asa
Severity: normal → enhancement
Component: Layout → Browser-General
QA Contact: petersen → doronr

Comment 3

18 years ago, 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.  

Comment 4

18 years ago
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.
Assignee: asa → pollmann
Component: Browser-General → HTMLFrames
QA Contact: doronr → petersen

Comment 5

18 years ago
not just mac...

is this really an enhancement request?  it's 4xp, and i feel it's pretty 
Keywords: 4xp
OS: Mac System 8.5 → All

Comment 6

18 years ago
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?

Comment 7

18 years ago
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).

Comment 8

18 years ago
Created attachment 11205 [details]
Example of possible style rules to show focus on frame (uses hover to simulate focus however.)

Comment 9

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

Comment 10

18 years ago
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.

Comment 11

18 years ago
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!
Assignee: pollmann → attinasi

Comment 12

18 years ago
Teach me to volunteer information......

Comment 13

18 years ago
Nominating for nsbeta3 - PDT, how important is this?
Keywords: nsbeta3

Comment 14

18 years ago
Milestone set.
Target Milestone: --- → M20
Implementing this would be a big usability win... 
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 

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

Comment 17

18 years ago
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). 


18 years ago
Keywords: polish
[nsbeta3-] and FUTURE.
Whiteboard: [nsbeta3-]
Target Milestone: M20 → Future


18 years ago
Blocks: 47139

Comment 19

18 years ago
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.

Comment 20

18 years ago
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. 

Comment 21

18 years ago
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.

Comment 22

18 years ago
Nominating for Mozilla 0.9
Keywords: mozilla0.9


17 years ago
Blocks: 56540
hi Marc --any progress/status on this recently? thx!
Keywords: nsbeta3 → access, ui

Comment 24

17 years ago
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 :(
Keywords: helpwanted

Comment 25

17 years ago
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.
Severity: enhancement → blocker
Target Milestone: Future → ---

Comment 26

17 years ago
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...
Whiteboard: [nsbeta3-]
Target Milestone: --- → mozilla0.9

Comment 27

17 years ago
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.

Comment 28

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

Comment 29

17 years ago
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.

Comment 30

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

Comment 31

17 years ago
Yes, you can get the focused window from nsIFocusController.

Comment 32

17 years ago
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?

Comment 33

17 years ago
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)

Comment 34

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

Comment 35

17 years ago
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):

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

Comment 36

17 years ago
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. :)

Comment 37

17 years ago
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 

Comment 38

17 years ago
Thanks for the _slap_, David. I wanted a simple solution so bad that I stopped 

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.

Comment 39

17 years ago
>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).

Comment 40

17 years ago
mpt pointed out in bug 59887 that it might make sense to fix this bug and 59887 

Comment 41

17 years ago
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.

Comment 42

17 years ago
Marc, I'll take this off your hands.
Assignee: attinasi → hyatt
Target Milestone: mozilla0.9 → mozilla0.9.1


17 years ago
Blocks: 70229


17 years ago
Priority: P3 → P1
Target Milestone: mozilla0.9.1 → mozilla0.9


17 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 43

17 years ago
QA Contact update
QA Contact: petersen → amar

Comment 44

17 years ago
This is blocking MSAA work ,we need an early ETA date in the status whiteboard ASAP.
Whiteboard: need for embed 0.9


17 years ago
Blocks: 75785


17 years ago
Target Milestone: mozilla0.9.1 → mozilla1.0


17 years ago
Blocks: 77308
Keywords: nsbeta1, nsdogfood

Comment 45

17 years ago
rods is looking into this one.
Assignee: hyatt → rods


17 years ago
Target Milestone: mozilla1.0 → mozilla0.9.2


17 years ago
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 46

17 years ago

Comment 47

17 years ago
Any pointers to how this was done?

Comment 48

17 years ago
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)

Comment 49

17 years ago
Is the focus ring stylable?

Comment 50

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

Comment 51

17 years ago
*   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
    <>, or
    <>, 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.

Resolution: FIXED → ---

Comment 52

17 years ago
I am closing this and opening a Mac specific bug. Bug 85877

Remarking this as fixed.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 53

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

Comment 54

17 years ago
Not showing up on Mac and now Linux, seems like a regression from what I had 

Comment 55

17 years ago
Since it's not working anywhere, reopening.
Resolution: FIXED → ---

Comment 56

17 years ago
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!
Assignee: rods → bryner

Comment 58

17 years ago
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
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 59

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

Comment 60

17 years ago
lowering severity based on this being ok for accessibility requirements.
Severity: blocker → normal


17 years ago
Keywords: nsenterprise

Comment 61

17 years ago
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.
Severity: normal → major
Keywords: fcc508
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 62

17 years ago
moving these out to 0.9.5 since it doesn't look like I will have time for 0.9.4.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
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 ;)


17 years ago
Blocks: 89975

Comment 64

17 years ago
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.

Comment 66

17 years ago
removing nsenterprise keyword
Keywords: nsenterprise

Comment 67

17 years ago
Ian Kennedy: 
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

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.

Comment 69

17 years ago
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.

Comment 70

17 years ago
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).
Last Resolved: 17 years ago17 years ago
Keywords: access
Resolution: --- → FIXED
Whiteboard: need for embed 0.9
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

Comment 72

16 years ago
I don't see any focus indication in current trunk build in modern or classic 
Resolution: FIXED → ---
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].

Comment 74

16 years ago
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. :)

Comment 76

16 years ago
re-marking fixed per sairuh's comments.
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 77

16 years ago
I agree with Simon - showing focus when you tab but not click seems stupid!
You need to log in before you can comment on or make changes to this bug.