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).

• http://kb.mozillazine.org/about:config

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.)

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.