86931 - should automatically focus the largest frame as frameset loads

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Suresh]

If I goto www.news.com and use keyboard uparrow, downarrow, page up, page dowm
to scroll, it doesn't work. 

Build: Today's commercial build on Win NT.

Comment 1

[Suresh]

Nominating! I'm pretty sure most the user will use keyboard navigation.

Comment 2

[joki (gone)]

After clicking in the page it then scrolls okay.  This is probably a dupe of one
of saari's initial focus bugs although it is interesting that it seems localized
to this page.

Comment 3

[saari (gone)]

Yup, it is the frameset on the page. Try it on IE, it doesn't work there either.

Comment 4

[saari (gone)]

giving to bryner, since he might know how to do it best. Not high priority

Comment 5

[Peter Trudelle]

What is the rationale for focussing the largest frame?  Do we really want
different behavior from IE6?

Comment 6

[Brian Ryner (not reading)]

Nominating for nsbeta1 triage.

Comment 7

[Peter Trudelle]

nsbeta1- per ADT triage team, cc marlon for possible wontfix or invalid.

Comment 8

[Jesse Ruderman]

Rationale for focusing the largest frame:

* You can't do anything interesting when focus is on a frameset.  You can tab to
other elements and use Ctrl+U to get the frameset source, but you can't scroll.

* In one type of frame setup, sometimes called URL cloaking, there is only one
frame.  If the frameset is focused instead of the frame, using the arrow keys to
scroll does nothing, Mozilla looks broken.

* In most frame setups, the largest frame contains the main content of the page.
 This is the frame the user is most likely to want to scroll.  Again, it might
not be obvious to the user that the page is a framed page (especially if the
navigation frame is on the left), so we shouldn't surprise him by ignoring his
keystrokes.

One disadvantage of focusing the largest frame is that tabbing might not start
from the upper left corner of the page, but tabbing to links is much less common
than scrolling.  Also, scrolling is usually done before selecting a link, so it
makes sense for focus to start in the best place for scrolling.

Comment 9

[marlon bishop]

i see your point, but i don't think it's right to guess which frame the author
intended the user to interact with by choosing the biggest one.  it would be
great if web page author could dictate which frame received focus on loading the
frameset. but given a reasonable focus order, i don't think that most users who
encounter frames will be upset by having to tab to desired frame.  

However, one scenario that might be reasonable to consider is to give initial
focus to any frame which had a scrollbar.  That would cover most cases.  This
way  the user is still sheltered from having to deal with the underlying
structure (frames) of a site. If there were more than two scrollbars showing,
then we go back to focusing the frameset, and let the user decide. 

Scrolling is the foremost activity when browsing webpages (aside from reading)

Comment 10

[Greg K.]

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

Comment 11

[Jesse Ruderman]

Marlon: I don't like the idea of "focusing the frame with scrollbars".  What if
multiple frames have scrollbars?  What if a site has multiple framed pages with
the same structure, but some content pages have scrollbars and some don't?  Have
you ever encountered a page where the main content was in the smallest frame?

Comment 12

[Jesse Ruderman]

Google Groups's framed-thread view uses javascript to focus the largest frame. 
This causes several problems: the large frame doesn't gain focus until it
finishes loading, the window jumps to the front when the frame finishes loading
(bug 196922), the window jumps to the front if you load the large frame outside
of the frameset, etc.

The fact that Google Groups has kept that javascript in place despite Brett
Tabke's repeated whining that it causes the window to steal focus suggests that
this bug is important.