Closed Bug 558532 Opened 15 years ago Closed 15 years ago

[OOPP]The mouse coordinates of Silverlight(Windowless = true) are offset in OOPP enabled

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
1.9.2 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: alice0775, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4pre) Gecko/20100409 Namoroka/3.6.4pre ID:20100409042742
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4pre) Gecko/20100409 Namoroka/3.6.4pre ID:20100409042742

The mouse coordinates of Silverlight are offset on the latest Namoroka and Minefield with OOPP enabled.

The problem does not occur If you set dom.ipc.plugins.enabled.npctrl.dll to false  (OOPP disabled).

Reproducible: Always

Steps to Reproduce:
1. Start Namoroka with new profile
2. set general.useragent.extra.firefox to Firefox/3.6.3
3. restart Namoroka
3. Go http://gyao.yahoo.co.jp/player/00566/v08856/v0885600000000534947/ (It is a free movie site with the popularity in Japan)
4. Mouse hover/ click on video control

Actual Results:
 The mouse coordinates of Silverlight are offset.

Expected Results:
 The mouse coordinates of Silverlight shouuld not be offset.


This  also happens on Minefield with OOPP enabled.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100408 Minefield/3.7a5pre ID:20100409223307

This problem does not happens if you set set dom.ipc.plugins.enabled.npctrl.dll to false.
Blocks: OOPP
your example URL is GeoIP'ed (.jp only).
are Bug 558526 & Bug 558527 dupes of this?
I am sorry but i could not find the other good url sample.

I think thay are different bug.
Because,
Bug 558526 is for Firefox 3,5.x.
Bug 558527 is for the plugin inside iframe and did not related OOPP.

