There is a bug in Firefox 3.6 that seems to wrongly notify plugins of a mouse position update just after a click. For some details, look at the previous entry of this blog, and possibly at this bugzilla entry.

Your application is impacted if:

  • you use double-click event listeners, as you won't get any of these
  • you noticed the (custom) cursor of you app "flicker up and down" very quickly on clicks, or you have some other flickering artifact (if you make something follow the cursor on clicks)
  • your application is complex enough in the way it handles mouse events, and you get random and hard to diagnose misbehaviors

Case 1 is possibly the most common (probably what hits google Street View).

Case 2 is hitting maniac people with good eyes and a thing for applications that work pixel for pixel.

Case 3 hit us.

Given I haven't had time enough to dig into Gecko regression window, and ideally come with a patch, and given we simply can't wait for Mozilla to ship a not broken Firefox, I had to write an ActionScript patch.

Usage is dead simple. In your main DisplayObject (at least one that won't go away from the stage until you're done), call:

new Bugzilla537269( this );

If you want doubleClick support as well:

new Bugzilla537269( this, 500 );

where "this" obviously is your main DisplayObject, and "500" is the delay between two clicks to be considered a doubleClick.

What it does?

It swallows-up all the extraneous mouseMove, mouseOver, mouseOut, rollOut, rollOver and mouseAway events that get dispatched, before they hit your application.

The following cases are handled:

  • hovering the stage, get a position update out of the stage (including the late over event)
  • hovering the stage, get a position update on a DisplayObject
  • hovering a DisplayObject, get a position update out of the stage (including the late over event)
  • hovering a DisplayObject, get a position update on another DisplayObject
If doubleClick support is enabled, it does also dispatch a doubleClick if:
  • the two clicks are hitting the same object
  • the two clicks occur during the "n" timeframe that you defined
  • there is no mouseMove between the two clicks

If the patch detects that you are not on Mac, it will self-destruct.

If the patch detects (after the first click) that it was not needed (any browser that don't have the bug), it will self-destruct.

Weak-ref are used for all listeners. The patching instance stays alive by keeping a static ref to itself, so, you don't need to (and should not) keep a ref to it, in order for it to be gc-ed. The patching instance suicides whenever the referenced DisplayObject you passed to its constructor is removed from the stage.

Tested with

  • flash 10.0.42.34 (both standalone and as a plugin)
  • Firefox 3.5 and 3.6
  • Leopard

Caveats

  • not tested with anything else but the above. If this triggers bugs for normally working platforms I'll probably know soon and will modify the patch
  • this might break in some very rare conditions that I still have to think about :-)
  • you might want to clean-up all the "traces" in order not to pollute your console when debugging
  • this is a darn freakin' ugly hack, and I have absolutely no incentive to prettify it
  • do whatever you want with it - if you can, be kind enough to ping me back if you are having unexpected problems with it so that you save us the trouble to be notified by our users later on :/

Download

Source

[Update]

In some conditions, things were not working correctly. Here is an updated version - though, I changed the registration mechanism slightly, so, you'll have to find your way out (now a singleton with an "enable" function and a package name change).