scripts in the document get access to input events before browser

RESOLVED FIXED in seamonkey2.38


3 years ago
3 years ago


(Reporter: lvm, Assigned:


SeaMonkey 2.33 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1
Build ID: 20150321194901

Steps to reproduce:

press / to start 'find as you type' if auto find is not enabled 
type 'bus'

Actual results:

seamonkey finds the first two characters but as soon as 's' is pressed the search field at the top of the screen gets focused, find as you type is interrupted and any additional characters will be typed into the search field on the page instead of find as you type string. Any 's' in the input string breaks find as you type.

Expected results:

find as you type should've continued uninterrupted regardless of what characters are typed

Comment 1

3 years ago
Confirmed, but...

It seems it's the webpage that is causing the action.
You don't even need 'bu'.
Simply typing an 's' cause the Search box to gain focus.

If you block JavaScript for, then 's' acts as an 's', & not a shortcut key to Search.

Google Chrome reacts the same.

Comment 2

3 years ago
"Using keyboard shortcuts"
Last Resolved: 3 years ago
Resolution: --- → INVALID

Comment 3

3 years ago
If find as you type is active it obviously should process keyboard events before javascript, plugins or anything else in the document, ditto menu accelerators, hotkeys, etc - the page should not be able to interfere with browser functionality and should get input events only after they've been processed and sanitized by the browser core, so it is still a bug and a much more serious one than I first thought. Even security implicatiions are possible - a keylogger in the page.

I am changing the descrption accordingly and reopening the bug.
Component: Find In Page → General
Resolution: INVALID → ---
Summary: github breaks find as you type → scripts in the document get access to input events before browser

Comment 4

3 years ago
The problem here is that there are keypress events (with nice char codes) and keydown events (which only have key codes). So we listen out for keypress events, but the page is listening out for keydown events, which means it gets them first.

Comment 5

3 years ago
Created attachment 8603839 [details] [diff] [review]
Proposed patch

I added a capturing keydown event listener to stop the propagation of keydown events to content while we're finding. I also capture keyup events for good measure, and stop the propagation of keypress events too. (I don't bother with the initial / or ' since that's a bubbling event in the system group anyway.)
Assignee: nobody → neil
Ever confirmed: true
Attachment #8603839 - Flags: review?(philip.chee)


3 years ago
Attachment #8603839 - Flags: review?(philip.chee) → review+

Comment 6

3 years ago
Pushed comm-central changeset 2b19b447dd93.
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.38
You need to log in before you can comment on or make changes to this bug.