Closed Bug 9701 Opened 25 years ago Closed 25 years ago

nsWebShell Key events not working until focus set in window (TAB, PgDn, ALT+, CTRL+)

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: hyatt)

References

Details

(Whiteboard: [PDT+])

Attachments

(1 file)

We have debugged this and this describes the problrm
(deleted), text/plain
Details 
On Mac, in a new browser window, no menu items dispatch events until you click
somewhere in the window, because no widget has focus. I added a warning in the
code to printf when this happens, but it needs fixing.

This does not appear to be a problem on Windows (perhaps because the OS gives
focus to a Window automatically?).
*** Bug 9526 has been marked as a duplicate of this bug. ***
*** Bug 9711 has been marked as a duplicate of this bug. ***
*** Bug 9739 has been marked as a duplicate of this bug. ***
*** Bug 9711 has been marked as a duplicate of this bug. ***
*** Bug 9372 has been marked as a duplicate of this bug. ***
Summary: Need to set focus in new windows before menus are operable. → [PP]Need to set focus in new windows before menus are operable.
Putting on [PP] radar
*** Bug 10347 has been marked as a duplicate of this bug. ***
Target Milestone: M9
Does this happen on Linux.  joki, can we get this one fixed?
*** Bug 8974 has been marked as a duplicate of this bug. ***
*** Bug 8974 has been marked as a duplicate of this bug. ***
Blocks: 9938
In response to leger, (fyi the world) no it doesn't happen on Linux, this is Mac only.
*** Bug 9938 has been marked as a duplicate of this bug. ***
*** Bug 9531 has been marked as a duplicate of this bug. ***
joki at w3c
Summary: [PP]Need to set focus in new windows before menus are operable. → [PP][DOGFOOD] Need to set focus in new windows before menus are operable.
We need this fixed for dogfood.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
It's no longer Mac-only. Using the 1999082008 build under NT, try this:

- Launch apprunner
- Press Alt-F

Result: The computer beeps.

Expected result: The File menu should drop down.

If you click in the window first to set focus, it does work correctly. Changing
platform and OS to All and All.
Blocks: 11547
*** Bug 13308 has been marked as a duplicate of this bug. ***
*** Bug 11547 has been marked as a duplicate of this bug. ***
Summary: [PP][DOGFOOD] Need to set focus in new windows before menus are operable. → [PP][DOGFOOD][BLOCKER] Need to set focus in new windows before menus are operable.
This is really starting to piss me off. Do we have a fix? Can this be handled by
someone else?
*** Bug 14554 has been marked as a duplicate of this bug. ***
Severity: normal → blocker
adding myself to cc list. making severity blocker.
As of yet no, we do not have a fix.  The basic issue is that after the main
document loads, or at least after the xul portion loads, we need to call the
focus method on its DOM window.  After talking with hyatt I tried adding this
at the end of onEndDocumentLoad.  Obviously it doesn't work.  Someone who knows
the behavior of nsWebShellWindow better than I needs to find the right place to
do this.
*** Bug 14492 has been marked as a duplicate of this bug. ***
Summary: [PP][DOGFOOD][BLOCKER] Need to set focus in new windows before menus are operable. → [PP][DOGFOOD][BLOCKER]nsWebShell Need to set focus in new windows before menus are operable.
Target Milestone: M10 → M11
m11
*** Bug 7027 has been marked as a duplicate of this bug. ***
Is this also the reason for the select-all focus bug?
Do Edit->Select All, observe that you don't see anything selected (because the
window lost focus).
Click in the window, now you do see everything selected (you shouldn't, the
click should have passed to the selection code and collapsed the selection to a
single point).
*** Bug 15629 has been marked as a duplicate of this bug. ***
Blocks: 12658
Adding a dependency from the editor dogfood tracker bug.
Summary: [PP][DOGFOOD][BLOCKER]nsWebShell Need to set focus in new windows before menus are operable. → [PP][BLOCKER]nsWebShell Need to set focus in new windows before menus are operable.
[DOGFOOD] designation removed, this is still a [BLOCKER] and tracked by
pork-jockeys.
Priority: P3 → P1
Assignee: joki → hyatt
saari and i are on this.
Putting on [PDT]+ radar.
Whiteboard: [PDT+]
Assignee: hyatt → saari
reassign to saari to type for hyatt.
*** Bug 13887 has been marked as a duplicate of this bug. ***
removing [BLOCKER] from summary, severity is enough.
Summary: [PP][BLOCKER]nsWebShell Need to set focus in new windows before menus are operable. → [PP]nsWebShell Need to set focus in new windows before menus are operable.
*** Bug 16327 has been marked as a duplicate of this bug. ***
QA Contact: phillip → claudius
Summary: [PP]nsWebShell Need to set focus in new windows before menus are operable. → [DOGFOOD][PP]nsWebShell Need to set focus in new windows before menus are operable.
This will *not* be fixed by my initial focus changes.
Status: NEW → ASSIGNED
Target Milestone: M11 → M12
... and given that we have lived with this before, I'm going to push to M12. I
don't have a quick fix in mind.
Why is thhis labeled a blocker?  What work is it blocking?
I don't see this problem any more on Mac. Maybe some other change fixed it.
Severity: blocker → normal
lowering severity to normal per pinkerton, no developers are blocked.
Whiteboard: [PDT+] → [PDT+] 11/26
*** Bug 18026 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT+] 11/26 → [PDT+] 12/15
Assignee: saari → pinkerton
Status: ASSIGNED → NEW
reassigning to pinkerton
Status: NEW → ASSIGNED
Target Milestone: M12 → M13
this is so M13.
No longer blocks: 12658
removing dependency with 12658
Assignee: pinkerton → travis
Status: ASSIGNED → NEW
I hate to do this, and will accept this bug and all its shame if kicked back to
me, but I think Travis has a much better chance of figuring out what to do here,
especially since he's in the middle of the webShell redesign.

