536429 - [FF3.6 Windows Only] - silverlight.net/Showcase : The mouse position is not captured accuratly

Status: RESOLVED WONTFIX

(Plugins Graveyard :: Silverlight (Microsoft), defect, P1)

Description

[Andy Rivas]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5  (.NET CLR 3.5.30729)

Mouse positions do not appear to be captured accurately with 3.6beta

Reproducible: Always

Steps to Reproduce:
1. Install Silverlight 4 Beta from http://silverlight.dlservice.microsoft.com/download/F/6/5/F653F7FD-AD4D-411D-8B1F-9C4B1BD69881/Silverlight_Developer.dmg
2. Go to http://silverlight.net/showcase/
3. After the app loaded well, move the mouse to ">" icon on the bottom right
4. Try to click it

Actual Results:  
The mouse position is not captured accuratly, if you want to click the ">", you should move the mouse to the left icon of the ">"
[NOTE]: Because of this issue, so the show cases cannot be selected and run


Expected Results:  
The mouse position should be captured accurately,


Bug Repros on Configuration:
WinXP + FF 3.6 Beta3
Vista + FF 3.6 Beta3

Bug does not repro on Configuration:
WinXP + FF 3.5 / IE6
Vista + FF 3.5 / IE7
Mac_OS_X_10.5 + FF3.6 Beta3

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

i can confirm this issue for
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5 ID:20091204143806

though it works on today's trunk (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091223 Minefield/3.7a1pre ID:20091223050727)

both using:
Silverlight Plug-In Version: 4.0.41108.0

Comment 2

[Andy Rivas]

So where are we in the investigation of this issue?

Comment 3

[Andy Rivas]

3.6 has shipped and this issue has broken http://Silverlight.net/showcase.  Has anyone looked at this?

Comment 4

[Jon]

I can confirm the issue on silverlight.net and I have a similar bug in a site I develop.  It appears that Silverlight components with "windowless=true" are having mouse coordinates calculated incorrectly.  This was not the case with my site under 3.5.7, but it is affected by the new Firefox 3.6 release.

To note, I have a silverlight plugin with windowless=true inside an iframe loaded to an absolute position in my application.  In my application the mouse is offset by a vertical amount equal to the amount of space above my iframe.

Comment 5

[Andy Rivas]

Thanks for confirming, Jon.

Is this considered a Firefox breaking change?  Have there been reports of Flash windowless apps being affected as well?

For Silverlight this is a high priority issue.  Can we have someone take ownership of this bug and have a closer look?

Comment 6

[Mike Shaver (:shaver emeritus)]

Confirming.  JST: can you take a look at this?

Andy or others who are set up to reproduce it -- could you do a binary search with the nightlies from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ with "1.9.2" in the directory name, and see when it was introduced?  That would help a lot in getting a fast fix in place.

Comment 7

[Andy Rivas]

Maybe someone could help me out here but I'm not able to repro on builds from the Nightlys:

2009-12-21-05-mozilla-1.9.2_OK
2009-12-26-03-mozilla-1.9.2_OK
2009-12-30-05-mozilla-1.9.2_OK
2009-12-31-05-mozilla-1.9.2_OK

But I install any of the Milestone builds from B1 - RC2 and the issue repros.  Can I get confirmation from someone?

Comment 8

[Mike Shaver (:shaver emeritus)]

One difference there would be the user agent -- does Silverlight do anything different for a user agent of "Firefox" versus a user agent of "Minefield"?

Comment 9

[Mike Shaver (:shaver emeritus)]

Also, thanks a ton for the regression-checking legwork!

Comment 10

[Andy Rivas]

You bet and I'll check on the user agent.

Comment 11

[Andy Rivas]

Yes, the user agent appears to be the issue.  We're checking now with an app owner to determine how they are handling the user agent.

Thanks for the help and I'll keep you posted as the info could be useful to others.

Comment 12

[Andy Rivas]

We're getting from the application owner that they don't do anything special to handle the user agent.  Do you guys have any ideas why the mouse coordinates are offset and if Flash windowless apps experience the same issue?

Comment 13

[Andy Rivas]

Alright, so yes, we are indeed handling the user agent for offset issus that have now been fixed in 3.6.

Mike or anyone watching, do you know if there are Silverlight applications in your test suites?

How often are test passes performed against shipping branch builds?

Thanks

Comment 14

[Mike Shaver (:shaver emeritus)]

Do you have the bug numbers for those offset issues?  Would be good to close the loop on them.

There aren't Silverlight applications in our test suites.  Last I checked, the Silverlight license wasn't compatible with being distributed that way, but if there are freely redistributable Silverlight test suites that we could incorporate, that would certainly be worth looking at.

For specific fixes, we have a test plugin that we add to in order to provide coverage and protect against regressions.  Patches to add tests there would be very welcome, and probably the most productive way of working together to improve our mutual-user experience.

Our tests are run on every commit that happens.

If you'd like, I could point you at instructions for running our test tools, so that you could set up something to report your own automated Silverlight test results back to us.  It'd be a bit of work on our end to get set up to accept them, but probably worth it!

Comment 15

[Dustin]

