542068 - Double-click does not work in Flash 9+ applications in FF 3.6 OSX

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Dan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

In Flash, any component which subscribes to the 'doubleClick' event will never have that event triggered.  

Reproducible: Always

Steps to Reproduce:
1.  Double-click the '[double]' click me' button

Actual Results:  
[16:38:51 GMT-0500] click
[16:38:51 GMT-0500] click

Posts to the output window

Expected Results:  
[16:39:31 GMT-0500] click
[16:39:31 GMT-0500] doubleClick

Posts to the output window. 
Note: Double click event is recorded on line 2

This is on a Mac running OSX 10.6.2, default theme.  QA team has thoroughly tested this issue and customers are noticing it as well.  There is also some buzz about this problem around on message boards, Twitter, etc.  This is critical to our product and there seems to be no clean fix that we can implement as a workaround.

Comment 1

[Tyler Downer [He/Him]]

Charles, is this something for flash?

Comment 2

[Charles]

I am hearing about this.  I just finished looking at the example and am UTR.  I need some version info to reproduce.  So far I am UTR on 10.1.51.66 (Beta 2) and 10.0.42.34

Comment 3

[Dan]

Updated URL and updated with a more reproducible test case.  Visit http://www.foozebox.com/doubleclick/index.html

1.  Double-click the 1st or 2nd item and large image shows and event type is recorded.  
2.  Double-click 3rd or 4th item and double-click does not fire and 'doubleClick' event type is not recorded at top of screen.  

(Right-click to view Flex AS3 source.)

Comment 4

[Rob]

Our customers are experiencing this at Sprout (http://sproutinc.com), rendering some of our product unusable since it relies on double-click!

Comment 5

[Charles]

This is interesting.  From what I can tell at this point is Mac 10.6 64-bit vs
32-bit machines behave differently for Flex where Flash Player consistent. This
could be due to different event models.

In addition it was injected in 3.6.  No difference in behavior from our current
release to 10.1 beta 2.

Flex test application
1)Fail - 10.6 64-bit processor
2)Pass - 10.6 32-bit processor

Flash AS3 test application
! Fails on all Mac 10.6 all flavors for Firefox 3.6

Comment 6

[Charles]

This indicates to me a Firefox bug.  Can someone validate that?

Comment 7

[Bob Clary [:bc] (inactive)]

I get inconsistent results on 10.5 across gecko 1.9.0, 1.9.1, 1.9.2, 1.9.3. Is this report about Mac OS X 10.6 only?

Comment 8

[Lingfeng.Guan]

There are also users in china call in to complain about the bug.
It seems to be Mac only
Does not affact Windows users

Comment 9

[Lingfeng.Guan]

The user mentioned it only affact OS X 10.6

Comment 10

[Charles]

Attachment: Flash AS3 double click test

Comment 11

[Charles]

It could be 10.6 only considering its worse in 64-bit over 32-bit versions of 10.6.

Comment 12

[Kyle Harr]

The problem also exists on 10.5.8 in 1.9.2 on a 32-bit machine (1.83GHz Core Duo). Flash plugin is 10.0.32.18. Verified that problem does not exist in 1.9.0.1 (or Safari) with same configuration. 

I have occasionally been able to produce a double click event. I can only get this to occur with repeated, rapid clicking of my trackpad button while simultaneously tapping the trackpad surface. It usually takes a few seconds of this to generate a double click.

Once I am able to produce one double click, I can then produce double clicks unless I click the button and tap the trackpad simultaneously.

I have not been able to generate a double click with a usb mouse.

Comment 13

[Kyle Harr]

