Closed Bug 418740 Opened 16 years ago Closed 16 years ago

NPAPI Plugins receive incorrect mouse input when overlapping an iFrame in windowless mode

Categories

(Core Graveyard :: Plug-ins, defect, P2)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Windows Vista
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: alanliu, Assigned: roc)

References

Details

(Keywords: fixed1.9.1)

Attachments

(2 files)

The HTML file that reproduces this problem. It's the duplicate of the HTML code in the bug description.
872 bytes, text/html
Details
fix
2.85 KB, patch
jst
: review+
jst
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2; .NET CLR 3.5.21022)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

When an NPAPI plugin (such as Microsoft Silverlight) is overlapping an IFrame, the mouse coordinates received to the plugin are incorrect.

For areas of the plugin not over the iframe, mouse input is relative to browser client area.  But for areas of the plugin over the iframe, it receives input based on the location of the iframe.

IFrame seems to be implemented with an hwnd, and input is relative to that hwnd.

Reproducible: Always

Steps to Reproduce:
1. Create an HTML doc with the contents in the Additional Information.
2. Move mouse over Silverlight plugin area.
3. Notice the mouse interaction.
Actual Results:  
The characters "mm" will be shown whenever the mouse is moved over the blue square.  Notice how nothing is produced when moved over the IFrame.  This is because the coordinates are off.  The plugin is confirmed to receive the mousemove messages, but just that the coordinates are off, and are relative to the iFrame.

Expected Results:  
The coordinates passed to the plugin are relative to the browser client area, even when over the IFrame.

<HTML>
<SCRIPT id="xaml1" type="text/xaml">

<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" x:Name="Root"
Width="350" Height="350" Background="Cornflowerblue"
MouseMove="$MM"
>


</Canvas>
</SCRIPT>
<SCRIPT>
function $MM(sender, args)
{
    Debug("mm ");
}

function Debug(msg)
{
    document.getElementById("Status").innerHTML += msg;
}
</SCRIPT>
<BODY>
<IFRAME SRC="http://www.msn.com" style="position:absolute;left:200;top:200;width:500;height:400;"></IFRAME>
<DIV style="position:absolute;left:300;top:100;width:600;height:300;" >
<EMBED TYPE="application/x-silverlight" Source="#xaml1" Windowless="true"> </EMBED>
</DIV>

<SPAN id="Status" style="fontsize:8;position:absolute;left:50;top:600;width:400;height:500;overflow:scroll"></SPAN>

</BODY>
</HTML>
Status: UNCONFIRMED → NEW
Component: General → Plug-ins
Ever confirmed: true
Product: Firefox → Core
Yeah, we just forward the message but not the target HWND ... NPAPI has always been like that :-(.

I suppose we could translate the coordinates to make them relative to the window we used for SetWindow. That would probably fix this, but would it break anything? Does Flash have the same bug or do they work around it somehow?
QA Contact: general → plugins
I'm a product manager for AOL Mail -- I can't comment on whether this issue exists in Flash or not, but I did want to comment on the importance of this fix to our business.  Without this we'll be unable to deliver out-of-banner rich media ads, which are critical for monetization of our traffic.  Is this something that can be addressed in an future Firefox release.
Understood, but I'm not sure why Flash isn't affected (or why a bug hasn't been filed on it, if it is affected) given that Flash gets used a lot this way already. Without understanding that, I'm reluctant to change anything this late in the release cycle for fear of breaking Flash which is used an awful lot more...
Hi, we've now confirmed that the same issue also exists in flash.  If you email me at seth.halvaksz@corp.aol.com I can send you a example that demonstrates the issue in flash.  This may not have been reported for Flash yet as there are more cases where this issue exists in Silverlight.  Silverlight controls in our mail app extend over an iframe in several places, not just ads.  Can this be considered for an upcoming Firefox release.
At this point, not for Firefox 3, sorry. Less than 24 hours to code freeze for RC1.
Can you please confirm when this fix will be picked up (with general timing) so we can align with our roadmap. I understand there will be a dot release every 6-8 weeks after Firefox 3 ships.
Roc, is this something you could work on?
Yeah I guess.
Assignee: nobody → roc
Flags: wanted1.9.0.x+
Hi, is there an estimated release / release date for this fix?
I'll try to get it done for 1.9.0.2.
You may want to have a look at this: #308529
Has this been scheduled for 1.9.0.2, if so can you provide general release timing
Flags: blocking1.9.1?
Attached patch fix — — Splinter Review 
This fixes it.
Attachment #342964 - Flags: superreview?
Attachment #342964 - Flags: review?
Attachment #342964 - Flags: superreview?(jst)
Attachment #342964 - Flags: superreview?
Attachment #342964 - Flags: review?(jst)
Attachment #342964 - Flags: review?
Attachment #342964 - Flags: superreview?(jst)
Attachment #342964 - Flags: superreview+
Attachment #342964 - Flags: review?(jst)
Attachment #342964 - Flags: review+
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Pushed 2ccfa9744edb
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment on attachment 342964 [details] [diff] [review]
fix

>+        // Make event coordinates relative to our enclosing widget,
>+        // not the widget they were received on.
>+        // See use of nsPluginEvent in widget/src/windows/nsWindow.cpp
>+        // for why this assert should be safe
>+        NS_ASSERTION(anEvent.message == NS_MOUSE_BUTTON_DOWN ||
>+                     anEvent.message == NS_MOUSE_BUTTON_UP ||
>+                     anEvent.message == NS_MOUSE_DOUBLECLICK ||
>+                     anEvent.message == NS_MOUSE_MOVE,
>+                     "Incorrect event type for coordinate translation");
Except it isn't, because for instance a mouse move can be translated into a synthetic mouse enter by nsEventStateManager::NotifyMouseOver
Depends on: 468421
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: