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

UNCONFIRMED
Unassigned

Status

()

P5
normal
UNCONFIRMED
12 years ago
2 months ago

People

(Reporter: danswer, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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
(Reporter)

Comment 1

12 years ago
Created attachment 222022 [details]
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).
Generally, speaking editor operations (moving the caret, clipboard operations, etc) from a web page _are_ a security violation.  Hence the current behavior.
(Reporter)

Comment 3

12 years ago
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.
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.
Assignee: events → nobody
QA Contact: ian → events
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.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.