Some more info. Flash documentation (http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/display/InteractiveObject.html#event:doubleClick) indicates that a double click is generated when Flash detects the following sequence: 
mousedown, 
mouseup, 
click, 
mousedown, 
mouseup,
doubleclick. 

In 1.9.2, a double click on the mouse button produces: 
mousedown,
mouseup,
click,
mousemove,
mousemove,
mousedown,
mouseup.

1.9.0.1 produces the correct event sequence. I believe the extra mousemove events are causing the problem.

Comment 14

[Pete Couture]

This bug has broken our card creator at www.cocodot.com

Able to reproduce only on firefox 3.6 MacOSX Leo and Snow Leo

Comment 15

[Pete Couture]

For you flex people the work around is to go back to the old school way of detecting for double click and using a timer and boolean on a mouse down/up/click event.

Comment 16

[David Tristram]

I'm seeing the additional mouse move events.  Flash Player would ignore them if they fell within the double click time window.  However, the events are also delayed, and the second click is coming too late as well.

Comment 17

[Kyle Harr]

David, do you have timing data? I have used Pete's suggestion without noticing any delay issues.

Additionally, on my configuration described earlier, I found that double-clicks _are_ generated when in full-screen mode. I had implemented Pete Couture's fix (and it's very simple to do) and found that when I disabled double-clicks and manually detected clicks, I could not register any double-clicks while in full-screen. So I enabled double-click detection and used the Timer method as well. Doing this will not generate two double-clicks in full-screen mode (assuming you have an appropriate time interval set), since the event subsystem  will not generate the second single-click event if it detects it as a double click. Now if you triple-click within your timer interval, then the third click would be recognized as the second click unless you did some filtering.

Comment 18

[David Tristram]

I did some analysis last night.  The problem does not repro for me on simple content, but it's consistent with a complex site, regardless of full-screen mode. 

Pete's timer hack will not work in the content I am looking at because the events are delivered late.  I am seeing very rapid clicks reporting as 550 and even 1000 milliseconds apart.  Unfortunately, the event time as embedded in the event timestamp and the wall time in the Flash Player event handler agree with these late numbers, so I don't think there is anything I can do in the plugin.

Comment 19

[Dan]

I agree that the timer hack is a bad idea. It will potentially negatively affect other browser/OS combinations and put an unnecessary strain on any QA team.

The most prevalent place this bug occurs is in Google Maps Street View.  Try to double-click (to walk) around a map.  

This bug surely needs to be addressed as soon as possible by either Mozilla or Adobe.  Sadly, it looks like it has not been assigned to be fixed at this point.

Comment 20

[David Tristram]

