![Firefox logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2020-04-14-08-36-13-8dda6f.png)
Recent change in behaviour of Silverlight pages in Firefox - buttons react to "mouseover", but "select" hotspot is 2cm above the button.
This has only started happening in the last few weeks, and only happens in Firefox. IE and Chrome are fine. Many Internet TV channels use Microsoft Silverlight as the player (e.g. SKY and BT Sport). Thel Silverlight pages usually have seveal buttons for things like "Play", "Stop", "Full screen" etc.. Moving the mouse over such buttons makes them highlighted, as you would expect. However the hotspot -- the point where the cursor changes from an arrow to a hand pointer -- is always 2 cm higher up the screen. It was driving me crazy that the buttons reacted to the mouse passing across them, but I couldn't click and make them do anything. It was days before I accidentally discovered why, and where the hotspots had gone.
But how / why / what / ...?
Software levels: O/S Windows XP SP3, Firefox 21.0, Silverlight 5.1.20513.0 (latest version). Uninstalling and reinstalling Silverlight made no difference.
被選擇的解決方法
FOUND IT !!!!!!!!!!!!!!!!!!!
But only by a very long process of elimination.
I duplicated my Firefox profile, did a reset to its default state, and discovered that the problem went away. So I then, very slowly, one step at a time, added all the bits back in to bring this reset profile back to match the real one.
The culprit was a preference that removed crash protection from Silverlight:
dom.ipc.plugins.enabled.npctrl.dll = false
Change it to true, the problem goes away. Change it back to false, the problem reappears. I remember fighting the crash-protection settings several weeks ago (not related to Silverlight in particular) following all sorts of guidance. I don't know which particular article encouraged me to make this change, or why, but that would explain when it appeared.
Which just leaves one big question -- though for "interested readers" only: WHY??? Why on earth would taking Silverlight out of crash protection mess up how it interacts with the mouse?
Answers on a postcard to...
(Oh, and a further wrinkle I discovered on the way: it only happens if the Silverlight session is embedded within a web page. It never happens in full-screen mode.)
從原來的回覆中察看解決方案 👍 0所有回覆 (12)
Try to disable hardware acceleration in Firefox.
- Tools > Options > Advanced > General > Browsing: "Use hardware acceleration when available"
- https://support.mozilla.org/kb/Troubleshooting+extensions+and+themes
It already is disabled, I'm afraid.
Try to set the layout.css.devPixelsPerPx pref on the about:config page to 1.0 (current default value is -1.0).
You can use this extension to adjust the font size for the user interface if necessary.
- Theme Font & Size Changer: https://addons.mozilla.org/firefox/addon/theme-font-size-changer/
You can look at the Default FullZoom Level or NoScript extension if web pages need to be adjusted after changing layout.css.devPixelsPerPx.
- Default FullZoom Level: https://addons.mozilla.org/firefox/addon/default-fullzoom-level/
- NoSquint: https://addons.mozilla.org/firefox/addon/nosquint/
Thank you for trying, but...
I recognize all these suggestions. They're the standard set of experiments to try and make Firefox 22 onwards behave the same as it always used to -- before they started messing around with screen resolutions and trying to get clever. I went through them all when FF22 first came out, and never managed to make a usable UI. So I went back to FF21, where I intend to stay.
But just to double check:
- layout.css.devPixelsPerPx was already 1.0 (legacy of the above experiments). Changing it back to -1.0 gave ma a screen I can read from the other end of the street, so I put it back to 1.0 again.
- Theme Font & Size Changer didn't do anything for the Silverlight problem.
- I have always had NoSquint installed. So I tried disabling it, in case it had been updated recently and become the culprit. Sadly that made no difference to Silverlight either.
This problem is really, really silly. It only happens in Firefox. It only affects interactive buttons in Silverlight screens. It affects every button on every Silverlight screen. The error is only a vertical displacement, not horizontal.
Does changing the layout.css.devPixelsPerPx pref has any effect on where you need to click in Silverlight?
Sort of. It increases the distance in the same proportion as the display resolution increases. I have my screens set to "Large", i.e. 125% (120 dpi). Changing that setting increases the size of Silverlight frames by 25%, and also increases the distance up from the buttons to their hotspots by 25%. (I hope that makes sense!)
Example: I have a web page with an embedded Silverlight screen that is 176 pixels tall. I have to click about 60 pixels above each button. Changing the option to -1.0 increases that frame to 220 pixels tall, and I now have to click 75 pixels above each button.
Did you try a higher setting for the layout.css.devPixelsPerPx pref like 1.25 or 1.5 to see if that helps?
You can try to increase layout.css.devPixelsPerPx starting with 1.0 in 0.1 or 0.05 steps (1.0 or 0.9) to to see if you can find a setting that works satisfactory.
You're missing the point -- it will never solve the problem. All it does is make the whole display bigger or smaller. But no matter how big or small it is, the mouse hotspots are always too high. In the above example, the point is always out by about one third the height of the Silverlight frame. Whether it's one third of 20 pixels or of 2,000 pixels it's still out by one third the height of that frame. The only way I could make the hotspots and the buttons coincide is by reducing the resolution so much that the entire screen is compressed down to a single pixel. Even then they only coincode because of rounding errors when converting the frame height to a whole number!
Hmmm, BT Sport doesn't like viewers from California...
Did you try Firefox's Safe Mode? That's a standard diagnostic tool to bypass interference by extensions (and some custom settings). More info: Diagnose Firefox issues using Troubleshoot Mode.
You can restart Firefox in Safe Mode using
Help > Restart with Add-ons Disabled
In the dialog, click "Start in Safe Mode" (not Reset)
Any difference?
Good idea...
...But no difference I'm afraid. Still, on the positive side I guess we can rule out an add-on being the culprit.
I'm going to see if I can find an older version of Silverlight and try that. I'll report back later.
選擇的解決方法
FOUND IT !!!!!!!!!!!!!!!!!!!
But only by a very long process of elimination.
I duplicated my Firefox profile, did a reset to its default state, and discovered that the problem went away. So I then, very slowly, one step at a time, added all the bits back in to bring this reset profile back to match the real one.
The culprit was a preference that removed crash protection from Silverlight:
dom.ipc.plugins.enabled.npctrl.dll = false
Change it to true, the problem goes away. Change it back to false, the problem reappears. I remember fighting the crash-protection settings several weeks ago (not related to Silverlight in particular) following all sorts of guidance. I don't know which particular article encouraged me to make this change, or why, but that would explain when it appeared.
Which just leaves one big question -- though for "interested readers" only: WHY??? Why on earth would taking Silverlight out of crash protection mess up how it interacts with the mouse?
Answers on a postcard to...
(Oh, and a further wrinkle I discovered on the way: it only happens if the Silverlight session is embedded within a web page. It never happens in full-screen mode.)
由 mfjames 於
Good sleuthing. I suspect that the vast majority of testing is done with plugins running in the plugin-container.exe process rather than the firefox.exe process, since that became the default long ago in Firefox 4. As a result, the problem you discovered might not have been noticed before and may never have been filed as a bug.