Closed
Bug 749185
Opened 12 years ago
Closed 12 years ago
untrusted key events are refused by editors in firefox 12
Categories
(Firefox :: Untriaged, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: ozzob1, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0 Build ID: 20120420145725 Steps to reproduce: With firefox 12 on windows, this code doesn't work : <script> function f() { var i = document.getElementById("i"); i.focus(); var evt = document.createEvent("KeyboardEvent"); evt.initKeyEvent("keypress", true, true, null, false, false, false, false, 0, 32); i.dispatchEvent(evt); } </script> <body onload="f();"> <input id="i" type="text"/> </body> But it works on firefox 11 Actual results: Space character never appear in text field.
Comment 1•12 years ago
|
||
See Bug 698949 and https://developer.mozilla.org/en/Using_the_Editor_from_XUL#Editor_event_handling
Blocks: 698949
Comment 2•12 years ago
|
||
The change is intentional. It doesn't work on other browsers too. And there is no spec for untrusted events vs. editor. If some spec would define the behavior, we would change again.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Comment 5•12 years ago
|
||
That is NOT correct. The MDN documentation suggest that it should work. Looking initKeyEvent on MDN In Webkit there is a way to send keyboard events to a keyboard area. You are very cryptic and very unhelpful. You should let others answer this.
Comment 6•12 years ago
|
||
(In reply to marc fawzi from comment #5) > That is NOT correct. > > The MDN documentation suggest that it should work. Looking initKeyEvent on > MDN > > In Webkit there is a way to send keyboard events to a keyboard area. > > You are very cryptic and very unhelpful. You should let others answer this.
Summary: initKeyEvent is not working anymore in firefox 12 → untrusted key events are refused by editors in firefox 12
Comment 7•12 years ago
|
||
Please note that initKeyEvent() still works. Editors just refuse the untrused key events for both security and unclear in current spec.
Comment 11•12 years ago
|
||
Please specify diagrammatically trusted key events.(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #7) > Please note that initKeyEvent() still works. Editors just refuse the > untrused key events for both security and unclear in current spec.
Comment 12•12 years ago
|
||
OK, how do I make my event trusted then? My issue: I have a bookmarklet that feeds off my UPC scanner, which used to allow me use the scanner to scan barcodes into my web-based inventory control system: javascript:(function(){e = doc.activeElement; if(e.type == 'text') { var http_request = new XMLHttpRequest(); http_request.open("GET", "http://server.my.domain/scanner.php", false); http_request.send(); var results = http_request.responseText; if (results) { for(s in results) { var evt = document.createEvent("KeyboardEvent"); var keycode = results.charCodeAt(s); evt.initKeyEvent("keypress", true, true, window, 0, 0, 0, 0, keycode, keycode); e.dispatchEvent(evt); } } }})() It worked like a charm until FF12. Now, I'm not saying undoing the fix is a good idea, but at least there should be some sort of control to make certain things (like bookmarklets) trusted?
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Comment 13•12 years ago
|
||
I think I'll create a new bug rather...
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → INVALID
Comment 14•12 years ago
|
||
Why can't you just write if (results) e.value += results; ?
Comment 15•12 years ago
|
||
Re: #14: Because doing "+=" will not cause onKeyDown methods associated with some of the input fields to fire.
Comment 16•12 years ago
|
||
(In reply to Wesha from comment #15) > Re: #14: Because doing "+=" will not cause onKeyDown methods associated with > some of the input fields to fire. Yes, but you can modify the <input>'s value by the way mentioned in comment 14 and you can dispatch the untrused event for kicking some keydown event handlers, right?
Comment 17•12 years ago
|
||
Hello Masayuki, The solution that you raise is correct for all inputs except one (this has happened to me). I have an ace-editor which has an ajax code behind (coloring the code according to you write a char) as an example the ace-editor of github. In this case element.value not work, so I used the following code: for (var i=0; i<str.length; i++) { var key = document.createEvent("KeyboardEvent"); key.initKeyEvent("keypress", true, true, null, false, false, false, false, 0, str.charCodeAt(i)); target.dispatchEvent(key); } But now with firefox12 it not work, ¿which would be the solution?
Comment 18•12 years ago
|
||
I guess that the hidden textarea is handling actual text input, so, you should modify it by script normally. Please don't ask anymore. There are some APIs to get selection range and modify editor content for each type of editor. You should use them for editing its content. And if you need to kick key event handlers, use the untrusted event before or after that.
Comment 19•12 years ago
|
||
That's an idiot response "Don't ask again" Great customer service and awareness of developer frustrations. Firstly, the W3C has a standard for sending keyboard events, and Webkit implements sending TextEvent which is harmless from a security point of view will do just fine. Moving to Chrome. Forget about Firehox. re-writing the value of the textarea on each key press is maximally retarded as it will produce a flash with each rewrite and does not work for real-time visual feedback. Going with Canvas is better but you have to emulate all fonts and all the hundreds of thousands of unicode glyphs if you wanna support unicode characters... As I said, W3C has a standard for sending keyboard events and Webkit supports TextEvent Firefox is just being a bitch, Google paid them $100M a year to ruin Firefox. We know the story. Stole the brightest developers and left **** ones behind who just don't get it.... Your answer is to modify the text area value for real time editing apps? Are you f***ing kidding me? Why not implement TextEvent or the W3C API for sending keyboard input? Tell me that you actually understand the problem and I'll back off but till then stop being so damn simple minded and try to think about the scenarios for which the API was invented in the first place, and for which Webkit supports the TextEvent. Doh.
Comment 20•12 years ago
|
||
TextEvent has been dropped from W3C spec (D3E) because it doesn't make sense. Instead, beforeTextInput is defined in new draft of editing API spec but it's not stable and if we need to implement it, we need a lot of work in our editor. So far, any W3C spec doesn't define untrusted event's default action behavior of all events. E.g., Gecko does nothing in a lot of places for default action of untrusted events. E.g., untrusted mouse scroll event has never caused scroll, moving history and zooming in/out the contents. And untrusted key events has never caused autocomplete and any shortcut keys. Additionally, other browsers including WebKit don't support to input text into editors via untrusted key events. Therefore, I'm very surprised at some developers using untrusted key events for that purpose since they don't work on other browsers. How do you support IE and Opera on such application?
You need to log in
before you can comment on or make changes to this bug.
Description
•