Closed Bug 1100862 Opened 5 years ago Closed 5 years ago

Compatibility issue: The Win+V shortcut used by PlainText doesn't work in Firefox


(Core :: XBL, defect)

Windows 7
Not set





(Reporter: mozilla, Assigned: masayuki)


(Keywords: dev-doc-needed)


(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141113143407

Steps to reproduce:

1. Start Plain Text ( v 1.5
2. Start Firefox
3. Copy any text to the clipboard (ctrl+C)
4. In any text area (address bar, search box, html text/textarea field, etc), press Win+V

Actual results:

Nothing at all

Expected results:

The text on the clipboard should be pasted without HTML formatting.
Pasting using Win+V works in all other applications that I know of, including Windows WordPad, Chrome, IE 11.

Related issue:
PlainText emulates Ctrl + V when user presses Win + V (perhaps, it modifies the clipboard text before that). However, the generated 'V' key event has both Ctrl and Win (OS) modifiers. Therefore, perhaps, nsXBLPrototypeHandler fails to do the expected command.

As far as I tested on Windows, native applications ignore Win key status at handling shortcut keys. I think that we need to ignore OS modifier state in nsXBLPrototypeHandler on Windows even if "os" isn't specified with "any".

How do you think, Enn?
Ever confirmed: true
Flags: needinfo?(enndeakin)
Component: Untriaged → XBL
Product: Firefox → Core
Version: 33 Branch → Trunk
On gedit, Ctrl + Super + X doesn't work as Ctrl + X. So, I think that this is Windows only issue.
So does PlainText create its own ctrl+V event and expect that to cause paste?
(If so, wouldn't it be just relying on a blink bug where they allow web pages to do all sorts of things with untrusted events?)
My understanding of comment 1 was that PlainText generates Windows key events, not DOM key events.
Ah yeah, probably.
Yes. Probably it uses SendInput() API and that causes WM_KEYDOWN, WM_CHAR and WM_KEYUP. We will dispatch DOM key events for them. So, they *expect* Ctrl+v causes "Paste". (Although, it should use WM_PASTE, instead)
FYI: On Windows 8.1, Win+V doesn't cause WM_KEYDOWN and WM_CHAR. Therefore, PlainText doesn't work on it. You need to test it on Windows 7 or earlier.
It does not work for me when testing with

Same problem as before, nothing happens when pressing Win+V . Using Windows 7 pro version 6.1 build 7601, service pack 1
Sorry, my bad. The old FF was still running so starting the new build just gave me a new window of the old version.

Pasting with PlainText using Win+V now works in address bar, search field and html text fields.

Great work, thanks a lot!
Okay, let's take this approach.

Native applications on Windows don't honor Windows key state at least for Ctrl+foo or Alt+bar. So, when Win key (OS key) is pressed, we should ignore the Win key state if there is no shortcut key handler which exactly matches Win+foo+bar.

I.e., on Windows, modifiers attribute of XUL key element always include "os any" implicitly. However, if there is a shortcut key handler which exactly matches a key event including OS key state, we should prefer it.
Assignee: nobody → masayuki
Flags: needinfo?(enndeakin)
Attachment #8526823 - Flags: review?(enndeakin)
Comment on attachment 8526823 [details] [diff] [review]
Shortcut key handlers should ignore Windows-Logo key state if no shortcut keys match a key event and the key is pressed because native applications do so

>+#ifdef XP_WIN
>+  // Windows native applications ignore Windows-Logo key state at checking
>+  // shortcut keys even if the key is pressed.  Therefore, if there is no

'key state at checking' -> 'key state when checking'

>-  if (mKeyMask & cOSMask) {
>+  if ((mKeyMask & cOSMask) &&
>+      (!aIgnoreModifierState.mOSIfActive || !inputEvent->IsOS())) {
>     if (inputEvent->IsOS() != ((mKeyMask & cOS) != 0)) {
>       return false;

Why is the !inputEvent->IsOS() necessary here? The caller already checks if the key is pressed.

You should also just change the name mOSIfActive to mOS to mirror the mShift property.
Attachment #8526823 - Flags: review?(enndeakin) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in before you can comment on or make changes to this bug.