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

Status: VERIFIED FIXED

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

Description

[Rob Yampolsky]

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

[Asa Dotzler [:asa]]

Rob Yampolsky, what build did you test?

Comment 2

[Doron Rosenberg (IBM)]

worksforme 2000102604 win98 mozilla trunk

Comment 3

[Eugene Savitsky]

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

Comment 4

[Jeffrey Baker]

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.

Comment 5

[R.K.Aa.]

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

Comment 6

[R.K.Aa.]

Modifying summary to reflect that all scroll-keys are on occation affected by
this bug. (both arrows and page up/down)

Comment 7

[Eugene Savitsky]

It would be very bad for me if I didn't had a wheel mouse... Marking as dogfood-.

Comment 8

[Frank de Lange]

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

[Viswanath Ramachandran]

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy

Comment 10

[Greg Miller]

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

[Chris McAfee]

we need to chase this down, nsbeta1

Comment 12

[Chris McAfee]

p1

Comment 13

[R.K.Aa.]

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

Comment 14

[R.K.Aa.]

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

Comment 15

[Chris Siebenmann]

 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

[Oliver Klee]

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

Comment 17

[Oliver Klee]

Changing platform to ALL as duplicate bug 69314 is on the Mac.

Comment 18

[Aleksander Adamowski]

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

[Jeffrey Baker]

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

[Greg Miller]

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

[Stephan Niemz]

Could this bug be related to the mostfreq bug 54936?
(Dismissing a dialog confuses focus)

Comment 22

[sairuh (rarely reading bugmail)]

adding nsCatFood --i take it for granted that this should work. and i think many
other users would too.

Comment 23

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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

Comment 24

[Paul Chen]

nav triage team:

Reassigning to pchen and setting target milestone to mozilla0.9.1

Comment 25

[sairuh (rarely reading bugmail)]

to pchen, this time. :)

Comment 26

[Keyser Sose]

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

Comment 27

[Keyser Sose]

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

Comment 28

[Samir Gehani]

Attachment: Fix for sidebar focus issue (press F9 to close sidebar leaves content area unfocused)

Comment 29

[Samir Gehani]

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

[Anthony DeRobertis]

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

[Matthew Cline]

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

[Asa Dotzler [:asa]]

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

Comment 33

[Viswanath Ramachandran]

this bug has lots of votes we shd try hard to fix it. 

Comment 34

[Viswanath Ramachandran]

nav triage: moving this to mozilla0.9.2. 

Comment 35

[R.K.Aa.]

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

Comment 36

[Aaron Leventhal]

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

[Aaron Leventhal]

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

Comment 38

[sairuh (rarely reading bugmail)]

aaronl, that's for win32-only, right?

Comment 39

[Aaron Lehmann]

Yikes no... I only use the Unix build.

Comment 40

[sairuh (rarely reading bugmail)]

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

[Aaron Lehmann]

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

Sorry for butting into your conversation :-)

Comment 42

[Jacek Piskozub]

10 dups. Making mostfreq.

Comment 43

[Aaron Leventhal]

Bryner taking keyboard inactive/ keydead bugs

Comment 44

[Brian Ryner (not reading)]

84501 covers the case of switching to another app and back, on win32.

Comment 45

[Brian Ryner (not reading)]

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

[Jeffrey Baker]

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

Comment 47

[Brian Ryner (not reading)]

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.

Comment 48

[Brian Ryner (not reading)]

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?

Comment 49

[Brian Ryner (not reading)]

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.

Comment 50

[Brian Ryner (not reading)]

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.

Comment 51

[Brian Ryner (not reading)]

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).

Comment 52

[Brian Ryner (not reading)]

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.

Comment 53

[Brian Ryner (not reading)]

Attachment: patch to fix focus controller

Comment 54

[Brian Ryner (not reading)]

Attachment: patch with improved comments

Comment 55

[saari (gone)]

So bryner, does it look we're suppressing the wrong command dispatcher because
we get the wrong global object? That would be bad...

Comment 56

[Brian Ryner (not reading)]

Attachment: patch #2

Comment 57

[saari (gone)]

Looks ducky! r=saari

Comment 58

[Brian Ryner (not reading)]

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).

Comment 59

[Brian Ryner (not reading)]

Attachment: patch #3

Comment 60

[David Hyatt]

A nervous sr=hyatt

Comment 61

[Brian Ryner (not reading)]

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

[tor]

a=tor for trunk checkin

Comment 63

[Brian Ryner (not reading)]

Checked in the patch.  Since all of the cases mentioned in this bug seem to be
working now, marking this bug FIXED.

Comment 64

[Chris Lyon]

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

Comment 65

[sairuh (rarely reading bugmail)]

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

[sairuh (rarely reading bugmail)]

another test on linux [almost forgot]: scrolling works after selecting an item
from the Bookmarks menu [main menu and toolbar menu].

Comment 67

[sairuh (rarely reading bugmail)]

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

[sairuh (rarely reading bugmail)]

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

[sairuh (rarely reading bugmail)]

s/ctrl+w/cmd+w in previous comment. :)

Comment 70

[sairuh (rarely reading bugmail)]

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...]

Comment 71

[sairuh (rarely reading bugmail)]

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

Comment 72

[Anthony DeRobertis]

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.

Comment 73

[Anthony DeRobertis]

I just checked 2001070508; same problem as w/ 0.9.2 (plus some others, but
that's expected)

Comment 74

[sairuh (rarely reading bugmail)]

anthony, could you pls open a new bug for what you're seeing? thx a lot!

Comment 75

[Jacek Piskozub]

Verifying, as nothing actually happened since the bug was verified/fixed for the
first time (Anthony's bug is a separate issue).

Comment 76

[Jesse Ruderman]

Anthony: it sounds like you're running into bug 76621, "sidebar elements should
not grab focus from other parts of window".

Comment 77

[Waldemar Horwat]

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.

Comment 78

[timeless]

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.

Comment 79

[timeless]

Verify Fixed per Comments From sairuh (se) 2001-06-19 15:34.