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)
Tracking
()
VERIFIED
FIXED
People
(Reporter: chado_moz, Assigned: enndeakin)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
2.76 KB,
text/html
|
Details | |
1.97 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
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.
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.
Assignee | ||
Updated•15 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•15 years ago
|
||
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 :-(.
Assignee | ||
Comment 7•15 years ago
|
||
(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.
Assignee | ||
Comment 8•15 years ago
|
||
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.
Description
•