Open Bug 1337471 Opened 7 years ago Updated 2 years ago

Received keyup event from press system hotkey, it triggers the page action

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Version:
52 Branch
Platform:
x86
Windows 10
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: yfdyh000, Unassigned)

Details

(Keywords: parity-chrome, testcase) 

STR:
1. Open the attachment 8831980 [details] (from bug 1335347) for testcase, open the Web Console (F12), and focus to the tesecase page.
2. Use the Windows + Right arrow hotkey to switch virtual desktop in Windows 10.


Actual results:
The console shows:
keydown Control { target: <body>, key: "Control", charCode: 0, keyCode: 17 }
keydown Control { target: <body>, key: "OS", charCode: 0, keyCode: 91 }
keyup Control { target: <body>, key: "ArrowRight", charCode: 0, keyCode: 39 }
keyup Control { target: <body>, key: "OS", charCode: 0, keyCode: 91 }
keyup { target: <body>, key: "Control", charCode: 0, keyCode: 17 }

The page received the keyup Control { target: <body>, key: "ArrowRight", charCode: 0, keyCode: 39 }.


Expected results:
No page misoperation, for example, on http://www.33yq.com/read/13/13393/1437158.shtml (a novel reading site), the left arrow / right arrow will go to the previous page / next page.

Use the same STR in Google Chrome 56, only these:
KeyboardEvent {isTrusted: true, key: "Control", code: "ControlLeft", location: 1, ctrlKey: true…}
KeyboardEvent {isTrusted: true, key: "Meta", code: "MetaLeft", location: 1, ctrlKey: true…}
Corrected STR for issue reproduce:
2. Press and hold the Windows key, press the Right arrow and Left arrow keys to switch the desktop to next and return, release the Windows key, the Left arrow keyup event is triggered.
Has STR: --- → yes
Olli, is this an example of something we shouldn't let the page intercept or am I mis-reading it?
Flags: needinfo?(bugs)
no response...
(In reply to YF (Yang) from comment #0)
> STR:
> 1. Open the attachment 8831980 [details] (from bug 1335347) for testcase,
> open the Web Console (F12), and focus to the tesecase page.
> 2. Use the Windows + Right arrow hotkey to switch virtual desktop in Windows
> 10.
> 
> 
> Actual results:
> The console shows:
> keydown Control { target: <body>, key: "Control", charCode: 0, keyCode: 17 }
> keydown Control { target: <body>, key: "OS", charCode: 0, keyCode: 91 }
> keyup Control { target: <body>, key: "ArrowRight", charCode: 0, keyCode: 39 }
> keyup Control { target: <body>, key: "OS", charCode: 0, keyCode: 91 }
> keyup { target: <body>, key: "Control", charCode: 0, keyCode: 17 }
> 
> The page received the keyup Control { target: <body>, key: "ArrowRight",
> charCode: 0, keyCode: 39 }.
> 
> 
> Expected results:
> No page misoperation, for example, on
> http://www.33yq.com/read/13/13393/1437158.shtml (a novel reading site), the
> left arrow / right arrow will go to the previous page / next page.

FWIW, I played around with nightly 55.0a1 (2017-03-13) on win10. I could use arrow keys to navigate sections back and forth on this novel reading site without problems. I focused on a page, and then switched between virtual desktops by pressing Window+ctr+arrow keys. After I switched back, I stayed on the same page. 

That being said, I did see extra arrow key event fired on firefox.

> 
> Use the same STR in Google Chrome 56, only these:
> KeyboardEvent {isTrusted: true, key: "Control", code: "ControlLeft",
> location: 1, ctrlKey: true…}
> KeyboardEvent {isTrusted: true, key: "Meta", code: "MetaLeft", location: 1,
> ctrlKey: true…}
(In reply to Andrew Overholt [:overholt] from comment #2)
> Olli, is this an example of something we shouldn't let the page intercept or
> am I mis-reading it?

Unclear, since all this is unspec'ed - in which cases web page shouldn't get the key event.
(by default it should get all)
Flags: needinfo?(bugs) → needinfo?(masayuki)
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #4)
> FWIW, I played around with nightly 55.0a1 (2017-03-13) on win10. I could use
> arrow keys to navigate sections back and forth on this novel reading site
> without problems. I focused on a page, and then switched between virtual
> desktops by pressing Window+ctr+arrow keys. After I switched back, I stayed
> on the same page. 
> 
> That being said, I did see extra arrow key event fired on firefox.

Well, I cannot reproduce it in Nightly, but the issue may not has fixed.

>   function jumpPage() {
> 	var event = document.all ? window.event: arguments[0];
> 	if (event.keyCode == 37) document.location = preview_page;
> 	if (event.keyCode == 39) document.location = next_page;
> 	if (event.keyCode == 13) document.location = index_page;
>   }
>   document.onkeydown = jumpPage;

Unknown reason, "keyup Control { target: <body>, key: "ArrowRight", charCode: 0, keyCode: 39 }" may fired to this in Fx52 & Fx53beta.
When I press Win+Ctrl+ArrowRight, I see following messages in Spy++:

WM_KEYDOWN VK_LWIN
WM_KEYDOWN VK_CONTROL (may be repeated)

And after Win+Ctrl+ArrowLeft on the other virtual desktop:

WM_KEYUP VK_LEFT
WM_KEYUP VK_LWIN
WM_KEYUP VK_CONTROL

So, WM_KEYDOWN for VK_RIGHT/VK_LEFT must be consumed by OS before application.

Although, I don't know why Google Chrome nor Edge doesn't fire keyup events after focus is back to it. At least from the idea of UI Events, "keydown" and "keyup" events are fired when physical key state is changed. So, our behavior doesn't break any standards.

If we should discard keyup events which are not following keydown events, we can do it in TextEventDispatcher but it may be risky.
Flags: needinfo?(masayuki)
Priority: -- → P5
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-chrome]
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.