Closed Bug 42758 Opened 24 years ago Closed 23 years ago

Need to show focus within frameset documents

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P1)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: sfraser_bugs, Assigned: bryner)

References

(Blocks 1 open bug)

Details

(Keywords: access, helpwanted, polish)

Attachments

(1 file)

Example of possible style rules to show focus on frame (uses hover to simulate focus however.)
(deleted), text/html
Details 
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.
Assignee: clayton → attinasi
Sounds like a feature request...
Assignee: attinasi → asa
Severity: normal → enhancement
Component: Layout → Browser-General
QA Contact: petersen → doronr
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.
Assignee: asa → pollmann
Component: Browser-General → HTMLFrames
QA Contact: doronr → petersen
not just mac...

is this really an enhancement request?  it's 4xp, and i feel it's pretty 
important...
Keywords: 4xp
OS: Mac System 8.5 → All
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!
Assignee: pollmann → attinasi
Teach me to volunteer information......
Status: NEW → ASSIGNED
Nominating for nsbeta3 - PDT, how important is this?
Keywords: nsbeta3
Milestone set.
Target Milestone: --- → M20
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).
Keywords: polish
[nsbeta3-] and FUTURE.
Whiteboard: [nsbeta3-]
Target Milestone: M20 → Future
Blocks: 47139
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
Keywords: mozilla0.9
Blocks: 56540
hi Marc --any progress/status on this recently? thx!
Keywords: nsbeta3 → access, ui
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.
Severity: enhancement → blocker
Target Milestone: Future → ---
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
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.
Assignee: attinasi → hyatt
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9 → mozilla0.9.1
Blocks: 70229
Priority: P3 → P1
Target Milestone: mozilla0.9.1 → mozilla0.9
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.9.1
QA Contact update
QA Contact: petersen → amar
This is blocking MSAA work ,we need an early ETA date in the status whiteboard ASAP.
Whiteboard: need for embed 0.9
Blocks: 75785
Target Milestone: mozilla0.9.1 → mozilla1.0
rods is looking into this one.
Assignee: hyatt → rods
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.2
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I am closing this and opening a Mac specific bug. Bug 85877

Remarking this as fixed.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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
Status: REOPENED → NEW
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
*** Bug 85877 has been marked as a duplicate of this bug. ***
lowering severity based on this being ok for accessibility requirements.
Severity: blocker → normal
Status: NEW → ASSIGNED
Keywords: nsenterprise
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
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 ;)
Blocks: 89975
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
Keywords: nsenterprise
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).
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 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
I don't see any focus indication in current trunk build in modern or classic 
themes.
Status: RESOLVED → REOPENED
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].
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
I agree with Simon - showing focus when you tab but not click seems stupid!
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: