337975 - Non printing synthesized key events are not handled (e.g. arrow keys in textarea)

Status: RESOLVED INVALID

(Core :: DOM: Editor, defect, P5)

Description

[Csaba Gabor]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Now that bug 303713 is fixed, one can synthesize keystroke events to deliver characters to DOM elements.  This includes sending a space to a button, thus activating its onclick handler or causing a form submission.

However, synthesizing non printing characters such as arrow keys (where charCode is 0 in the keypress event) has no effect.

Reproducible: Always

Steps to Reproduce:
In the accompanying attachment, pressing the buttons marked simple will cause focus to go to the textarea, followed by a synthesized keypress event directed at the textarea.  Pressing the button marked complete will include synthesis of the keydown and keyup events, too.
Actual Results:  
Only the printing character, 'c', is inserted into the textarea.  If a left arrow synthesis is attempted, the caret is not moved.

Expected Results:  
When non printing characters are synthesized, the corresponding default behaviour should result unless it is a security violation.  For example, ctrl+v should not have any effect.  Also, ctrl+number probably shouldn't activate the corresponding tab (unless it's a related window).

Csaba Gabor from Vienna

Comment 1

[Csaba Gabor]

Attachment: Synthesizing non printing keys (arrows) has no effect

This attachment shows that the default action is not carried out when non printing keys are synthesized.  Press the buttons on the attachment to synthesize a keypress event and see the result in the textarea (specifically, check for the caret position).

Comment 2

[Boris Zbarsky [:bzbarsky]]

Generally, speaking editor operations (moving the caret, clipboard operations, etc) from a web page _are_ a security violation.  Hence the current behavior.

Comment 3

[Csaba Gabor]

I don't follow how these are "generally speaking" security violations.  What I mean is that, is it not the case that there are distinct classes of violations:

1.  Clipboard operations (specifically paste) are a violation
      because copying the clipboard is a way to transmit
      private user information back to the server.
2.  ctrl+tab, ctrl+pageUp/pageDown, ctrl+number, and friends are
      possible window access violations because they switch focus
      to another tab.
3.  ctrl+n/ctrl+t (or Alt+f, n / Alt+f, t) are also potentially
      window access violations.
4.  ctrl+-/+ alters (font size) settings sans user authorization.
5.  Alt+char,char2 pulls down the menu and can select a menu item.
      Brief summary: Menu operations are privileged.

How are the following classes of non printing characters generated via synthesized events security violations?
A.  caret movement operations
      (home/end/pageUp/pageDown/arrow keys and
      ctrl+shifted versions) via events (as opposed
      to via textarea.setSelectionRange) 
B.  character insertion (enter)
C.  deletion (backspace, delete)
D.  focus change (tab, shift+tab)
E.  characters without default actions (escape, and
      untrapped for ctrl/shift/alt character combinations)

A-C can be accomplished via javascript, altering either textarea.value or using textarea.setSelectionRange().  Even if some of the above are security violations, should it not be the responsibility of the relevant default action to handle it (by not taking any action, for example) as opposed to not synthesizing the event?

Use case: textarea has several caret positioning bugs (for example, pasting a selection that has a newline at the end into a fresh textarea) that can be compensated for by synthesizing an arrow key.  Not a very strong case because it is really those bugs that should be fixed.  And yet...

Use case 2: Synthesizing a HOME key is the only way I know of to determine what column of the textarea the caret is at.  And synthesizing a Shift+left arrow and Shift+up arrow is the only way to set a reverse selection that I know of.

PS.  Boris, I sign threads (usually only once) for indexing purposes, and it continues to prove very useful.  However, if this induces prejudice against my reports, I'll forbear.

Comment 4

[Martijn Wargers (dead)]

Synthesizing arrow key events could also be used for the autocomplete fill by automatically selecting something from the autocomplete popup and then synthesizing the enter key. This way, a malicious script could steal information from the autocomplete history.

It's not useful to sign threads, because every comment contains already your name/e-mail address.

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Editor does not accept untrusted events for security reason, and the testcase does not work on Chrome too. So, we don't need to support it. Instead, web apps can modify selection range with selectionStart etc of <input> and <textarea>, and if you need support of execCommand of insertText on the elements, it'll be fixed in bug 1220696.