This comment #0 is for OOPP enabled bug.
Every time we have tried this it is related to setting the user agent to Firefox/* and really didn't have anything to do with OOPP.
(In reply to comment #3)
> Every time we have tried this it is related to setting the user agent to
> Firefox/* and really didn't have anything to do with OOPP.

NO
I set UA.to Firefox/3.6.3.
For the above site.
If OOPP disabled, no problem.
If OOPP enabled ,the issue happens.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
(In reply to comment #5)
> 
> *** This bug has been marked as a duplicate of bug 536429 ***

NO this is related OOPP.
Not UA problem (bug 536429).

I re - open.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to comment #6)
> (In reply to comment #5)
> > 
> > *** This bug has been marked as a duplicate of bug 536429 ***
> 
> NO this is related OOPP.
> Not UA problem (bug 536429).
> 
> I re - open.

bug 547353 maybe? Are you still able to reproduce this?
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > 
> > > *** This bug has been marked as a duplicate of bug 536429 ***
> > 
> > NO this is related OOPP.
> > Not UA problem (bug 536429).
> > 
> > I re - open.
> 
> bug 547353 maybe? Are you still able to reproduce this?

heh, posted 4-10. I guess the answer would be "yes".
Maybe Masayuki has some ideas. When I enter the site, instead of video, I get a link to another page. Not sure why.
(In reply to comment #7)(In reply to comment #3)
No. not related Bug 547353.

the bug in comment #0 is only happens in OOPP enabled.

and i found the followings.


The following html code is for object of the movie.

<object xmlns="http://www.w3.org/1999/xhtml" width="600" height="600" type="application/x-silverlight-2" data="data:application/x-silverlight-2," id="testplayer" hogehoge="1">
  <param value="http://i.yimg.jp/images/gyao/sl/PlayerGyaO.xap?v=5" name="source" />
  <param value="onSilverlightError" name="onerror" />
  <param value="#00FFFFFF" name="background" />
  <param value="2.0.31005.0" name="minRuntimeVersion" />
  <param value="true" name="autoUpgrade" />
  <param value="true" name="enableHtmlAccess" />
  <param value="true" name="AllowHtmlPopupwindow" />
  <param value="true" name="Windowless" />
  <param value="pluginLoaded" name="onLoad" />
  <param value="spaceID=1183051606, vid=00660:v07316:v0731600000000536669, enableIM=1, ts=1271037601" name="initParams" />
  <a style="text-decoration: none;" href="http://go.microsoft.com/fwlink/?LinkID=124807">
    <img style="border-style: none;" alt="Microsoft Silverlight を取得" src="http://go.microsoft.com/fwlink/?LinkId=108181" />
  </a>
  <param name="wmode" value="opaque" />
</object>

If I change <param value="true" name="Windowless" /> to <param value="false" name="Windowless" />, 
then the problem is solved even if set dom.ipc.plugins.enabled.npctrl.dll to true.

So, Handling of Windowless plugins may be wrong in OOPP.
Summary: [OOPP]The mouse coordinates of Silverlight are offset → [OOPP]The mouse coordinates of Silverlight(Windowless = true) are offset in OOPP enabled
OOps I misstake. 

s/In reply to comment #7)(In reply to comment #3)/In reply to comment #7)(In reply to comment #8)
Is this really our bug? If our windowless plug-in mouse handling is broken, this bug should be reproduced on other plug-ins in windowless mode.
(In reply to comment #12)
> this bug should be reproduced on other plug-ins in windowless mode.

1. the problem happens when  OOPP enabled.
2. the problem does not happens when OOPP disabled.

So i think that the problem *MUST* be OOPP's BUG.
(In reply to comment #13)
> (In reply to comment #12)
> > this bug should be reproduced on other plug-ins in windowless mode.
> 
> 1. the problem happens when  OOPP enabled.
> 2. the problem does not happens when OOPP disabled.
> 
> So i think that the problem *MUST* be OOPP's BUG.

What version of silverlight are you using Alice?
(In reply to comment #14)
> What version of silverlight are you using Alice?
I am using Silverlight Plug-In
    File: npctrl.dll
    Version: 3.0.50106.0
    3.0.50106.0
(In reply to comment #13)
> (In reply to comment #12)
> > this bug should be reproduced on other plug-ins in windowless mode.
> 
> 1. the problem happens when  OOPP enabled.
> 2. the problem does not happens when OOPP disabled.
> 
> So i think that the problem *MUST* be OOPP's BUG.

If you're right, other plug-ins, e.g., flash player should have same problem.

I guess that the process has no window in windowless mode but silverlight tries to do something with a window, so, it might be aborted by process separation.

Jim, can somebody contact to the developers of Silverlight?
Alice, any chance you could try out the newer silverlight 4 rc and see if it's in that as well?

http://www.silverlight.net/getstarted/silverlight-4/
(In reply to comment #16)
> (In reply to comment #13)
> > (In reply to comment #12)
> > > this bug should be reproduced on other plug-ins in windowless mode.
> > 
> > 1. the problem happens when  OOPP enabled.
> > 2. the problem does not happens when OOPP disabled.
> > 
> > So i think that the problem *MUST* be OOPP's BUG.
> 
> If you're right, other plug-ins, e.g., flash player should have same problem.
> 
> I guess that the process has no window in windowless mode but silverlight tries
> to do something with a window, so, it might be aborted by process separation.
> 
> Jim, can somebody contact to the developers of Silverlight?

We do do some funny mouse event translation for silverlight here -

http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginInstanceChild.cpp#1225

This fixed a bug where silverlight mouse coords were offset. I have yet to find a silverlight app that isn't working right with this however. So I'm not sure what's going on here and I can't get to the video to test.
(In reply to comment #17)
> Alice, any chance you could try out the newer silverlight 4 rc and see if it's
> in that as well?
> 
> http://www.silverlight.net/getstarted/silverlight-4/
I install  the folllowing version.
Silverlight Plug-In

    File: npctrl.dll
    Version: 4.0.50303.0
    4.0.50303.0

The issue is still there.
Can anyone view the movie?
This Silverlight(Windowless) has same problem with OOPP.

http://www.microsoft.com/showcase/ja/jp/details/7b917c16-111c-425e-be85-5069a6106f2f
(In reply to comment #20)
> Can anyone view the movie?
> This Silverlight(Windowless) has same problem with OOPP.
> 
> http://www.microsoft.com/showcase/ja/jp/details/7b917c16-111c-425e-be85-5069a6106f2f

Thanks Alice! Yes, I can, I get the following results in a nightly:

useragent           OOPP   offset?
----------------------------------
Minefield/3.7a5pre  Yes    No
Firefox/3.6.4       Yes    Yes
Minefield/3.7a5pre  No     No
Firefox/3.6.4       No     No

So Silverlight must be doing really funky here. I'll do some more investigating.
This page is also Silverlight(Windowless), and has problem.
http://www.nederland24.nl/
blocking1.9.2: --- → ?
Silverlight 3.0/Firefox 3.6.4 suffer from bug 536429. SL 3.0 is generally hosed because they have a quirk for a bug we fixed, and they don't plan on updated 3.0 to address. There's nothing we can do about that.

With Silverlight 4.0, microsoft removed their quirk. Testing with that and the latest 1.9.2 (Namoroka) build on the following sites, I get the good results:


http://www.silverlight.net/
http://www.microsoft.com/showcase/ja/jp/details/7b917c16-111c-425e-be85-5069a6106f2f
http://www.nederland24.nl/


useragent           OOPP   offset?
----------------------------------
Firefox/3.6.4       Yes    No
Namoroka/3.6.4pre   Yes    No
Firefox/3.6.4       No     No
Namoroka/3.6.4pre   No     No

So I am tempted to say, if users have any issues with offsets, install silverlight 4.0, which should be out in a week or so.
Keywords: qawanted
Silverlight 4.0 is now available through silverlight.net.
Today, I updated plugin to Silverlight 4.0 as follows,
The issue was fixed.

Silverlight Plug-In

    File: npctrl.dll
    Version: 4.0.50401.0
    4.0.50401.0

So, I change this status to RESOLVED WORKSFORME
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → WORKSFORME
Since this is still a problem with SL3, we still need to fix it.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Argh, sorry! I was mixing up this bug with a different one.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → WORKSFORME
blocking1.9.2: ? → ---
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.