reassigning to travis.
Blocks: 20870
Whiteboard: [PDT+] 12/15 → 12/15 completion
Removing PDT+ status because it's obvious we're not gonna hold up dogfood for
this.
Whiteboard: 12/15 completion → [PDT-]12/15 completion
Putting on PDT- radar.  spoke with don, enough of this is working at this time.
although I'm sure there are other manifestations, currently the best way to see
this is to open a new browser window and type ^N and you'll see that nothing
happens until you click in the content area of the window. All 3 paltforms with
the 1999121508 builds
Is this why quitting with key combo (cmd+Q) doesn't work after closing window
(File| Close or cmd+W)? Quitting with File menu leads to crash (bug 22088).
Summary: [DOGFOOD][PP]nsWebShell Need to set focus in new windows before menus are operable. → nsWebShell Need to set focus in new windows before menus are operable.
Whiteboard: [PDT-]12/15 completion
Target Milestone: M13 → M14
Remove "DOGFOOD" and "PP" in summary.  Move to M14.
*** Bug 22722 has been marked as a duplicate of this bug. ***
*** Bug 22723 has been marked as a duplicate of this bug. ***
Summary: nsWebShell Need to set focus in new windows before menus are operable. → nsWebShell Key events not working until focus set in window (TAB, PgDn, ALT+, CTRL+)
Reading the Comments From joki@netscape.com  09/21/99 22:48, the attachment,
the Comments From claudius@netscape.com  1999-12-15 20:35, and especially noting
that bug 7027 "page up/page down requires a focus click to start working" has
been made a DUP of this bug, it seems that this is a general problem with focus
for all keyboard events, not just with keys that should activate menus.

The continued presence of this bug is causing a very large number of DUPs of
a variety of bugs, including bug 8014, and even more INVALID bugs, as
inexperienced reporters note problems with keypresses not working, especially
TAB, PgDn, PgUp, Up and Dn, as well as any ALT+ and CTRL+, when they try to
use they browser as they are accustomed to using 4.x. Many bugs marked INVALID
would probably have been better made DUPs of this bug, but this bug was not
easily findable when searching for earlier bugs on need to click in window
for scrolling or tabbing problems.

Changing Summary from "nsWebShell Need to set focus in new windows before menus
are operable." to "nsWebShell Key events not working until focus set in window
(TAB, PgDn, ALT+, CTRL+)" to add keywords for DUP-searchers.

Glad to see that this is P1 ... I'd hate to see the number of uninformative
bug reports due to this one problem post beta if this doesn't get fixed by then.
I can launch composer w/o giving any kind of focus in the browser, other than
clicking on the edge of the Browser window to get the menus to show up...

