Closed
Bug 1100862
Opened 11 years ago
Closed 11 years ago
Compatibility issue: The Win+V shortcut used by PlainText doesn't work in Firefox
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
FIXED
mozilla37
People
(Reporter: mozilla, Assigned: masayuki)
Details
(Keywords: dev-doc-needed)
Attachments
(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 (http://plaintext.codeplex.com/) 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: https://bugzilla.mozilla.org/show_bug.cgi?id=819899#c25
Assignee | ||
Comment 1•11 years ago
|
||
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".
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/key#a-modifiers
How do you think, Enn?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(enndeakin)
Assignee | ||
Updated•11 years ago
|
Component: Untriaged → XBL
Product: Firefox → Core
Version: 33 Branch → Trunk
Assignee | ||
Comment 2•11 years ago
|
||
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?)
![]() |
||
Comment 4•11 years ago
|
||
My understanding of comment 1 was that PlainText generates Windows key events, not DOM key events.
Ah yeah, probably.
Assignee | ||
Comment 6•11 years ago
|
||
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)
Assignee | ||
Comment 7•11 years ago
|
||
Okay, this test build works for me.
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/masayuki@d-toybox.com-825eedbcee71/try-win32/
However, I need to modify or add test for this before requesting review.
https://hg.mozilla.org/try/rev/ba2e50eff625
Assignee | ||
Comment 8•11 years ago
|
||
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.
Reporter | ||
Comment 9•11 years ago
|
||
It does not work for me when testing with http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/masayuki@d-toybox.com-825eedbcee71/try-win32/firefox-36.0a1.en-US.win32.zip
Same problem as before, nothing happens when pressing Win+V . Using Windows 7 pro version 6.1 build 7601, service pack 1
Reporter | ||
Comment 10•11 years ago
|
||
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!
Assignee | ||
Comment 11•11 years ago
|
||
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
Status: NEW → ASSIGNED
Flags: needinfo?(enndeakin)
Attachment #8526823 -
Flags: review?(enndeakin)
Comment 12•11 years ago
|
||
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+
Assignee | ||
Comment 13•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Assignee | ||
Updated•11 years ago
|
Keywords: dev-doc-needed
You need to log in
before you can comment on or make changes to this bug.
Description
•