open link in a new window. mozarea focus_in, no call to nsWindow::SetFocus => null sFocusWindow
VERIFIED
FIXED
in mozilla0.9.2
Status
()
People
(Reporter: ryampols, Assigned: bryner)
Tracking
(Blocks: 1 bug, {access})
Firefox Tracking Flags
(Not tracked)
Details
(Whiteboard: se-radar)
Attachments
(5 attachments)
854 bytes,
patch
|
Details | Diff | Splinter Review | |
2.29 KB,
patch
|
Details | Diff | Splinter Review | |
2.29 KB,
patch
|
Details | Diff | Splinter Review | |
5.51 KB,
patch
|
Details | Diff | Splinter Review | |
5.63 KB,
patch
|
Details | Diff | Splinter Review |
I find that most of the time, the arrow keys won't work to scroll a web page until you explicitly click inside the page with the mouse. Even clicking doesn't always make the arrow keys work.
Comment 1•19 years ago
|
||
Rob Yampolsky, what build did you test?
Comment 2•19 years ago
|
||
worksforme 2000102604 win98 mozilla trunk
Comment 3•19 years ago
|
||
I also saw this many times. I'm using a wheel mouse + some time keyb to navigate. Today I had this situation: I scrolled a page with wheel, then wanted to scroll it with arrows, but no effect. Clicking in the page solved it. It is a focus problem, that is not always given to the rendered page. Currently on 2000102704-Mtrunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•19 years ago
|
||
I can find lots of places where keyboard scrolling does not get hooked up. For example, go to http://www.anandtech.com. Then click on a link for any review. When the new page loads, you can't scroll with the keys. Click to the next page. Can't scroll again. Sometimes, clicking in the content window restores keyboard scrolling, sometimes not. Who is grabbing the keyboard input focus during page load? Linux 2000-11-05-06 Trunk.
Assignee: asa → don
Severity: minor → major
Component: Browser-General → Keyboard Navigation
QA Contact: doronr → sairuh
Updated•19 years ago
|
OS: Windows 98 → All
Modifying summary to reflect that all scroll-keys are on occation affected by this bug. (both arrows and page up/down)
Summary: Arrow keys don't always scroll the page. → keys don't always scroll the page.
Comment 7•19 years ago
|
||
It would be very bad for me if I didn't had a wheel mouse... Marking as dogfood-.
Keywords: dogfood
Whiteboard: [dogfood-]
Comment 8•19 years ago
|
||
I also see this on many pages, using Linux CVS 20001119 build (also earlier builds), like this one: http://slashdot.org/article.pl?sid=00/11/20/1239211&mode=flat&threshold=2
Comment 9•19 years ago
|
||
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Comment 10•18 years ago
|
||
I've run into a lot of pages where clicking in the window didn't allow the arrow keys to begin working, but only on post-RTM nightlies. Netscape 6.0 and previous nightlies worked great for me. This is on NT4sp6a.
Comment 12•18 years ago
|
||
p1
Assignee: vishy → mcafee
Priority: P3 → P1
Target Milestone: --- → mozilla0.9
Comment 13•18 years ago
|
||
*** Bug 67920 has been marked as a duplicate of this bug. ***
Comment 14•18 years ago
|
||
reporter in bug 67920 mentions another site: http://linuxtoday.com/
Comment 15•18 years ago
|
||
I have stumbled over a 100% reliable (for me) way of reproducing this. (On a current Linux CVS build). How to do it: - have your sidebar closed/not shown. - show it with F9 or View|My Sidebar. The page will scroll from the keyboard. - close it with F9 or View|My Sidebar. The page will no longer scroll from the keyboard. If you refresh the page, it will scroll again. Hopefully this is the same bug, and not an unrelated one that just has the same symptoms. Also hopefully this bug can be fixed soon. I certainly find it a nasty usability hit when my scrolling breaks periodically.
Comment 16•18 years ago
|
||
*** Bug 69314 has been marked as a duplicate of this bug. ***
Comment 17•18 years ago
|
||
Changing platform to ALL as duplicate bug 69314 is on the Mac.
Hardware: PC → All
Comment 18•18 years ago
|
||
Build ID: 2001021820 Platform: win32 I found an interesting reproducible behaviour here: It happens always when you open then close My Sidebar, but if after this you enter (click in) any form element such as INPUT box, TEXTAREA or a SELECT (drop-down), and then click on the page anywhere, the scroll keys start working again!
Comment 19•18 years ago
|
||
Wow, nice observation. I too can re-enable keyboard scrolling on these broken pages by focussing an input box and then the page. Non-obvious workaround, but helpful nonetheless.
Comment 20•18 years ago
|
||
After the form-related comments were added, I started paying attention to forms on pages that gave me this problem... So far, they're all pages with forms and the workaround mentioned above reliably fixes it for me.
Comment 21•18 years ago
|
||
Could this bug be related to the mostfreq bug 54936? (Dismissing a dialog confuses focus)
Updated•18 years ago
|
Keywords: nsdogfood-
Updated•18 years ago
|
Keywords: nsdogfood
Comment 22•18 years ago
|
||
adding nsCatFood --i take it for granted that this should work. and i think many other users would too.
Keywords: access, nsCatFood
Whiteboard: [dogfood-]
*** Bug 70342 has been marked as a duplicate of this bug. ***
Comment 24•18 years ago
|
||
nav triage team: Reassigning to pchen and setting target milestone to mozilla0.9.1
Keywords: nsbeta1 → nsbeta1+
Target Milestone: mozilla0.9 → mozilla0.9.1
Comment 26•18 years ago
|
||
*** Bug 69812 has been marked as a duplicate of this bug. ***
Comment 27•18 years ago
|
||
*** Bug 70441 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Keywords: nsCatFood → nsCatFood+
Comment 28•18 years ago
|
||
Created attachment 32819 [details] [diff] [review] Fix for sidebar focus issue (press F9 to close sidebar leaves content area unfocused)
Comment 29•18 years ago
|
||
Spun off bug 78440 for the sidebar issue (closing with F9 doesn't set focus on content area) which is separate from the initial bug and for which we have a fix (as attached above).
Comment 30•18 years ago
|
||
Here's another URL: http://www.msnbc.com/news/568651.asp?0nm=C17O&cp1=1 I can't do anything to make keyboard scrolling work on this page with 0.8.1
Comment 31•18 years ago
|
||
I've fooled around with this a bit and found some more info; I'm using build 2001050506 on Linux. Go to http://www.fanfiction.net/, then select the "Anime" fanfic directory (though I suspect that any of the others would work as well); keys don't work for scrolling, even after you use the mouse to click on the content of the window. This *only* happens if you access the page through a link; if you get there through a bookmark, by middle clicking a non-link area of the window with that page's URL in the clipboard, or if you paste the URL into the URL bar, then you can scroll with the keys. Once you're in the state of not being able to scroll with the keys, even after clicking with the mouse inside the content area of the window - You can get back key control of scrolling by right clicking on a link, and then either pressing escape or clicking somewhere on the page; it doesn't matter if the context menu pops up or not. - Middle clicking any of the links immediatly gets back control (as soon as you get back to that window). - Reload the page and click on the content of the window; you'll be able to scroll with the keys. Reload it again, and you can't scroll with the keys, even after cliking on the window. Repeated reloading just alternates between these two. - Transfer focus to another window, transfer it back again, and click on the content of the window; you'll now be able to scroll with keys. (This is using KDE 2.1) - Transfer focus to the URL bar (using CTRL-L or the mouse), then back to the content area; you now have control back.
Comment 32•18 years ago
|
||
*** Bug 78752 has been marked as a duplicate of this bug. ***
Comment 33•18 years ago
|
||
this bug has lots of votes we shd try hard to fix it.
Comment 34•18 years ago
|
||
nav triage: moving this to mozilla0.9.2.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 35•18 years ago
|
||
*** Bug 81337 has been marked as a duplicate of this bug. ***
Comment 36•18 years ago
|
||
For me, I can be on any page. Alt Tab once to go to another app. Alt Tab again to move back. Your scrolling keys no longer work.
Comment 37•18 years ago
|
||
*** Bug 71493 has been marked as a duplicate of this bug. ***
Comment 38•18 years ago
|
||
aaronl, that's for win32-only, right?
Comment 39•18 years ago
|
||
Yikes no... I only use the Unix build.
Comment 40•18 years ago
|
||
weird, then i completely misheard you during the mtg today when i thought you were describing/showing it on win32. anyhow, i'm getting rather bleary-eyed at the moment... :)
Comment 41•18 years ago
|
||
Perhaps you're confusing me with Aaron Leventhal (or I'm confusing myself with him!) Sorry for butting into your conversation :-)
(Assignee) | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
(Assignee) | ||
Comment 44•18 years ago
|
||
84501 covers the case of switching to another app and back, on win32.
Depends on: 84501
(Assignee) | ||
Comment 45•18 years ago
|
||
With saari's patch for 84501, on Windows 2000, I tested all the cases mentioned in this bug, with the exception of the MSNBC article (404) and the fanfiction.net link (server seemed to be down). Keyboard scrolling worked in all cases. Will test Linux next.
Comment 46•18 years ago
|
||
bryner, I don't see how that could possibly fix anything in Linux since the patch is a one-liner to widget/src/windows, not widget/src/gtk
(Assignee) | ||
Comment 47•18 years ago
|
||
Hence my comment saying I'll need to test on Linux. I believe 84501 just fixes the cast of alt-tabbing to another app and back, which I don't think was broken on Linux.
(Assignee) | ||
Comment 48•18 years ago
|
||
This all seems to work on Linux too, except for the case where you open a link in a new window (investigating that now). Does anyone have any other cases on Linux where keyboard scrolling gets broken?
(Assignee) | ||
Comment 49•18 years ago
|
||
I'm seeing two distinct problems that can come up here, on Linux, both seem to be triggered by opening a link in a new window. The first problem is where, is far as I can tell, the event gets dispatched to the wrong window. I deduced this by tracking what happened when the PresShell called HandleDOMEvent -- it went into nsHTMLAnchorElement, but there were no anchor elements on the page I was on. I haven't completely tracked through what happens after this, but I'm not surprised that we don't scroll. The second problem (and possibly related), is that if I alt-tab into the window that I opened the link into, we don't even make it into the PresShell when you use the arrows. It does come into the GTK widget code though-- one thing I noticed was that sFocusWindow is null. blizzard, what does that mean? gdb was giving me a hard time and I couldn't trace into the widget's event callback. Clicking in the window, or selecting it from the gnome taskbar, however, lets it scroll.
(Assignee) | ||
Comment 50•18 years ago
|
||
In the cases where it fails (and this seems to be timing-related, as I can reproduce it on the network but not locally), we are getting the mozarea focus_in but nsWindow::SetFocus is never getting called. These leaves us with a null sFocusWindow. In the cases where it works, SetFocus is getting called for the new window and everything is fine.
(Assignee) | ||
Comment 51•18 years ago
|
||
I've narrowed this case down to a problem that can happen in handling NS_DEACTIVATE where SuppressFocus isn't called on the right FocusController (either that, or the blur event is sent to the wrong EventListenerManager).
(Assignee) | ||
Comment 52•18 years ago
|
||
Ok, found it. This patch fixes some cases where the focus controller would end up with a null current window... which causes key events to go to the wrong window, on Linux.
(Assignee) | ||
Comment 53•18 years ago
|
||
Created attachment 37775 [details] [diff] [review] patch to fix focus controller
(Assignee) | ||
Comment 54•18 years ago
|
||
Created attachment 37806 [details] [diff] [review] patch with improved comments
Comment 55•18 years ago
|
||
So bryner, does it look we're suppressing the wrong command dispatcher because we get the wrong global object? That would be bad...
(Assignee) | ||
Comment 56•18 years ago
|
||
Created attachment 38346 [details] [diff] [review] patch #2
Comment 57•18 years ago
|
||
Looks ducky! r=saari
(Assignee) | ||
Comment 58•18 years ago
|
||
Oops! I accidentely removed a null check along with the debugging spew when I was cleaning up this patch to attach to the bug, and it turns out to cause crashes. Patch #3 coming up (exactly the same with the addition of the null check).
(Assignee) | ||
Comment 59•18 years ago
|
||
Created attachment 38587 [details] [diff] [review] patch #3
Comment 60•18 years ago
|
||
A nervous sr=hyatt
(Assignee) | ||
Comment 61•18 years ago
|
||
Just to clarify, I tested all the cases listed in this bug on Linux (with patch #3 applied) and scrolling works as expected in all cases.
Comment 62•18 years ago
|
||
a=tor for trunk checkin
(Assignee) | ||
Comment 63•18 years ago
|
||
Checked in the patch. Since all of the cases mentioned in this bug seem to be working now, marking this bug FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Comment 64•18 years ago
|
||
*** Bug 80340 has been marked as a duplicate of this bug. ***
Comment 65•18 years ago
|
||
okay, tested using linux 2001.06.19.08 comm verif bits --i'll get to the Mac and WinNT bits later on. * keys used to test: arrow keys, pageUp/pageDown, Home [top of page] and End [end of page] * tested many of the links here [just by clicking their links], and am able to scroll with the keyboard. * scrolling works after loading a page from the urlbar [used ctrl+L to select, then entered a url]. * scrolling works after hitting alt+left arrow and alt+right arrow [going Back and Forward]. * scrolling works in the new window after middle+clicking a link. * scrolling works after selecting these context menu items for a link: - Open Link in New Window [from both framed and non-framed pages] - Open Frame in New Window the only place [so far] that scrolling doesn't seem to work is when i selected Show Only This Frame from the context menu of a link in a frame. however, i'll file a separate bug, rather than reopening this on for that case.
Comment 66•18 years ago
|
||
another test on linux [almost forgot]: scrolling works after selecting an item from the Bookmarks menu [main menu and toolbar menu].
Comment 67•18 years ago
|
||
yet a couple more tests on linux in which scrolling via keyboard works: * the alt+tab btwn windows/apps that aaronlev mentioned. * when i have 2 browser windows, and close [used ctrl+w] the topmost/active one, i can still scroll in the remaining window using the keyboard.
Comment 68•18 years ago
|
||
2001.06.19.08 comm verif bits on Mac OS 9.0x also pass. * keys used to test: arrow keys, pageUp/pageDown, and Home [top of page]; no end key on my keyboard. :( * tested many of the links here [just by clicking their links], and am able to scroll with the keyboard. * scrolling works after loading a page from the urlbar [used cmd+L to select, then entered a url]. * scrolling works after hitting cmd+left arrow and cmd+right arrow [going Back and Forward]. * scrolling works after selecting these context menu items for a link: - Open Link in New Window [from both framed and non-framed pages] - Open Frame in New Window * scrolling works after selecting an item from the Bookmarks menu [main menu and toolbar menu]. * when i have 2 browser windows, and close [used ctrl+w] the topmost/active one, i can still scroll in the remaining window using the keyboard. also have the problem with Show Only This Frame...filed bug 86745.
Comment 69•18 years ago
|
||
s/ctrl+w/cmd+w in previous comment. :)
Comment 70•18 years ago
|
||
2001.06.19.11 comm verif bits on winNT also work nicely [except for bug 86745]. * keys used to test: arrow keys, pageUp/pageDown, Home [top of page] and End [end of page] * tested many of the links here [just by clicking their links], and am able to scroll with the keyboard. * scrolling works after loading a page from the urlbar [used ctrl+L to select, then entered a url]. * scrolling works after hitting alt+left arrow and alt+right arrow [going Back and Forward]. * scrolling works after selecting these context menu items for a link: - Open Link in New Window [from both framed and non-framed pages] - Open Frame in New Window * scrolling works after selecting an item from the Bookmarks menu [main menu and toolbar menu]. * the alt+tab btwn windows/apps that aaronlev mentioned. * when i have 2 browser windows, and close [used ctrl+w] the topmost/active one, i can still scroll in the remaining window using the keyboard. moreover, i also verified [and the 3 platforms] that: * keyboard scrolling works after hitting the Back and Forward *buttons*. * keyboard scrolling works in the source page *without* having to click in it first. * holding down the arrow keys, PageUp, PageDown and spacebar still works as well as tapping the keys. [didn't really try holding down more than one key at a time --iirc, only one key type is processed-- eg, if i hold down the right and down arrow keys, the page only scrolls to the right. not sure if there's a bug filed on that already...]
Status: RESOLVED → VERIFIED
Comment 71•18 years ago
|
||
*** Bug 81973 has been marked as a duplicate of this bug. ***
Comment 72•18 years ago
|
||
This is from Mozilla 0.9.2, which was released after this bug was closed. Keyboard scrolling still doesn't always work. Steps to break: Precondition: You'll need to have the search tab open 1) File -> New Navigator Window 2) Open arbitrary page by using the bookmarks button to the right of `Home.' 3) Try to scroll by using the keyboard. Note that the Search entry box has focus and scrolls --- not the page.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 73•18 years ago
|
||
I just checked 2001070508; same problem as w/ 0.9.2 (plus some others, but that's expected)
Comment 74•18 years ago
|
||
anthony, could you pls open a new bug for what you're seeing? thx a lot!
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Comment 75•18 years ago
|
||
Verifying, as nothing actually happened since the bug was verified/fixed for the first time (Anthony's bug is a separate issue).
Status: RESOLVED → VERIFIED
Comment 76•18 years ago
|
||
Anthony: it sounds like you're running into bug 76621, "sidebar elements should not grab focus from other parts of window".
Comment 77•18 years ago
|
||
The keys and mouse wheel still don't scroll a new window that's opened by clicking a link from another Macintosh application. You must click in the newly created topmost window first to set the focus. To reproduce: Go to another Macintosh application and click on a link that will send an event to Netscape 6 and open a new topmost window. If the window has a scroll bar, the PageUp and PageDown keys will not scroll the page. The mouse wheel won't work either until you click in the window.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 78•18 years ago
|
||
Don't zombify bugs. this bug was fixed twice, there are already plenty of open bugs for key focus, please pick another one or if you really can't find one you like (that is still open) file a new one. I'm trying to resummarize based on bryner's comments and his fix. Resolving Fixed per Comments From Brian Ryner 2001-06-18 00:37.
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago → 18 years ago
Resolution: --- → FIXED
Summary: keys don't always scroll the page. → open link in a new window. mozarea focus_in, no call to nsWindow::SetFocus => null sFocusWindow
Comment 79•18 years ago
|
||
Verify Fixed per Comments From sairuh (se) 2001-06-19 15:34.
Status: RESOLVED → VERIFIED
Updated•18 years ago
|
Whiteboard: se-radar
You need to log in
before you can comment on or make changes to this bug.
Description
•