Closed
Bug 337975
Opened 19 years ago
Closed 5 years ago
Non printing synthesized key events are not handled (e.g. arrow keys in textarea)
Categories
(Core :: DOM: Editor, defect, P5)
Tracking
()
RESOLVED
INVALID
People
(Reporter: danswer, Unassigned)
Details
Attachments
(1 file)
1.39 KB,
text/html
|
Details |
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•19 years ago
|
||
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•19 years ago
|
||
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•19 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.
Comment 4•19 years ago
|
||
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.
Updated•15 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Comment 5•6 years ago
|
||
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
Comment 6•5 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Component: DOM: Events → DOM: Editor
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•