Closed Bug 502383 Opened 15 years ago Closed 15 years ago

No key operation works when a existing window get focus via js focus()

Categories

(Core :: General, defect)

All
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: chado_moz, Assigned: enndeakin)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

User-Agent:       Opera/9.64 (Windows NT 5.1; U; ja) Presto/2.1.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090704 Minefield/3.6a1pre  buildID: 20090704044508

When not-most-front window get focus via JS function focus(), 
key operations no longer work.  Dead key-ops are document/application 
level (e.g. keypress/down/up events, keyboard short-cuts, 
menu operations with Alt key).  System level key-ops (e.g. Alt + Tab, 
Ctrl + Shift + Esc, etc.) are keep working.

After it happens, the situation carries on until the window lose 
focus once and get focus again via some way other than JS focus().


Reproducible: Always

Steps to Reproduce:
0.  prepare:
  0-1. Enable JavaScript.
  0-2. Allow scripts to: "Raise or lower windows" 
       in Advanced JavaScript Settings.
  0-3. Allow "pop-up windows" at least for this testcase.
1. (Re)Load testcase.
2. Click the link named "TEST."  This opens small empty window
   named "test_win", causes moving focus to test_win.  
   After a second, "this.focus()" is fired to get focus back to 
   root window.
3. Check if the right-arrow key (horizontal scroll) works 
   or not.  Also, any of app-level keyboard short-cuts or menu 
   operations with Alt + some keys can be tested.

Actual Results:  
no key operation works.


Expected Results:  
any allowed key operations work.


Little more extra testcase, using keypress, is available at URL.

Also, you can see this (probably the same) problem on Error Console.
Steps:
0. No extra setting needed when you use default settings.
1. Open Error Console via Tools menu or Ctrl + Shift + J.
2. Focus to browser window (click or Alt + Tab) without closing 
   Error Console.
3. Give focus to Error Console via Tools menu or Ctrl + Shift + J.
4. Check if any key-ops work or not (Alt + [EWMA] or Ctrl + W.)

repro/non-repro builds I tried:
Minefield/3.6a1pre  buildID: 20090610042525  not reproduced
Minefield/3.6a1pre  buildID: 20090611044033  reproduced
                (snip)
Minefield/3.6a1pre  buildID: 20090704044508  reproduced

I'm seeing this on WinXP SP3 but not seeing on Linux 
(Ubuntu 9.04 on VM Guest).  No Mac around of me.
Attached file testcase
Keywords: regression
Version: unspecified → Trunk
Confirmed on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090704 Minefield/3.6a1pre (.NET CLR 3.5.30729)

WFM on Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

Definitely a regression.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: x86 → All
Windows only it seems.
Status: NEW → ASSIGNED
This was caused because Windows was, after we'd already focused the child browser window, trying to refocus the toplevel chrome window again.

Builds are at https://build.mozilla.org/tryserver-builds/neil@mozilla.com-winfocusfix/
Assignee: nobody → enndeakin
Attachment #387008 - Flags: superreview?(roc)
Attachment #387008 - Flags: review?(roc)
I tried the build of comment #4, looking good about attached testcase.
The only thing I'm worrying about is: 
With the testcase of URL, focus() through keypress event to 
already-existing-window looks not working.  for example: 
Pressing "1", then "0" expecting root window focused, but not.
another one (after closing child):
Pressing "1", "2", then "1" expecting test_win_1 window focused, nor.

Should be filed another bug after checked-in of this ?

Thank you.
Attachment #387008 - Flags: superreview?(roc)
Attachment #387008 - Flags: superreview+
Attachment #387008 - Flags: review?(roc)
Attachment #387008 - Flags: review+
Comment on attachment 387008 [details] [diff] [review]
focus the child widget on windows instead

Can you write a test for this? This is going to need changes in my compositor build :-(.
(In reply to comment #6)
> (From update of attachment 387008 [details] [diff] [review])
> Can you write a test for this?

A test would require knowledge of which window/widget Windows thought was focused.
Blocks: 178324
http://hg.mozilla.org/mozilla-central/rev/2b03c49c957f
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Works fine on trunk-nightly.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090714 Minefield/3.6a1pre  buildID: 20090714054201

Just note: comment #5 was stood on wrong setting.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.