Often, I read news.com . Beneath their daily list of headline articles, news.com includes a section called "More news from around the Web" . When I click on one of the links that takes me to a new site (say, Forbes.com, Fortune.com, etc), I notice that when the referenced article is loaded at the new site, the space bar does not scroll the article down. Instead, Mozilla's URL text entry box has the focus and so, pressing the space bar simply moves the cursor one char beyond the end of the current URL. IE 5.5 does not exhibit this problem--the space bar scrolls the page down. If it matters, I disable javascript and java in my preferences and I only allow images and cookies that only come from the originating server. This is a very irritating bug. Hope you can fix it soon. I truly enjoy using Mozilla!

ok, i can see this too. went to news.com, selected the link "Better graphics for notebooks", and space did not work. I clicked on the page, still no scrolling on space. Only clicking into a input filed and then clicking on some text made it work. Could not find a dupe -->event handling (seen 2001020704 win32)

Adding ben + alecf who can comment on this. It's a UI issue.

yeah, we need to fix focus.. don't think this belongs to joki though, it's an xpapps issue.

->keybd nav...

Reassigning to owner of Keyboard Navigation...

Here's an observation that may or may not be relevant: from http://bugzilla.mozilla.org/show_bug.cgi?id=67977 click on the "Component" link. Keyboard navigation works (for me). Go back, click on "URL" link (to go to news.com). Keyboard navigation doesn't work. Go back again and look at those two links you followed. "Component" is coloured purple (ie followed) but "URL" is still blue. This is with build 2001022808, Linux.

isn't this a dupe of the general problem of the url bar getting focus too often?

Marking nsbeta1+, p2

Well, I found the problem with with going directly to www.news.com (click on URL link on this bugzilla page), and trying to scroll. The page is inside a framset with a single frame. There is also a problem navigating into framesets from the URL bar. It appears these problems are related. I'm not quite sure why clicking on links to the outside from within news.com exhibit the problem, since the pages that are loaded are not framesets. One clue is that they're server side redirects. Perhaps that in combination with starting from within a frame is what's causing it. However, a plain server-side redirect doesn't reproduce the problem (www.kmart.com).

->aaronl...? or, are you working on this, alecf?

->hyatt

This is two bugs. (1) Focusing a window with a frameset doc should auto-focus the first frame in a DFS search of the doc. This should be recursive. (2) When _top is used to redirect from an inner frame back out, the pres shell's auto-focus code should catch this case. It used to months ago, so this is a regression. Moving to 0.9.1. I obviously can't fix this at the last minute. :)

> (1) Focusing a window with a frameset doc should auto-focus the first frame > in a DFS search of the doc. This should be recursive. I think it would make more sense to do that after loading the page (just before firing a page-specified onload function), and then hope the focus within the window is preserved after switching apps. It might be useful to focus the largest frame instead of the first.

Actually IE does exhibit the problem. IE on news.com does not allow you to scroll with the arrow keys after initially loading the page from the URL bar.

(Sorry for the spam, but I don't know where else it would fit better) This bug is the very reason why I _very much_ dislike CTRL-W being focus dependend (clearing URL-bar when in URL panel, closing window otherwise).

-> bryner to either dismiss or fix as part of his other work

The problem at the news.com front page is now covered by bug 86931, "should automatically focus the largest frame as frameset loads". It's not clear to me what this bug covers... I think it could use a better summary.

worksforme in a current build (on linux), please reopen if you're still seeing the problem.

mass verification of WorksForMe bugs: to find all bugspam pertaining to this, set your search string to "IfItWorksForSlappyTheSquirrelThenItWFM". if you think this particular bug is *still* an open issue, please make sure of the following before reopening: a. that it's still a problem with ***recent trunk builds*** on the all appropriate platform[s] b. provide clear steps to reproduce (unless a good test case is already in the bug report), making sure it pertains to the original problem (avoid morphing as much as possible :)