Closed Bug 58250 Opened 20 years ago Closed 19 years ago

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

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: ryampols, Assigned: bryner)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: se-radar)

Attachments

(5 files)

Fix for sidebar focus issue (press F9 to close sidebar leaves content area unfocused)
854 bytes, patch
Details | Diff | Splinter Review
patch to fix focus controller
2.29 KB, patch
Details | Diff | Splinter Review
patch with improved comments
2.29 KB, patch
Details | Diff | Splinter Review
patch #2
5.51 KB, patch
Details | Diff | Splinter Review
patch #3
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.
Rob Yampolsky, what build did you test?
worksforme 2000102604 win98 mozilla trunk
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
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
OS: Windows 98 → All
*** Bug 60062 has been marked as a duplicate of this bug. ***
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.
It would be very bad for me if I didn't had a wheel mouse... Marking as dogfood-.
Keywords: dogfood
Whiteboard: [dogfood-]
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
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.
we need to chase this down, nsbeta1
Keywords: nsbeta1
p1
Assignee: vishy → mcafee
Priority: P3 → P1
Target Milestone: --- → mozilla0.9
*** Bug 67920 has been marked as a duplicate of this bug. ***
reporter in bug 67920 mentions another site: http://linuxtoday.com/

 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.

*** Bug 69314 has been marked as a duplicate of this bug. ***
Changing platform to ALL as duplicate bug 69314 is on the Mac.
Hardware: PC → All
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!
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.
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.
Could this bug be related to the mostfreq bug 54936?
(Dismissing a dialog confuses focus)
Keywords: nsdogfood-
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. ***
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
*** Bug 69812 has been marked as a duplicate of this bug. ***
*** Bug 70441 has been marked as a duplicate of this bug. ***
Keywords: nsCatFood → nsCatFood+
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).
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
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.
*** 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
*** Bug 81337 has been marked as a duplicate of this bug. ***
Blocks: 81552
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.
*** Bug 71493 has been marked as a duplicate of this bug. ***
aaronl, that's for win32-only, right?
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... :)
Perhaps you're confusing me with Aaron Leventhal (or I'm confusing myself with
him!)

Sorry for butting into your conversation :-)
10 dups. Making mostfreq.
Keywords: mostfreq
Blocks: focusnav
No longer blocks: focusnav
Blocks: focusnav
No longer blocks: focusnav
Bryner taking keyboard inactive/ keydead bugs
Assignee: pchen → bryner
No longer depends on: focusnav
Blocks: focusnav
Status: NEW → ASSIGNED
84501 covers the case of switching to another app and back, on win32.
Depends on: 84501
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.

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

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

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.

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

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.
So bryner, does it look we're suppressing the wrong command dispatcher because
we get the wrong global object? That would be bad...
Attached patch patch #2 — — Splinter Review 
Looks ducky! r=saari
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).
Attached patch patch #3 — — Splinter Review 
A nervous sr=hyatt

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.
a=tor for trunk checkin

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
Closed: 19 years ago
Resolution: --- → FIXED
*** 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. ***
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 → ---
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
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
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
Anthony: it sounds like you're running into bug 76621, "sidebar elements should
not grab focus from other parts of window".
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 → ---
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
Closed: 19 years ago → 19 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
Verify Fixed per Comments From sairuh (se) 2001-06-19 15:34.
Status: RESOLVED → VERIFIED
Whiteboard: se-radar
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.