294351 - Plugins capture all events - even events that they are not interested in.

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Jey Davis]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804

Components (XPCOM?) steal events when the mouse pointer is over them. Under X
they should be passing these events to their container (or the container should
decide whether the components should receive the event(s)).
One example is that if there is an Flash ad or a Java applet the scroll wheel
ceases to work.
This is probably a security issue as well. If a component captures all activity
it should be possible to record key strokes that are mistakenly captured.
The component should require a click event before capturing the scroll event or
keystrokes.


Reproducible: Always

Steps to Reproduce:
1. Open page with Flash
2. Mouse Over
3. Use scoll wheel

Actual Results:  
All events are captured by component

Expected Results:  
The page should have scrolled.

This could be a security problem.
If the component captures all events unexepectedly someone can reap credit card
numbers and passwords.

Comment 1

[Daniel Veditz [:dveditz]]

It would only be a security issue if a plugin captures events intended for
another window (or tab). Whether a page includes a keystroke-capturing plugin,
captures keystrokes using regular web page script features, or simply captures
the data after you've entered it into the form and submitted to the server, the
end result is that data you intended for that window got to the entity
responsible for that window's contents. Clearing security flag

I assume you mean "plugins" rather than components since you mention Flash, and
XPCOM components are not normally part of a web page. Reassigning so the right
folks can evaluate the event passing issue.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that this bug is a major pain with acrobat, since it prevents a lot of
windowmanager shortcuts from working if the mouse pointer happens to be over an
acrobat plugin.

Comment 3

[chris hofmann]

sounds like this should be sg:low or not security sensitive and   pain:high

Comment 4

[chris hofmann]

sg:nse unless we can come up with a case like dveditz mentioned in comment 1

Comment 5

[Benjamin Smedberg]

There's another bug specifically about keyboard shortcuts, but with windowed plugins dying I'm not going to track this any more.