1105642 - Mouse pointer position is inaccurate with internal Silverlight application when using a large screen resolution

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Layers, defect)

Description

[Dimas]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141125180439

Steps to reproduce:

We are a company with Firefox 24 deployed to more than 2000 PCs. We have an Intranet app made with Silverlight working ok with this Firefox version. But now we want to update to Firefox 33 and testing it we've found that it doesn't work with the Silverlight app with big monitors. It seems to be related to the resolution of the monitor, or at least, to the size of the Firefox window. The problem is that the mouse pointer doesn't seem to be pointing where it is. It's better explained in this screencast, where you can see that in a 1024px Firefox window it works OK, but when it's 1920px it doesn't work: https://www.youtube.com/watch?v=DA9DLYc-vpE

We tried different versions of Silverlight, currently 5.1.30514.0

I don't know in which Firefox version it started to appear this bug. With Internet Explorer it works.

Comment 1

[:Gijs (he/him)]

Considering we don't have access to your intranet app, can you try to narrow down the regression range?("sometime between Firefox 24 and 33" is a /lot/ of changes to look at...)

We have a pretty user-friendly commandline tool for this purpose called mozregression. You can find instructions on how to use it at http://mozilla.github.io/mozregression/ .

Comment 2

[Dimas]

mozregression ended with an error: AttributeError: 'NoneType' object has no attribute 'inbound_branch', but I found the range:

Last good revision: 298f262f21ff (2014-01-18)
First bad revision: 61fd0f987cf2 (2014-01-19)

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=298f262f21ff&tochange=61fd0f987cf2

After that: "... attempting to bisect inbound builds (starting from previous week, to make sure no inbound revision is missed)
Getting http://(...)/nightly/2014/01/2014-01-11-03-02-00-mozilla-central/firefox-29.0a1.en-US.win64-x86_64.txt
(...)
'NoneType' object has no attribute 'inbound_branch'

Hope it helps!

Comment 3

[:Gijs (he/him)]

So that backlog is very helpful because it's quite small... The only thing that really jumps out at me is the APZ hit testing change, except AFAICT that /should/ only affect touch access? kats, can you confirm my interpretation of that patch? ( http://hg.mozilla.org/mozilla-central/rev/dbe8147a7981 ) 

I just tried to look at the demo screencast, but youtube just tells me "This video is private, sorry about that"...

Alternatively, is it possible to make a simpler (public) testcase with a silverlight app on its own page, considering we can't access the intranet app?

