188225 - Windowless plugins can't determine own location due to bad WM_WINDOWPOSCHANGED design

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[Deneb Meketa]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030108
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030108

Mozilla calls NPP_HandleEvent(WM_WINDOWPOSCHANGED) to alert a windowless plugin
to a change in its location relative to the browser's client area, generally due
to a scroll or resize. The position data is passed in an odd and unfortunate
format: Mozilla provides the intersection rectangle between the plugin and the
client area. Much preferable would be the virtual rectangle of the plugin, with
negative coordinates in the case where the origin is scrolled out of view.

This design actually makes it impossible for windowless plugins to determine
their own origin coordinates (and thus correctly locate mouse events, which are
supplied in browser-relative terms) in the situation where the origin is
scrolled offscreen and the plugin is larger than the browser window. This
situation is not very common for windowless plugins; thus the reduced priority
on this bug.

Here is a breakdown of the cases windowless plugins must handle given the
current design. This list enumerates the y cases; the x cases are analogous.

1. y > 0. Origin is in view. Just use y as passed.

2. y = 0 and intersection height < browser window height. Origin is out of view,
but bottom of plugin is in view. Calculate origin as difference of intersection
height and plugin height.

3. y = 0 and intersection height = browser window height. Plugin is taller than
browser window, and origin is at top of browser window or above it. In this case
there is not enough information to determine where the origin is. Mouse events
will go to the wrong place.

I don't know the right way to fix this. Ideally, a fix should (a) immediately
solve the problem for all existing plugins where the problem happens; (b) not
cause any new problems for existing plugins. That may or may not be possible.
Speaking for the Flash Player (for which I am a developer), I can say that both
goals would be achieved by simply altering the rectangle that Mozilla passes in
WM_WINDOWPOSCHANGED, specifying the virtual rectangle of the plugin rather than
the intersection rectangle, and allowing x and y coordinates to be negative. But
I only know that would work because I know how our code is written. Other
plugins might have worked around this problem in different ways, and the change
I proposed here might in fact break those plugins in worse ways. An alternative
solution would be to introduce a new event; this would achieve goal (b) but not
goal (a).


Reproducible: Always

Steps to Reproduce:
1. Install Flash plugin version 6.0.65.0 or later (macromedia.com/go/getflashplayer)
2. Open file FlashWindowlessTextExtended.html from attachment.
3. Resize browser window to be very short vertically.
4. Scroll down until beginning of Flash text is offscreen above top of browser
window, and end of Flash text is offscreen below bottom of browser window.
5. Click and drag inside Flash text.

Actual Results:  
Text selection inside Flash text does not appear where mouse drag occurred.

Expected Results:  
Text selection inside Flash text should appear where mouse drag occurred.

Comment 1

[Deneb Meketa]

Attachment: Test case for reproducing bug

Comment 2

[Peter Grandmaison]

I would believe the easiet way to solve this is to re-visit NPP_SetWindow() for 
windowless plugins. For windowed plugins, the coordinate system is relative to the top 
left of the client rect. For a windowless plugin, this would also make a lot of sense (as it 
helps with mouse targetting et al), but instead, we are given coordinates based on some 
offscreen image (which is perhaps useful to mozilla, but it means plugins need to have 
extra work for this case) ... it would have been simple for you to translate the coordinate 
system of the DC before invoking a plugin to draw (etc), so that it's coordinates are the 
same as if it was a windowed plugin. This would remove the need for 
WM_WINDOWPOSCHANGED.

Comment 3

[Doron Rosenberg (IBM)]

this is affecting rich media.

Peter: any idea how hard this would be to fix?

Comment 4

[Arun Ranganathan]

I'm nominating this nsbeta1. It is a painful problem that Buffy ought to address.

Comment 5

[Karl Tomlinson (:karlt)]

This should be fixed by Bug 271442?

Comment 6

[Benjamin Smedberg]

We radically changed this for OOPP painting, and I believe all the events are now correct.