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)

Product:
Firefox
Component:
Untriaged
Version:
12 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
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.
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
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.
(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
Please note that initKeyEvent() still works. Editors just refuse the untrused key events for both security and unclear in current spec.
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.
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 → ---
I think I'll create a new bug rather...
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → INVALID
Why can't you just write if (results) e.value += results; ?
Re: #14: Because doing "+=" will not cause onKeyDown methods associated with some of the input fields to fire.
(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?
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?
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.
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.
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.