Comment 4

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #3)
> So that backlog is very helpful because it's quite small... The only thing
> that really jumps out at me is the APZ hit testing change, except AFAICT
> that /should/ only affect touch access? kats, can you confirm my
> interpretation of that patch? (
> http://hg.mozilla.org/mozilla-central/rev/dbe8147a7981 ) 

Now with needinfo...

Comment 5

[Dimas]

Now you can see the youtube video, sorry for that: https://www.youtube.com/watch?v=DA9DLYc-vpE

Comment 6

[Kartikaya Gupta (email:[e-mail])]

The APZ change should only have affected touch events, and even so wouldn't affect any desktop platforms. I also looked through the list of changes and the diff between those two revisions and didn't see anything that might cause this. Too bad we don't have inbound builds going that far back.

Comment 7

[:Gijs (he/him)]

So I can't reproduce this on Firefox 34, with responsive mode on http://bubblemark.com/sl3/TestPage.html  (which afaict has a fullpage silverlight plugin). Dimas, can you provide a publicly accessible testcase?

Comment 8

[Dimas]

Trying to publish a testcase I discovered that with the version 37.0.1 the Silverlight app works again ok!

I used mozregression to find when it has been fixed:

10:19.58 LOG: MainThread Bisector INFO Got as far as we can go bisecting nightli
es...
10:19.58 LOG: MainThread Bisector INFO First good revision: f1f48ccb2d4e
10:19.58 LOG: MainThread Bisector INFO Last bad revision: 035a951fc24a
10:19.58 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=035a951fc24a&tocha
nge=f1f48ccb2d4e

41:54.26 LOG: MainThread Bisector INFO Oh noes, no (more) inbound revisions :(
41:54.26 LOG: MainThread Bisector INFO First good revision: 24ba8274ed60
41:54.26 LOG: MainThread Bisector INFO Last bad revision: 2a61df4eaa2d
41:54.26 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2a61df
4eaa2d&tochange=24ba8274ed60

Comment 9

[Dimas]

Viewing the pushlog It makes sense for you?

Comment 10

[:Gijs (he/him)]

I don't know that code well enough to give a whole-hearted "yes", but it is at least not illogical that such a change would fix this. It sounds like we're now using D3D11 to render stuff on win7 even if we weren't before, and that might well be related to (a) it now working and (b) you were having different experiences from me in terms of reproducing the issue when it was broken. CC'ing Bas in case he has any ideas/comments.

Comment 11

[Dimas]

The bug appeared again :( Using Mozregression-gui:

Last good nightly build: 2015-07-28
First bad nightly build: 2015-07-29

Last good inbound build: 9c48bac3 (https://hg.mozilla.org/integration/mozilla-inbound/rev/9c48bac3e0d3 - https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9c48bac3e0d30deec06907bc582516cc170d82b1&tochange=efb3e9a0b0b88d3b482162bb7664691288cb62a2)
First bad inbound build: efb3e9a0 (https://hg.mozilla.org/integration/mozilla-inbound/rev/efb3e9a0b0b8 - https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2696ce503d339ce1e629d95ede7661068c82f841&tochange=efb3e9a0b0b88d3b482162bb7664691288cb62a2)

Comment 12

[:Gijs (he/him)]

I don't know enough about graphics to be useful in commenting on that regression range. Bas should be able to.

Comment 13

[Bas Schouten (:bas.schouten)]

Almost certainly a regression of Bug 1176363.

Comment 14

[Dimas]

Any progress on this?

Comment 15

[Dimas]

Andreas?

Comment 16

[Andreas Pehrson [:pehrsons]]

It's the patch that Bas wrote that appears to be at fault here.

Comment 17

[Bas Schouten (:bas.schouten)]

This bug just needs a diagnosis and work. Right now it's not tracked or prioritized, nor is there a way for me to reproduce or fix it.

Comment 18

[Dimas]

I hope someone can take a look urgently because in our case we can't update Firefox over 2,000 PCs because of it. I imagine there are more people with the same problem that don't know about Bugzilla and simply will change the browser. Sadly, after years promoting Firefox, we will need to to the same if no solution is given.

The reported inbound builds should be a good clue to know what might be the problem and how to solve it.

Obviously I am at your disposal for testing.

Comment 19

[:Gijs (he/him)]

(In reply to Dimas from comment #18)
> I hope someone can take a look urgently because in our case we can't update
> Firefox over 2,000 PCs because of it. I imagine there are more people with
> the same problem that don't know about Bugzilla and simply will change the
> browser. Sadly, after years promoting Firefox, we will need to to the same
> if no solution is given.
> 
> The reported inbound builds should be a good clue to know what might be the
> problem and how to solve it.
> 
> Obviously I am at your disposal for testing.

Can you provide a testcase and/or detailed STR? Can you reproduce the problem with the page linked in comment #7 ?

Comment 20

[Dimas]

I can't reproduce the problem with the page linked in comment #7 ... but we found what part of the app are causing it! It's an animation with gradients of a button's background. Removing these parts the performance seems normal and the app response is ok.

<StackPanel>
	<StackPanel.Resources>
		<Storyboard x:Name="myStoryboardBotoEscollir">
			<DoubleAnimation Storyboard.TargetName="txtEsculli"
			Storyboard.TargetProperty="Opacity"
			From="0.0" To="1.0" Duration="0:0:3" 
			AutoReverse="True" 
			RepeatBehavior="Forever" />
		</Storyboard>
	</StackPanel.Resources>
</StackPanel>

<TextBox Height="22" Name="txtEsculli" Width="138" AllowDrop="True" Background="#FFDC000C" Text="&lt;&lt; Esculli una opció" Foreground="White" TextAlignment="Center" FontWeight="Normal" FontFamily="Portable User Interface" IsReadOnly="False" IsTabStop="False" Padding="2">
	<TextBox.BorderBrush>
		<LinearGradientBrush>
			<GradientStop Color="#FFA3AEB9" Offset="0" />
			<GradientStop Color="#FF8399A9" Offset="0.375" />
			<GradientStop Color="#FF718597" Offset="0.375" />
			<GradientStop Color="#FFE2E8EB" Offset="1" />
		</LinearGradientBrush>
	</TextBox.BorderBrush>
</TextBox>

Comment 21

[:Gijs (he/him)]

(In reply to Dimas from comment #20)
> I can't reproduce the problem with the page linked in comment #7 ... but we
> found what part of the app are causing it! It's an animation with gradients
> of a button's background. Removing these parts the performance seems normal
> and the app response is ok.

This sounds like an issue with silverlight, then? If the extra perf issue is in Firefox, to diagnose it, it'd be helpful to have a testcase we can run - I don't know how to turn the markup you posted into a running app, and even if I did I wouldn't be sure that my version of it reproduces the issue for you.

Comment 22

[Dimas]

The same was working ok with Internet Explorer and Google Chrome (when was compatible with Silverlight), only Firefox is giving this errors.

We will try to create a testcase with this code, but we aren't Silverlight experts, the app was inherited from another person who is no longer with us.

Comment 23

[Kanchan Kumari QA]

Hi Gijs, we are cleaning up items that are marked as untriaged, I need to find a component for this - thinking Core Plugins? Do you have any suggestions that would help.
Thanks!

Comment 24

[:Gijs (he/him)]

(In reply to Kanchan Kumari QA from comment #23)
> Hi Gijs, we are cleaning up items that are marked as untriaged, I need to
> find a component for this - thinking Core Plugins? Do you have any
> suggestions that would help.
> Thanks!

Per comment 17 and/or comment 13, this is a graphics issue, but we still need STR / a testcase.

Comment 25

[Dimas]

I created and published a testcase here: http://permisos.somee.com/gt2/gp.aspx
A howto video: https://youtu.be/ZbN_zAuAVK8

You can compare with the same app without the blink effect here: http://permisos.somee.com/gt/gp.aspx

Comment 26

[:Gijs (he/him)]

I tried to reproduce with the testcase on both 45 beta and 42, and I can't reproduce on either one. I see minor (5%) CPU churn while the page is open, but no slowness in e.g. mouse hover behaviour. The CPU usage does go away on the alternative testcase (without the button pulsating). I tried to create a profile, but it doesn't seem to contain much useful information... In case it's still useful: https://cleopatra.io/#report=3bf080d47e4bd4f5953ffef582305439b205fcf0 .

Bas, is there enough information here for you or someone else from gfx to take a look? Anything else that would help?

Comment 27

[Dimas]

The video is recorded with Firefox 45.0b3. I tried now with 47.0a1 (blank profile) and the same happens: with the blink effect the left buttons don't work as expected. Sorry, I don't understand why you can't reproduce it.

Comment 28

[Bas Schouten (:bas.schouten)]

(In reply to :Gijs Kruitbosch from comment #26)
> I tried to reproduce with the testcase on both 45 beta and 42, and I can't
> reproduce on either one. I see minor (5%) CPU churn while the page is open,
> but no slowness in e.g. mouse hover behaviour. The CPU usage does go away on
> the alternative testcase (without the button pulsating). I tried to create a
> profile, but it doesn't seem to contain much useful information... In case
> it's still useful:
> https://cleopatra.io/#report=3bf080d47e4bd4f5953ffef582305439b205fcf0 .
> 
> Bas, is there enough information here for you or someone else from gfx to
> take a look? Anything else that would help?

Not really. I can't reproduce it either. I'm not sure it's caused by bug 1176363 anymore either. With the additional information here that seems a lot less likely, we'd need someone who can reproduce it to at least concern that that patch is at fault in order to try anything at all.

Comment 29

[Kanchan Kumari QA]

Attachment: MouseHover.mp4

Even I can't reproduce it on the latest nightly 47.0a1. I tried on Benq GL2250-B monitor that supports up to 1920 X 1080p resolution. Tried several times to duplicate it using the URL http://permisos.somee.com/gt2/gp.aspx that Dimas specified but I just could not. I am attaching the screencast recording of the steps. 

Dimas,
Is there any other way to duplicate the problem? We are not able to do it using the test case that was specified. In case steps are not correct in the attached recording or there is an alternative way then please let us know.

Comment 30

[Kanchan Kumari QA]

Resolved-Incomplete due to time since last communication/update by reporter.
Please feel free to reopen if the error occurs in a current Firefox version and please also include any changes to Steps to Reproduce.

Comment 31

[Dimas]

Clearing needinfo