is this bug fixed???
...don't think so. the current manifestation is that some key events aren't getting
through until the browser has focus. So if you were to try to launch Composer w/o using the
mouse (just shortcuts and accelerators) you be stuck.
Blocks: uaag
*** Bug 24498 has been marked as a duplicate of this bug. ***
*** Bug 21246 has been marked as a duplicate of this bug. ***
*** Bug 24239 has been marked as a duplicate of this bug. ***
*** Bug 23301 has been marked as a duplicate of this bug. ***
*** Bug 24153 has been marked as a duplicate of this bug. ***
*** Bug 25278 has been marked as a duplicate of this bug. ***
*** Bug 25278 has been marked as a duplicate of this bug. ***
I'm currently experiencing something similar to this bug.  On Windows Nt 4.0
(sp4) when I click on a link to load a new page, the page loses focus.  I have
to click on the page before I can use the scroll wheel (or the pgup/pgdown/arrow
keys) to scroll through the document.

*** Bug 20450 has been marked as a duplicate of this bug. ***
*** Bug 25724 has been marked as a duplicate of this bug. ***
*** Bug 25724 has been marked as a duplicate of this bug. ***
holy duparoni - if dups are any indication of bug importance then 
this one should be on the beta1 radar
Keywords: beta1
PDT+
Whiteboard: [PDT+]
*** Bug 22766 has been marked as a duplicate of this bug. ***
I'm not inexperienced with any of this stuff.  I have M13 on WinNT4/workstation.
Here's what I am seeing.

- PgUp and PgDn are extremely flaky.  They work about a tenth of the time,
and clicking in the viewport makes no difference.  At the same time, the
scrollbar and the mouse scroll-wheel work fine.

- Alt-F and the other menu shortcuts work fine, but Alt-Left and Alt-Right
don't work.  Ctrl-R doesn't work.  I can click all over the place, select
text, whatever.  It makes no difference.

This doesn't appear to be the same as what you're describing above.

--
jorend@yahoo.com

Am I correct that the times they work correctly are:
 * the first page you load (after clicking in viewport?)
 * when you type in the URL bar, and then click in the viewport?
(see bug 24498).
*** Bug 27066 has been marked as a duplicate of this bug. ***
I have a plan for this.  If travis wants, I can take this bug.

Hyatt wants it.
Assignee: travis → hyatt
Status: NEW → ASSIGNED
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 27550 has been marked as a duplicate of this bug. ***
If a text edit widget has focus, PgUp and PgDn still don't work.  Different bug?

*** Bug 27503 has been marked as a duplicate of this bug. ***
hooray! VERIFIED fixed on all platforms with 2000021509 builds
Status: RESOLVED → VERIFIED
Not_working_for_me_with_Linux/i386_Feb.18_build!
If_I_enter_a_URL_at_the_top_and_hit_enter...the_page_loads..
but_the_focus_is_still_in_the_URL_field_until_I_click_it_away
with_the_mouse...hence...PAGE_UP..&..PAGE_DOWN_keys_don't_work
until_main_window_is_clicked.

Seems_to_me_hitting_enter_for_a_URL_should_move_focus
to_the_main_window...agreed?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
That doesn't fall under this bug.  In fact 4.x does not move focus into the 
content area.  I do agree with you, but strictly speaking, you're asking for a 
change in functionality...

File a new bug on this against me, and cc german@netscape.com.  Let's keep this 
one closed.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Was already verified.
Status: RESOLVED → VERIFIED
*** Bug 28614 has been marked as a duplicate of this bug. ***
I believe saari already has some other bugs on the fact that text fields grab
page up/down events even though they can't do anything with them, so they don't
bubble out to the outer container (like they would have in 4.x).
niles, if you do file another bug (like hyatt) mentioned could you note it here so those following the issue(like me) can stay on 
top of it. fwiw, I did notice the behavior you speak of but 4.x did it exactly the same way so I knew that was a different issue.

Space in textarea causes scroll (REOPENED, saari)
http://bugzilla.mozilla.org/show_bug.cgi?id=26882

Up and Down arrow in select field causes window to scroll (NEW, karnaze)
http://bugzilla.mozilla.org/show_bug.cgi?id=28030

page up/down when focus is in text field should scroll containing page
(ASSIGNED, saari)
http://bugzilla.mozilla.org/show_bug.cgi?id=27771

Niles' bug: Focus should shift to main window after CR/NL (ASSIGNED, hyatt)
http://bugzilla.mozilla.org/show_bug.cgi?id=28580

*** Bug 30864 has been marked as a duplicate of this bug. ***
*** Bug 31076 has been marked as a duplicate of this bug. ***
*** Bug 32349 has been marked as a duplicate of this bug. ***
*** Bug 34796 has been marked as a duplicate of this bug. ***
No longer blocks: 20870
Keywords: mostfreq
*** Bug 49436 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: