Last Comment Bug 749185 - untrusted key events are refused by editors in firefox 12
: untrusted key events are refused by editors in firefox 12
Status: RESOLVED INVALID
:
Product: Firefox
Classification: Client Software
Component: Untriaged (show other bugs)
: 12 Branch
: x86 Windows XP
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 749140 751801 751810 752932 (view as bug list)
Depends on:
Blocks: 698949
  Show dependency treegraph
 
Reported: 2012-04-26 07:25 PDT by ozzob1
Modified: 2012-05-14 17:22 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description ozzob1 2012-04-26 07:25:40 PDT
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 2 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2012-04-26 08:21:58 PDT
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.
Comment 3 Alice0775 White 2012-04-26 09:46:57 PDT
*** Bug 749140 has been marked as a duplicate of this bug. ***
Comment 4 Alice0775 White 2012-05-03 21:17:09 PDT
*** Bug 751801 has been marked as a duplicate of this bug. ***
Comment 5 marc fawzi 2012-05-03 21:45:21 PDT
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 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2012-05-03 22:06:13 PDT
(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.
Comment 7 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2012-05-03 22:07:51 PDT
Please note that initKeyEvent() still works. Editors just refuse the untrused key events for both security and unclear in current spec.
Comment 8 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2012-05-03 22:16:02 PDT
*** Bug 751801 has been marked as a duplicate of this bug. ***
Comment 9 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2012-05-03 23:08:46 PDT
*** Bug 751810 has been marked as a duplicate of this bug. ***
Comment 10 Alice0775 White 2012-05-08 08:51:09 PDT
*** Bug 752932 has been marked as a duplicate of this bug. ***
Comment 11 Reza Owliaei 2012-05-08 09:10:52 PDT
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 Wesha 2012-05-11 21:09:07 PDT
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?
Comment 13 Wesha 2012-05-11 21:14:17 PDT
I think I'll create a new bug rather...
Comment 14 neil@parkwaycc.co.uk 2012-05-12 02:05:47 PDT
Why can't you just write if (results) e.value += results; ?
Comment 15 Wesha 2012-05-12 02:09:43 PDT
Re: #14: Because doing "+=" will not cause onKeyDown methods associated with some of the input fields to fire.
Comment 16 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2012-05-12 05:28:42 PDT
(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 josunedesosakerejeta 2012-05-14 03:01:55 PDT
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 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2012-05-14 03:41:16 PDT
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 marc fawzi 2012-05-14 10:52:03 PDT
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 Masayuki Nakano [:masayuki] (Mozilla Japan) (Offline: 9/19, 9/22-9/25, 9/28)) 2012-05-14 17:22:19 PDT
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?

Note You need to log in before you can comment on or make changes to this bug.