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.

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

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.

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

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

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

Nominating for nsbeta1 triage.

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

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.

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)

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

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?

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.