Closed Bug 819899 Opened 12 years ago Closed 2 years ago

The shortcut Windows+V doesn't work

Categories

(Core :: Widget: Win32, defect, P4)

Product:
Core
Component:
Widget: Win32
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: oren.hurvitz, Unassigned, Mentored)

References

Details

(Keywords: regression, Whiteboard: [lang=c++][bug in PlainText][tpi:+])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 Build ID: 20121128204232 Steps to reproduce: I use PureText ( http://www.stevemiller.net/puretext/ ) to copy and paste text without formatting. It uses the shortcut "Windows+V" to paste text. I copy text anywhere on my PC; click inside any textbox in Firefox (including the address bar); and press "Windows+V". Actual results: Nothing. Expected results: The text in the clipboard should have been pasted into the text box.
I'm having the same problem using Win7 x64 and Firefox 17.0.1. Puretext still works fine in Chrome.
I think it's because enablePrivilege has been removed from Firefox 17 due to security issues, see bug 546848. Many copy/paste tools are broken now. Some alternatives: https://developer.mozilla.org/en-US/docs/SpecialPowers https://github.com/brettz9/asyouwish/ http://beckelman.net/demo/copy-to-clipboard-with-zeroclipboard-flash-10-and-jquery/ http://www.w3.org/TR/clipboard-apis/ (see bug 407983) Anyway I think this bug will be closed as INVALID. bholley, what do you think?
Whiteboard: invalid?
(In reply to Loic from comment #3) > I think it's because enablePrivilege has been removed from Firefox 17 due to > security issues, see bug 546848. Many copy/paste tools are broken now. > > Some alternatives: > https://developer.mozilla.org/en-US/docs/SpecialPowers > https://github.com/brettz9/asyouwish/ > http://beckelman.net/demo/copy-to-clipboard-with-zeroclipboard-flash-10-and- > jquery/ > http://www.w3.org/TR/clipboard-apis/ (see bug 407983) > > Anyway I think this bug will be closed as INVALID. > bholley, what do you think? It's impossible to say without debugging the addon. But a priori I don't see why enablePrivilege would be involved here. enablePrivilege is a way for web pages to escalate their privileges. If this is an addon, it _already_ has all those privileges, so I don't see why it would be using enablePrivilege. Actually, it looks like PureText isn't even a firefox addon at all. So enablePrivilege definitely wouldn't be involved.
PureText is definitely not a FF add-on. It's a stand-alone, memory resident application that uses only 680 kB and is very helpful if you have to copy and paste large amounts of formatted text with much dirty codes completely frre of codes in another application (for instance a webbased CMS). Anyway - Mozilla Thunderbird now has a the same 'new' engine as FF and the PureText shortcut keys aren't working as well since last update to 17.0. It's a little annoying, because I use PureText many many times a day...
Keywords: regressionwindow-wanted
Whiteboard: invalid?
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/6d5150ee06ce Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120719032015 Bad: http://hg.mozilla.org/mozilla-central/rev/e1dcf7c892d1 Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120719052815 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6d5150ee06ce&tochange=e1dcf7c892d1 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/6b1ef3183423 Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120718181115 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/205aaea8796d Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120718183023 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6b1ef3183423&tochange=205aaea8796d Suspected: Bug 751749
Blocks: 751749
Keywords: regressionwindow-wanted → regression
Status: UNCONFIRMED → NEW
Ever confirmed: true
It's odd. How that works in Windows message level? How to insert the text? And if you don't use Windows key, does it work?
Component: Untriaged → Event Handling
Product: Firefox → Core
(In reply to Masatoshi Kimura [:emk] from comment #8) > Is the key events dropped by this change? > https://hg.mozilla.org/mozilla-central/diff/372c0dbbfb5b/widget/windows/ > nsWindow.cpp Ah, yeah, I understand. However, looks like the cause is old bug. I think that we should not consume the following messages *before* dispatching keypress events. In other words, we should remove the following messages only when the keypress event is prevented default. How do you think?
Component: Event Handling → Widget: Win32
Version: 17 Branch → Trunk
Mentor: jmathies, tabraldes, netzen
Whiteboard: [good first bug][lang=c++]
Hi, I am kind of new to open source. I wish to try my hand at fixing bugs. I'd be grateful if anyone can help me get started.
(In reply to Manan Doshi from comment #10) > Hi, I am kind of new to open source. I wish to try my hand at fixing bugs. > I'd be grateful if anyone can help me get started. A good place to start would be to get the source code repo cloned locally and the browser built - https://developer.mozilla.org/en-US/docs/Simple_Firefox_build/Windows_Firefox_build If you run into problems, you will probably want to get an irc session going so you can talk to developers. The #developer and #windev channels are good places to start. https://wiki.mozilla.org/IRC You can find me (jimm) in both.
Can I start working on this bug?. I already have the build setup
Anyone is welcome to work on bugs marked "good first bug," though it's polite to avoid working on something that someone else is already working on. Typically, for "good first bugs," the bug doesn't get assigned to a contributor until the contributor has posted a reasonable patch (where "reasonable" can mean different things, but probably at least has code changes that start to address the bug)
I am willing to work on this bug. I am really new to opensource and firefox. Could you please tell me where i should start. I have already setup the nightly build.
I guess that this is not a simple bug for now due to e10s. When content has focus, keyboard events are dispatched to child process asynchronously. Therefore, we cannot check if key events actually consumed by web apps. Is this correct, smaug? If so, we have only two choices: 1. If a key event is dispatched to a child process, we shouldn't mark it as consumed. And widget shouldn't consume native key event even if it could cause double action. 2. If a key event is dispatched to a child process, we should mark it as consumed. And widget should consume native key events always. I.e., we need to kill the compatibility with other key message related utilities.
Flags: needinfo?(bugs)
So do you think that i should drop this one and try another one.? I mean i don't really know if i should take it or not. This is my first bug so i kind of really consfused.
I think so. This has now complicated issues.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #15) > I guess that this is not a simple bug for now due to e10s. > > When content has focus, keyboard events are dispatched to child process > asynchronously. Therefore, we cannot check if key events actually consumed > by web apps. Is this correct, smaug? Right > If so, we have only two choices: > > 1. If a key event is dispatched to a child process, we shouldn't mark it as > consumed. And widget shouldn't consume native key event even if it could > cause double action. > 2. If a key event is dispatched to a child process, we should mark it as > consumed. And widget should consume native key events always. I.e., we need > to kill the compatibility with other key message related utilities. Could we somehow use mWantReplyFromContentProcess here? Though, it is not quite clear to me what this bug is about. How do other browsers deal with this case? (IIRC there is some issue still related to mWantReplyFromContentProcess handling, but that is a separate issue.)
Flags: needinfo?(bugs)
(In reply to Olli Pettay [:smaug] from comment #18) > (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #15) > > If so, we have only two choices: > > > > 1. If a key event is dispatched to a child process, we shouldn't mark it as > > consumed. And widget shouldn't consume native key event even if it could > > cause double action. > > 2. If a key event is dispatched to a child process, we should mark it as > > consumed. And widget should consume native key events always. I.e., we need > > to kill the compatibility with other key message related utilities. > > Could we somehow use mWantReplyFromContentProcess here? I'll check it, thanks. > Though, it is not quite clear to me what this bug is about. > How do other browsers deal with this case? The cause of this bug is that we don't send the key messages to default or next wndproc after we handle them. I was thinking that it occurs even if nobody consumes the keydown event. But as I researched it again now, it might be a bug of nsEditor... I'll debug this deeper today.
Hmm, I download the PureText and tested this. But I cannot reproduce both on Nightly and Firefox 33. Do you really still reproduce this bug?
Flags: needinfo?(oren.hurvitz)
I can still reproduce on Firefox 33.1.1 using Windows 7 (build 7601, service pack 1). I use PlainText instead of PureText though, but it uses the same keyboard shorcut (Win+V). Pressing Win+V in Firefox does nothing, while IE 10 and Chrome 38 happily paste.
(In reply to Mikael Falkvidd from comment #21) > I can still reproduce on Firefox 33.1.1 using Windows 7 (build 7601, service > pack 1). > I use PlainText instead of PureText though, but it uses the same keyboard > shorcut (Win+V). Could you tell me the URL of the official site of PlainText? (It's hard to search with Google...)
Flags: needinfo?(mozilla)
Sorry about that :) http://plaintext.codeplex.com/
Flags: needinfo?(mozilla)
(In reply to Mikael Falkvidd from comment #23) > Sorry about that :) > http://plaintext.codeplex.com/ Thanks! I can reproduce this bug with it.
The PlainText case looks different bug. It sends Ctrl + V at pressing Win + V. However, it doesn't generate a keyup message of Windows key. Therefore, it causes the V key event is fired with Ctrl *and* Win. This causes mismatching with our shortcut key handler. I think that even if we should fix the shortcut key handler, it's out of scope of this bug. Could you file another bug for PlainText issue (and cc me)?
Flags: needinfo?(mozilla)
Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1100862 I agree that it is out of scope for this bug, so I'll stay out of the discussion here. Sorry for messing things up.
Flags: needinfo?(mozilla)
removing [good first bug] as per comment 15 and comment 17
Whiteboard: [good first bug][lang=c++] → [lang=c++]
Priority: -- → P4
Whiteboard: [lang=c++] → [lang=c++][bug in PlainText][tpi:+]
Severity: normal → S3

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(oren.hurvitz)

Closing as RESOLVED WORKSFORME per comment 20.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.