Keyboard events created by bookmarklets are not considered trusted.

RESOLVED WONTFIX

Status

()

Firefox
Untriaged
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: Wesha, Unassigned)

Tracking

12 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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, where untrusted events in edit controls were disabled (see Bug 698949)

Since bookmarklets can only be manually created the user, I believe they should be considered trusted.
(Reporter)

Updated

6 years ago
See Also: → bug 749185
(Reporter)

Updated

6 years ago
Summary: Keyboard events from bookmarklets are considered untrusted. → Keyboard events created by bookmarklets are not considered trusted.
Yes, it's actually an untrusted event because you ignore a lot of process of trusted key events, e.g., targeting focused element.

I don't know if bookmarklet is running on chrome or content. If it's running on chrome, you can use nsIDOMWindowUtils.sendKeyEvent() for generating trusted key events.

Comment 2

6 years ago
Bookmarklets run in the context of a web page, with the privileges of the web page.  It wouldn't be safe to mix in higher privileges while still running in the context of the web page, because a site could modify "String.prototype.charCodeAt" or create a getter/setter pair for "window.s", changing the behavior of your bookmarklet or even running its own code while the bookmarklet is running.

(I suppose we could move bookmarklets to a "wrapper" model like Greasemoneky, but that would break page-specific bookmarklets that do want to interact with page JS.)

You could explore a mixed-privilege setup such as Greasemonkey or a Firefox extension, but I'd recommend using "e.value += s;" followed by calling the page's onchange handler yourself.
Blocks: 698949
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 3

6 years ago
Calling onchange handler is not always sufficient. For instance, my barcode scanner uses TAB as the final delimiter of the barcode, and in the browser, obviously, TAB moves to the next input field. Are you suggesting I should replicate all the complexities of the TAB handling (including analyzing tabindex fields) in my bookmarklet? I need onkeypress rather than onchange.

Comment 4

6 years ago
Interesting twist.  We don't want to expose "normal" tab behavior to web pages, because the "normal" tab order includes the address bar and items in third-party iframes.  But it might be sensible to have a window.advanceFocus() or window.nextElementInTabOrder that stays within the document.

This seems to be a somewhat common thing for web developers to want to do, so please consider suggesting it to the WhatWG :)

http://stackoverflow.com/questions/7208161/focus-next-element-in-tab-index
You need to log in before you can comment on or make changes to this bug.