(In reply to comment #3)
> Updated URL and updated with a more reproducible test case.  Visit
> http://www.foozebox.com/doubleclick/index.html
> 


foozebox.com is not resolving for me just now, problem?

Comment 21

[Kyle Harr]

Dan, I have to disagree with regard to using a timer and flag to determine double-clicks in conjunction with the built-in double-click event. As I noted, if Flash is generating the double-click event, it will not generate the second click event, so the timer technique will not generate a double-click if double-clicks are being generated by Flash. In addition, an event listener could be configured to set the flag to false if a real double-click event is detected. This would provide seamless and consistent double-click behavior regardless of the platform. The following code added to an InteractiveObject will provide seamless double-click support regardless of environment

private var doubleClickTimer:Timer = new Timer(250);
private var firstClick:Boolean = false;

doubleClickEnabled = true;

private function doubleClick(evt:MouseEvent):void{
    if(evt.type == MouseEvent.DOUBLE_CLICK){
        firstClick = false;
        doubleClickEvent(evt);
    } else if(firstClick){
        firstClick = false;
        doubleClickTimer.stop();
        doubleClickEvent(evt);
    } else {
        firstClick = true;
        doubleClickTimer.start();
    }
}

private function clickTimer(evt:TimerEvent):void{
    firstClick = false;
    doubleClickTimer.stop();
}

Granted, this isn't going to work if your problem looks like David's, but I haven't been experiencing any slowness. It seems as though this problem has several different manifestations. Using this technique, I catch every single double-click in my environment.

Comment 22

[Dan]

(In reply to comment #20)
> (In reply to comment #3)
> > Updated URL and updated with a more reproducible test case.  Visit
> > http://www.foozebox.com/doubleclick/index.html
> > 
> 
> 
> foozebox.com is not resolving for me just now, problem?

Domain issues..sorry.  updated:
http://foozebox.x10hosting.com/doubleclick/index.html

Comment 23

[Dan]

(In reply to comment #21)
> Dan, I have to disagree with regard to using a timer and flag to determine
> double-clicks in conjunction with the built-in double-click event. As I noted,
> if Flash is generating the double-click event, it will not generate the second
> click event, so the timer technique will not generate a double-click if
> double-clicks are being generated by Flash. In addition, an event listener
> could be configured to set the flag to false if a real double-click event is
> detected. This would provide seamless and consistent double-click behavior
> regardless of the platform. The following code added to an InteractiveObject
> will provide seamless double-click support regardless of environment
> 
> private var doubleClickTimer:Timer = new Timer(250);
> private var firstClick:Boolean = false;
> 
> doubleClickEnabled = true;
> 
> private function doubleClick(evt:MouseEvent):void{
>     if(evt.type == MouseEvent.DOUBLE_CLICK){
>         firstClick = false;
>         doubleClickEvent(evt);
>     } else if(firstClick){
>         firstClick = false;
>         doubleClickTimer.stop();
>         doubleClickEvent(evt);
>     } else {
>         firstClick = true;
>         doubleClickTimer.start();
>     }
> }
> 
> private function clickTimer(evt:TimerEvent):void{
>     firstClick = false;
>     doubleClickTimer.stop();
> }
> 
> Granted, this isn't going to work if your problem looks like David's, but I
> haven't been experiencing any slowness. It seems as though this problem has
> several different manifestations. Using this technique, I catch every single
> double-click in my environment.

Well, it's not so much that your solution/code will not work, I'm sure that code is perfectly well suited in many cases and thank you for it.  

My issue is I've got 15+ different implementations of double-click used on many different objects (images, item renderers in a list, text-inputs, etc.) all of which are carrying data within the actual event.  These occur within 5 or so enterprise-level applications that are currently in production.  So the code change would be very large and would be considered high impact/risk. It also would require a team of people, time, and coordination.  

So until there is a Flash or FF patch sent out to the public, my organization will have to sit tight until I know there is absolutely no resolution.

Comment 24

[Kyle Harr]

You know your situation best.

By the way, I just tested your example and I can double-click the first item in the list, but the last three don't produce a double-click despite my repeated attempts. As I understand, the first two items generate double-clicks for you. Did you implement alternate click handling, or is this just another one of the quirks of this bug?

Comment 25

[David Tristram]

just wanted to report I've been working on this bug.  It's very difficult to reproduce reliably.  It seems as though just debug output to a terminal window can change the event timing.  I've been building the FF 3.6 and 3.7-dev sources and have confirmed that FF event timestamps correspond to the time Flash Player is receiving the events.  I have not been able to reproduce the problem in the dev branch, and I see that FF is now using the "new" OSX event path into the player.  But I'm not yet convinced the problem is fixed because right now I can't repro in my build of 3.6 either.

Comment 26

[David Tristram]

I've implemented a partial fix in Flash Player that keeps a mousemove that falls in the double click time window from killing the double click.  So far I've not seen again the problem where the mouseUp arrives too late.  I never saw the delayed events with the 3.7 dev sources so we may be good on this now.

Comment 27

[David Tristram]

This bug is UTR in today's nightly build of Minefield, 3.7a2pre.

Comment 28

[Steven Michaud [:smichaud] (Retired)]

The buggy behavior starts with the landing (on the trunk) of part of
the patch for bug 504524
(http://hg.mozilla.org/mozilla-central/rev/77787eb64629).

I can't see how this patch could have triggered the problem, and I'm
not yet convinced this is a Firefox bug.  I'll keep digging.

Comment 29

[Steven Michaud [:smichaud] (Retired)]

Testing with my DebugEventsPlugin from bug 441880 in FF 3.6, I don't
see any mouse-moved events when I double-click on the plugin (even in
Carbon event mode).  I think their presence must be caused by one or
more bugs in the Flash plugin.

I'll continue working on this tomorrow.

Comment 30

[Kyle Harr]

Steven, it may be a flash bug, but as I wrote earlier, my testing indicates that it is triggered by upgrading to 3.6. I have both 3.0 and 3.6 installed. When using 3.0 with the same flash plugin, I did not receive any mouse move events in my flash app between click events. However, mouse move events did pop up when I tested the app in 3.6.

I've seen other bizarre flash bugs that seem to defy logic (<a href="http://krpano.com/forum/wbb/index.php?page=Thread&threadID=1263">flash failing to load when the page enclosing a compressed swf contains a fragment identifier in the url</a>), so it wouldn't surprise me that flash is at fault, but in this case the trigger appears to be Firefox.

Comment 31

[David Tristram]

@Steven: I really don't think this is a Player problem.  In the release build I am definitely getting from FF 3.6 mouse move (null) events between the mouse down and up that we did not see in earlier versions.  I've added a fix in Player that does not let move events that fall within the double click window kill a double click.

Comment 32

[David Tristram]

We also saw a bug in Flash content where after a mouseUp in a control the control did not return to the hover state, but rather to the normal state.  I saw that FF 3.6 was delivering after every mouseUp a mouseMove that has bad coordinate.  The where point might be offset by the window origin, perhaps?  With the wrong coordinates, Flash Player interpreted the pointer as being outside the control and generated a mouseOut event in ActionScript, leading to the incorrect control state.  I have put in a fix in Flash Player to ignore the first mouseMove after mouseUp and we are getting good behavior.

I am not aware of a separate Mozilla bug on this bad mouseMove event problem, but it seems related to this bug, and I'm hoping it will get fixed at the same time.  At some point my fixes would then be removed from the Player.

Comment 33

[Steven Michaud [:smichaud] (Retired)]

I've been working on this, and have a fix for it.  But the fix isn't
complete -- so I won't post it yet.  And (as it happens) Josh already
arrived independently at one part of "my" fix (in his patch for bug
518135, which landed on the 1.9.2 branch on 2010-02-24).

Either of these two "parts" makes the double-click problem go away.

To confirm this, please test a current 1.9.2-branch (aka FF 3.6.X)
nightly.

(From comment #28)

> The buggy behavior starts with the landing (on the trunk) of part of
> the patch for bug 504524
> (http://hg.mozilla.org/mozilla-central/rev/77787eb64629).

This turns out to be incorrect.  The patch that triggered the problem
is actually part of the patch for bug 506304 (its tests) --
http://hg.mozilla.org/mozilla-central/rev/22588ab14ac6.

I used 'hg bisect' to pin the blame on (part of) the patch for bug
504524.  But the result was so strange (and I was making so little
progress) that I decided to redo the search (for the guilty patch) "by
hand" (without using 'hg bisect') ... and arrived at a different
result.

This is the first time I've ever seen 'hg bisect' give the wrong
result.  Which is very puzzling, and a bit disturbing.  But I'm afraid
I don't have time to figure out why it happened.

In my debugging I've found this problem has nothing to do with event
timestamps.  And (as I already said above in comment #29) tests with
my DebugEventsPlugin show that the browser doesn't send mouse-moved
events to a plugin when you double-click on it.  Both of these
problems are Flash bugs, caused (as best I can tell) by the Flash
plugin's processing of "null events".

But Firefox also has bugs, which contributed to this problem:

1) Before Josh's patch for bug 518135, Firefox sent null events to the
   plugin for each of the following DOM events, whenever you
   double-clicked in it:

   NS_MOUSE_CLICK (2)
   NS_MOUSE_DOUBLECLICK (1)

   (Of course, on each ordinary mouse click it also sent one null
   event for every NS_MOUSE_CLICK DOM event.)

2) The wrong coordinates were used for these events -- window
   coordinates instead of screen coordinates.

Either of these bugs could explain why Flash gets confused and
generates spurious mouse-moved events with the wrong timestamp.

Comment 34

[Steven Michaud [:smichaud] (Retired)]

Attachment: 1.9.2-branch fix

As I noted above (in comment #33), Josh's patch for bug 518135 also
fixes this bug's double-click problem (by fixing comment #33's problem
#1).  You can see this by testing with the "Flash AS3 double click
test" (attachment 423877 [details]) in today's 1.9.2-branch nightly.

But it doesn't fix problem #2 --
nsPluginInstanceOwner::ProcessEvent(), when it synthesizes plugin
events, uses window coordinates (instead of screen coordinates as it
should).

This patch fixes problem #2.  It also fixes the test plugin -- so that
its getLastMouseX() and getLastMouseY() methods continue to work
properly when called by a mochitest.

A tryserver build will follow eventually.

Comment 35

[Steven Michaud [:smichaud] (Retired)]

Attachment: Trunk fix

Another tryserver build will follow eventually.

Comment 36

[Josh Aas]

Comment on attachment 429635 [details] [diff] [review]
Trunk fix

I think the code path in 1.9.1 led to the location being set to ::GetGlobalMouse in InitializeEventRecord. Bug 506304 changes that.

Anyway, patch looks good.

Comment 37

[Josh Aas]

Comment on attachment 429634 [details] [diff] [review]
1.9.2-branch fix

+#include "nsplugindefs.h"

This isn't for use in plugins. I don't want to give the wrong impression by using it in our test plugin even if it would technically work.

Comment 38

[Steven Michaud [:smichaud] (Retired)]

Attachment: 1.9.2-branch fix rev1 (stop using nsplugindefs.h)

> +#include "nsplugindefs.h"
>
> This isn't for use in plugins. I don't want to give the wrong
> impression by using it in our test plugin even if it would
> technically work.

Then the fix will have to be something like this.

Which raises the question -- Why does the branch npapi.h have
counterparts for nsplugindefs.h's nsPluginWindow (NPWindow),
nsPluginPortQD (NP_Port) and nsPluginPortCG (NP_CGContext), but not
for its nsPluginPort?

Comment 39

[Steven Michaud [:smichaud] (Retired)]

Here are tryserver builds for my trunk patch (from comment #35)

https://build.mozilla.org/tryserver-builds/[e-mail]-bugzilla542068/bugzilla542068-macosx.dmg

and my 1.9.2-branch patch (from comment #34)

https://build.mozilla.org/tryserver-builds/[e-mail]-bugzilla542068-192branch/bugzilla542068-192branch-macosx.dmg

(My rev1 1.9.2-branch patch compiles to the same binary code as the
old one.)

As I mentioned above, this bug's double-click problem is already fixed
by Josh's 1.9.2-branch patch for bug 518135 (which is in current
nightlies).  But there are a couple of bugs that might (more or less)
be dups of this one, and which might also need the fix my patch
provides -- bug 545687 and bug 549194.

Comment 40

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 429635 [details] [diff] [review]
Trunk fix

Landed on trunk:
http://hg.mozilla.org/mozilla-central/rev/b697781a04a8

Comment 41

[David Tristram]

Thanks for the fixes!  Can anyone tell me when this will be publicly available in a non-pre-release release?

Comment 42

[Josh Aas]

Comment on attachment 429748 [details] [diff] [review]
1.9.2-branch fix rev1 (stop using nsplugindefs.h)

You want NP_CGContext, which is the plugin port struct for Core Graphics plugins.

Comment 43

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #42)

Josh, you don't understand.

My trunk patch won't work on the 1.9.2 branch.  On the trunk
NPWindow.window is a NP_CGContext* (in CoreGraphics mode), but on the
1.9.2 branch it's an nsPluginPort structure, whose cgPort member is a
NP_CGContext*.

Take another look at the following, from comment #38:

> Which raises the question -- Why does the branch npapi.h have
> counterparts for nsplugindefs.h's nsPluginWindow (NPWindow),
> nsPluginPortQD (NP_Port) and nsPluginPortCG (NP_CGContext), but not
> for its nsPluginPort?

Comment 44

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #43)

Actually, my trunk patch (the relevant part of it) *does* work on the
1.9.2 branch -- I just tried it.

Though NPWindow.window has different definitions on the trunk and the
1.9.2 branch, they turn out to be binary-compatible for the purposes
of this patch -- nsPluginWindow.nsPluginPort.cgPort.window has the
same address as NPWindow.NP_CGContext.window.

New patch coming up.

It's a real pain this is so confusing :-(

Comment 45

[Josh Aas]

nsPluginPort is a union on Mac OS X. It's an NP_CGContext in Core Graphics mode.

Comment 47

[Steven Michaud [:smichaud] (Retired)]

Attachment: 1.9.2-branch fix rev2

Comment 48

[Josh Aas]

Comment on attachment 429772 [details] [diff] [review]
1.9.2-branch fix rev2

It's not a deficiency. The whole nsPluginPort thing was a confusing attempt at a helpful abstraction, npapi.h more clearly defines the structures used. This is why we don't have nsplugindefs.h in Gecko 1.9.3 any more.

Patch looks good but please drop the nsplugindefs comment. NPAPI plugins don't need to be aware of it. Nothing in there is a real part of NPAPI.

Comment 49

[Steven Michaud [:smichaud] (Retired)]

Attachment: 1.9.2-branch fix rev3 (drop comment)

> The whole nsPluginPort thing was a confusing attempt at a helpful
> abstraction, npapi.h more clearly defines the structures used.

I disagree ... but it's not worth making a fuss over.

Comment 50

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #41)

> Thanks for the fixes!

You're quite welcome.

> Can anyone tell me when this will be publicly available in a
> non-pre-release release?

I don't know, and won't be the one who makes the decision.  But I do
think the 1.9.2-branch patch should get into FF 3.6.2 (which on
current plans will be the next release).

Comment 51

[Johnny Stenback (:jst)]

(In reply to comment #41)
> Thanks for the fixes!  Can anyone tell me when this will be publicly available
> in a non-pre-release release?

Per the current predictions it's looking like this will be available in 3.6.2, which is likely to hit the masses at the very end of this month.

Comment 52

[Josh Aas]

Comment on attachment 429801 [details] [diff] [review]
1.9.2-branch fix rev3 (drop comment)

I should have asked this before you landed the trunk patch...

+    Rect globalBounds = {0};

Is this really the way to initialize a Rect? I'm having trouble finding good examples. It seems that if we're going to give it a default value we should use 'SetRect', otherwise we should not initialize it and check the error value of 'GetWindowBounds'.

Comment 53

[Steven Michaud [:smichaud] (Retired)]

> +    Rect globalBounds = {0};
>
> Is this really the way to initialize a Rect?

I don't see any problems with it.  And it doesn't trigger any
compiler warnings.

The definition of Rect is as follows (from MacTypes.h in the
CarbonCore framework under the CoreServices framework):

struct Rect {
  short top;
  short left;
  short bottom;
  short right;
};
typedef struct Rect Rect;

So it's not opaque or obfuscated.  I don't see any need to use
SetRect().

Comment 54

[Steven Michaud [:smichaud] (Retired)]

I suppose we could check the return value of GetWindowBounds(), but
what would we gain by that?

What should we do if it returns an error?

Comment 55

[Steven Michaud [:smichaud] (Retired)]

Here's what Apple has to say about the SetRect() function in its
QuickDraw Reference (under Description):

"This function is provided to help you shorten your program text. If
you want a more readable text, at the expense of source text length,
you can instead assign integers (or points) directly into the fields
of a Rect structure."

This makes it sound like just a convenience function.

Comment 56

[Josh Aas]

Drivers - we should take this on 1.9.2 soon.

Comment 57

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 429801 [details] [diff] [review]
1.9.2-branch fix rev3 (drop comment)

Is there any way to get that test automated?

Comment 58

[Steven Michaud [:smichaud] (Retired)]

> Is there any way to get that test automated?

No.  That would involve automating the Flash plugin.

Comment 59

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #58)

No, we can't automate the testing of this bug's STR (using the
testcase from comment #10).

But in a way this bug's patch already has an automated test --
test_plugin_mouse_coords.html (in layout/generic/test).

Comment 60

[Goffredo Marocchi]

This bug happens also on Google Maps' StreetView (Firefox 3.6, OSX 10.6.2, latest stable Flash plugin). The interesting thing is that once I make the StreetView view go full-screen with the provided button... double clicks work as expected. They just do not work when the StreetView frame is in its default state.

Comment 61

[Goffredo Marocchi]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

Comment 62

[Steven Michaud [:smichaud] (Retired)]

> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115
> Firefox/3.6

So you're using FF 3.6, which of course doesn't have Josh's patch for bug 518135 (which makes the double-click problem go away).

Comment 63

[Goffredo Marocchi]

Ok, so 3.6.1 will have this issue fixed then? When is it expected?
Thanks for the answer btw :).

Comment 64

[Steven Michaud [:smichaud] (Retired)]

The next release will be called FF 3.6.2.  I understand the release
target date is March 30th.

By the way, the StreetView problem is bug 537269.

Comment 65

[Benjamin Smedberg]

http://hg.mozilla.org/projects/firefox-lorentz/rev/ddbc08b3cfab

Comment 66

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 429801 [details] [diff] [review]
1.9.2-branch fix rev3 (drop comment)

a=beltzner for 1.9.2.4

Comment 67

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 429801 [details] [diff] [review]
1.9.2-branch fix rev3 (drop comment)

Landed on the 1.9.2 branch:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/396505dd8842

Comment 68

[Mike Beltzner [:beltzner, not reading bugmail]]

Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed

Comment 69

[Benjamin Smedberg]

Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430

Comment 70

[Al Billings [:abillings - ex-MoCo]]

Can this fix be tested by the testcase in comment 10 or will the fact that bug 518135 is fixed completely mask this for 1.9.2? That bug had a test plugin that only worked with 64-bit builds.

Comment 71

[Steven Michaud [:smichaud] (Retired)]

The specific problem reported here (and tested by the testcase from comment #10) *was* fixed by the patch for bug 518135.

My patch for this bug fixed another, related problem that the patch for bug 518135 didn't fix.  I think test_plugin_mouse_coords.html is a perfectly adequate test of my patch for this bug.

Comment 72

[Al Billings [:abillings - ex-MoCo]]

Verified for 1.9.2 by passing test_plugin_mouse_coords.html on OS X.