Just to add a little confusion to the mix. If you use the User Agent Switcher (https://addons.mozilla.org/en-US/firefox/addon/59) and switch to any UA besides FF, the mouse position is captured correctly.

Comment 16

[Ashish Shetty (Microsoft)]

Mike: regarding the bug number for the offset issue, this appears to be the bug the Silverlight team had reported a few years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=356084

The data in there is stale, but my understanding is some time later on we added a workaround in Silverlight to account for the incorrect offsets in Firefox with windowless Silverlight plugin instances. 

Apparently some fix in Firefox 3.6 fixed the original issue but without quirking the old behavior. Now ironically our workaround - which currently exists in Silverlight versions in the wild - is surfacing as a bug. We've fixed this in our current sources so future releases of Silverlight (i.e. 4 and up) should see the right behavior on 3.6 and up, as well as 3.5 and below. This is where the user agent based pivot comes.

Aside from instantiating the plugin as windowed, is there any other workaround app/page authors can use? Alternately is there a way to add a quirks mode behavior to the FF3.6 fix?

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There might be a workaround for authors but right now I'm not sure what the change was so I can't recommend one. The fastest way to figure that out is probably to bisect using nightly builds to find a fix range. It sounds like you can install the User Agent Switcher extension to set the UA string to Firefox to reproduce the bug.

At a wild guess it might have been the changes in bug 506304 that caused a behavior change.
http://hg.mozilla.org/mozilla-central/rev/333fb0fdfd67

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

A minimal testcase would also be useful.

I'm reluctant to work around Silverlight's work-around ... that way lies madness :-)

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If it's bug 506304, then I would expect only Silverlight plugins in IFRAMEs to be affected.

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I see that silverlight.net/showcase has the Silverlight object in an IFRAME. Not putting the Silverlight object in an IFRAME would be one possible workaround.

Comment 21

[Andy Rivas]

Roc, I actually installed a months worth of nightlys earlier this month but since the Nightlys' user agent is not "Firefox/3.6" but "nakamura" the issue does not reproduce.  Someone would need to install a nightly and change the user agent.

Also, another offset bug that you are looking at https://bugzilla.mozilla.org/show_bug.cgi?id=508382 

Thanks

Comment 22

[Benjamin Smedberg]

Whew, we've been have all sorts of OOPP problems on the showcase because it's windowless and in an iframe. The iframe thing is the key!

Comment 23

[Ashish Shetty (Microsoft)]

The specific showcase URL is just a poster child of the general problem. I'll notify its owners at Microsoft and see if it really needs that combination of windowless and iframe. 

However the usage doesn't seem to be uncommon, especially in cases where CDNed/3rd party Silverlight content is hosted on pages like web portals. We have a customer with exactly this combination happening on a high traffic portal in Europe. I am seeking their permission to post their URL here.

Comment 24

[Jon]

Agreed.  My application is a web-based tabbed MDI with multiple Silverlight applications hosted within the tabs' iframe containers.  It's not feasible for our application to remove iframe (the tabs are loaded as needed dynamically) or windowless (this breaks having our main toolbar overlay the silverlight controls as they display on-screen).

Unfortunately, our users cannot all install/use the User-Agent Switcher, so for the moment we're asking them to downgrade to 3.5.7 until this can be fixed.

Comment 25

[Robert O'Callahan (:roc) (email my personal email if necessary)]

At this point I think our options are
1) We update Firefox 3.6 to work around your workaround for Silverlight 3
2) You update Silverlight 3 to remove your workaround for Firefox 3.6

On the face of it, #2 sounds better because it reduces complexity instead of adding complexity. In particular, Silverlight 3 is already sniffing for Firefox, but we are not sniffing for Silverlight (any version).

Comment 26

[Ashish Shetty (Microsoft)]

Correct, but there's the hypothetical app author workaround as option 3. I just don't know what that is. Any suggestions there would be much appreciated. 

As to option 2, we can do the engineering easy enough. The issue currently is that our only planned release vehicle isn't until April. That is too late for our mutual affected customers. This is primarily why we were asking for option 1 to be considered. However if a fix in Firefox cannot make it by until April or later, then we will explore other other options (i.e. 3 or accelerating 2). 

We're in this together for the long haul and we wouldn't want the Firefox team to do what we wouldn't ourselves do :)

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I suspect the only reasonable workarounds for customers are:
1) don't put windowless Silverlight in IFRAMEs
2) if you do put windowless Silverlight in an IFRAME, ensure that the IFRAME's top-left is at the top-left of the viewport for the outermost document.

If there was a security bug you'd release before April, right?

If we were to work around your workaround, how exactly would we detect which Silverlight version(s) to apply our work-around to?

Comment 28

[Johnny Stenback (:jst)]

What would the Silverlight plugin do if we made the npruntime hooks that the silverlight plugin calls (all NPRuntime hooks, really) fail if they're called while the plugin is told to paint? Would it use the correct values, or fall back to 0,0, or fail in some way?

Comment 29

[Andy Rivas]

We've found a workaround.  You can override the user agent string before instantiating the control.  We’ve also found that using CSS overflow property can  cause issues as well so best to not use this property if possible.

This snippet below can be run after a browser check for Firefox.

// you can choose your own user agent string but just don’t use Firefox

function changeuserAgent() {
        
            var altuserAgentGetter = function () {
                return "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 <choose your string>/3.6";
            };
            if (Object.defineProperty) {
                Object.defineProperty(navigator, "userAgent", {
                    get: altuserAgentGetter
                });
            } else if (Object.prototype.__defineGetter__) {
                navigator.__defineGetter__("userAgent", altuserAgentGetter);
            } 
        }

Comment 31

[Austin McDaniel]

I see that someone says its fixed above, what is the fix?  I tried updating my firefox but there were no updates available.

Comment 32

[Benjamin Smedberg]

There is a workaround that customers can deploy. Mozilla has not made any code changes, so going to call this WONTFIX per our resolution guidelines.

Comment 36

[Austin McDaniel]

How can this statement be true:"Mozilla has not made any code changes" if the same version works in Firefox 3.5 and not 3.6?!?

Comment 37

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Benjamin meant that "Mozilla has not made any code changes" to fix this bug.

Comment 43

[Mike Kelley]

Attachment: Example of mouse position issue in FF 33.1