If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

open link in a new window. mozarea focus_in, no call to nsWindow::SetFocus => null sFocusWindow

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
Keyboard: Navigation
P1
major
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: Rob Yampolsky, Assigned: Brian Ryner (not reading))

Tracking

(Blocks: 1 bug, {access})

Trunk
mozilla0.9.2
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: se-radar)

Attachments

(5 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
Rob Yampolsky, what build did you test?

Comment 2

17 years ago
worksforme 2000102604 win98 mozilla trunk

Comment 3

17 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

17 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

17 years ago
OS: Windows 98 → All

Comment 5

17 years ago
*** Bug 60062 has been marked as a duplicate of this bug. ***

Comment 6

17 years ago
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

17 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

17 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
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy

Comment 10

17 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 11

17 years ago
we need to chase this down, nsbeta1
Keywords: nsbeta1

Comment 12

17 years ago
p1
Assignee: vishy → mcafee
Priority: P3 → P1
Target Milestone: --- → mozilla0.9

Comment 13

17 years ago
*** Bug 67920 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
reporter in bug 67920 mentions another site: http://linuxtoday.com/

Comment 15

17 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

17 years ago
*** Bug 69314 has been marked as a duplicate of this bug. ***

Comment 17

17 years ago
Changing platform to ALL as duplicate bug 69314 is on the Mac.
Hardware: PC → All

Comment 18

17 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

17 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

17 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

17 years ago
Could this bug be related to the mostfreq bug 54936?
(Dismissing a dialog confuses focus)
Blocks: 70812

Updated

17 years ago
Keywords: nsdogfood-

Updated

17 years ago
Keywords: nsdogfood
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

17 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
to pchen, this time. :)
Assignee: mcafee → pchen

Comment 26

17 years ago
*** Bug 69812 has been marked as a duplicate of this bug. ***

Comment 27

17 years ago
*** Bug 70441 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Keywords: nsCatFood → nsCatFood+

Comment 28

17 years ago
Created attachment 32819 [details] [diff] [review]
Fix for sidebar focus issue (press F9 to close sidebar leaves content area unfocused)

Comment 29

17 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

17 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

17 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

17 years ago
*** Bug 78752 has been marked as a duplicate of this bug. ***
this bug has lots of votes we shd try hard to fix it. 
nav triage: moving this to mozilla0.9.2. 
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 35

17 years ago
*** Bug 81337 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Blocks: 81552

Comment 36

17 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

17 years ago
*** Bug 71493 has been marked as a duplicate of this bug. ***
aaronl, that's for win32-only, right?

Comment 39

17 years ago
Yikes no... I only use the Unix build.
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

17 years ago
Perhaps you're confusing me with Aaron Leventhal (or I'm confusing myself with
him!)

Sorry for butting into your conversation :-)

Comment 42

17 years ago
10 dups. Making mostfreq.
Keywords: mostfreq

Updated

17 years ago
Blocks: 83552

Updated

17 years ago
No longer blocks: 83552

Updated

17 years ago
Blocks: 83552
No longer blocks: 83552
Depends on: 83552

Comment 43

17 years ago
Bryner taking keyboard inactive/ keydead bugs
Assignee: pchen → bryner

Updated

17 years ago
No longer depends on: 83552

Updated

17 years ago
Blocks: 83552
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 44

17 years ago
84501 covers the case of switching to another app and back, on win32.
Depends on: 84501
(Assignee)

Comment 45

17 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

17 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

17 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

17 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

17 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

17 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

17 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

17 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

17 years ago
Created attachment 37775 [details] [diff] [review]
patch to fix focus controller
(Assignee)

Comment 54

17 years ago
Created attachment 37806 [details] [diff] [review]
patch with improved comments

Comment 55

17 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

17 years ago
Created attachment 38346 [details] [diff] [review]
patch #2

Comment 57

17 years ago
Looks ducky! r=saari
(Assignee)

Comment 58

17 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

17 years ago
Created attachment 38587 [details] [diff] [review]
patch #3

Comment 60

17 years ago
A nervous sr=hyatt
(Assignee)

Comment 61

17 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

17 years ago
a=tor for trunk checkin
(Assignee)

Comment 63

17 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: 17 years ago
Resolution: --- → FIXED

Comment 64

17 years ago
*** Bug 80340 has been marked as a duplicate of this bug. ***
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.
another test on linux [almost forgot]: scrolling works after selecting an item
from the Bookmarks menu [main menu and toolbar menu].
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.
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.
s/ctrl+w/cmd+w in previous comment. :)
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
*** Bug 81973 has been marked as a duplicate of this bug. ***

Comment 72

16 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

16 years ago
I just checked 2001070508; same problem as w/ 0.9.2 (plus some others, but
that's expected)
anthony, could you pls open a new bug for what you're seeing? thx a lot!
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED

Comment 75

16 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

16 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

16 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

16 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: 16 years ago16 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

16 years ago
Verify Fixed per Comments From sairuh (se) 2001-06-19 15:34.
Status: RESOLVED → VERIFIED
Whiteboard: se-radar
You need to log in before you can comment on or make changes to this bug.