1194733 - [Not e10s] Version 40.0.2 has issue with jquery ibutton plugin

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Jay]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.155 Safari/537.36

Steps to reproduce:

Nothing, firefox updated and now has issues with a plugin.

1. Download plugin at bottom of page:  http://www.givainc.com/labs/ibutton_jquery_plugin.cfm
2. Add a select box with values anywhere on page.
3. Try to select an item in the select box.  It will not select


Actual results:

When trying to select an option with a mouse in a select box the item will no longer select.  This worked in every previous version I had and works with every other browser.  Using the keyboard works fine.


Expected results:

The item should have selected.

Comment 1

[Loic]

Attachment: jquery.ibutton.js

Comment 2

[Loic]

Attachment: testcase.html

I attached a reduced testase.

The entries of the <select> cannot be selected with the mouse if jQuery 1.6.2 is used, but with higher versions like 1.11.3 or 2.1.4, it works.

Which version of jQuery do you use on your website?

Comment 3

[Loic]

I don't know if it's a valid regression in FF40 or an old bug in some outdated jQuery libs highlighted by FF40, but here is the regression range:

good=2015-04-22
bad=2015-04-23
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=946ac85af8f4&tochange=0b202671c9e2

The funny thing is this regression doesn't appear in e10s mode.

Comment 4

[Alice0775 White]

Regression pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=863f3575521b&tochange=d49f149a7c76

Regressed by: 11df38318e9c	Mats Palmgren — Bug 1153586 - Prevent the same BUTTON_DOWN event from opening the dropdown menu again on platforms that don't consume the event. r=enndeakin

Comment 5

[Alice0775 White]

Reproduced on Ubuntu14.04 and Windows7 without e10s. 

[Tracking Requested - why for this release]: Regressed by  Bug 1153586

Comment 6

[Alice0775 White]

(In reply to Loic from comment #2)
> Created attachment 8648423 [details]
> testcase.html
> 
> I attached a reduced testase.
> 
> The entries of the <select> cannot be selected with the mouse if jQuery
> 1.6.2 is used, but with higher versions like 1.11.3 or 2.1.4, it works.
> 

jquery.ibutton.js seems incompatible with such higher version jQuery.

Comment 7

[Kohei Yoshino]

https://developer.mozilla.org/en-US/Firefox/Releases/40/Site_Compatibility#HTML

Comment 8

[Mats Palmgren (inactive)]

Attachment: Testcase #2

I think this is the essence of what they do.

Comment 9

[Mats Palmgren (inactive)]

Attachment: fix

This fixes it for me on Linux.
Alice, can you please test it on Windows when the Try builds are ready?
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8028062b728d

Also, please verify it doesn't break bug 1153586 or bug 1106824.

Comment 10

[Mats Palmgren (inactive)]

BTW, the exact circumstance for the bug to occur is that event.preventDefault()
was called in a "mouseup" event handler on a <select> element or any of its ancestors.

Comment 11

[Alice0775 White]

(In reply to Mats Palmgren (:mats) from comment #9)
> Created attachment 8648486 [details] [diff] [review]
> fix
> 
> This fixes it for me on Linux.
> Alice, can you please test it on Windows when the Try builds are ready?
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/
> [e-mail]-8028062b728d
> 
> Also, please verify it doesn't break bug 1153586 or bug 1106824.

The try build fixes the problem.
And I verified that The try build did not break bug 1153586 and bug 1106824.

https://hg.mozilla.org/try/rev/8028062b728d95929e8c854626e4c4c926a1371f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0 ID:20150816055013

Comment 12

[Alice0775 White]

I forgot to mention, I tested the each cases with/without e10s.

Comment 13

[Mats Palmgren (inactive)]

Thanks Alice, very much appreciated.

Comment 14

[Loic]

Is it useful to add some tests to catch possible future regressions?

Comment 15

[Kohei Yoshino]

(In reply to Mats Palmgren (:mats) from comment #10)
> BTW, the exact circumstance for the bug to occur is that
> event.preventDefault()
> was called in a "mouseup" event handler on a <select> element or any of its
> ancestors.

Thanks, added the details to the site compat doc.

Comment 17

[Mats Palmgren (inactive)]

(In reply to Loic from comment #14)
> Is it useful to add some tests to catch possible future regressions?

I would have if I knew how.  None of the functions in SimpleTest/EventUtils.js
is able to honor the event capturing that the combobox drop-down menu does.
That is, they all take a target element as input and that's the element that
will receive the event even if said element is actually under an open
drop-down menu at the given coordinate.

I'd be happy to write a test if someone can show me how to do it.

Comment 18

[Neil Deakin]

Which special event capturing?

Is there something that happens at the widget layer that need to happen for this bug to be tested? You could also use nsDOMWindowUtils::SendNativeMouseEvent if needed.

Comment 19

[Mats Palmgren (inactive)]

> Is there something that happens at the widget layer that need to happen for this bug to be tested?

Yes, and AFAICT, all the functions in EventUtils.js bypass that.

> could also use nsDOMWindowUtils::SendNativeMouseEvent if needed.

I had forgotten about that function.  I'll try that instead...

Comment 20

[Mats Palmgren (inactive)]

Attachment: mochitest

nsDOMWindowUtils::SendNativeMouseEvent doesn't seem to be implemented
on Linux.  On OSX it appears we're using a native widget for the combobox
drop-down menu that is transparent to SendNativeMouseEvent, so this test
only really works on Windows.  And even there it's seems a bit fragile
since it's relying on subtle timing issues with the native event delivery
of Windows.  The test has some setTimeouts sprinkled to make it more
robust, but it still fails about once in ~50 runs in a local debug build.
I'm not sure if that's good enough to land.  The results might be different
on our test machines of course, for better or worse.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=573d29f569c5

Comment 22

[Mats Palmgren (inactive)]

(In reply to Mats Palmgren (:mats) from comment #20)
> On OSX it appears we're using a native widget for the combobox
> drop-down menu...

I should note for the record that this bug does not occur on OSX.
Presumably for that reason.

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 42 and 43. This regression has been around since Firefox 37.

Comment 26

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5e40a35a76cb

Comment 27

[Mats Palmgren (inactive)]

I skipped landing the mochitest since I think it might not be reliable enough.

Comment 29

[Daniel Holbert [:dholbert]]

(In reply to Liz Henry (:lizzard) from comment #23)
> Tracking for 42 and 43. This regression has been around since Firefox 37.

I don't think that's correct, about Firefox 37. This has only been around since Firefox 40 (current release), as shown by the target-milestone on the regressing bug (bug 1153586).

(I'm guessing you accidentally looked at the "Version" on bug 1153586, i.e. the version of Firefox that was in use by the reporter of *that* bug when it was filed.)

I'm bringing this up in case this affects the calculus of "should we backport this all the way to Firefox 41 [current beta]". (I think we should.)

Comment 30

[Konstantin Svist]

second! Only started after upgrade to 40 -- and I would vote that the fix should get backported to 40 if at all possible...

Comment 32

[Kohei Yoshino]

(In reply to Liz Henry (:lizzard) from comment #23)
> Tracking for 42 and 43. This regression has been around since Firefox 37.

No, since Firefox 40, as far as I read the status of Bug 1153586. Given 6 duplicates, this should be solved in 40.0.3 or 41.

Comment 33

[Kohei Yoshino]

... along with another Firefox 40 site-compat issue: Bug 1194055.

Comment 34

[Michael Ball]

I have a site that currently has exactly the same error but is not using a Jquery ibutton.
https://bugzilla.mozilla.org/show_bug.cgi?id=1197533
You can see an example of the bug here using Windows 7.
www.craftanddesign.net/test

The code for a drop down menu which you can see here:
https://www.craftanddesign.net/js/mm_menu/mm_menu_01nov12_mod.js
appears to be the cause of the problem in Firefox 40.

I notice that there is a patch available as a download to this thread, but I am unclear how to use it. Can anyone offer some advice on how to implement this?
Your help would be greatly appreciated.

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

seems like you should request uplift to aurora and beta

Comment 36

[Mats Palmgren (inactive)]

Comment on attachment 8648486 [details] [diff] [review]
fix

Approval Request Comment
[Feature/regressing bug #]:1153586
[User impact if declined]: can't select value in combobox controls using the mouse on some sites
[Describe test coverage new/current, TreeHerder]:none
[Risks and why]: low risk, return to previous behavior
[String/UUID change made/needed]:  none

Comment 37

[Mats Palmgren (inactive)]

(In reply to Michael Ball from comment #34)
> I have a site that currently has exactly the same error but is not using a
> Jquery ibutton.

See comment 10 - the workaround is to avoid calling event.preventDefault()
in a "mouseup" event handler.

Comment 38

[Michael Ball]

(In reply to Mats Palmgren (:mats) from comment #37)
> (In reply to Michael Ball from comment #34)
> > I have a site that currently has exactly the same error but is not using a
> > Jquery ibutton.
> 
> See comment 10 - the workaround is to avoid calling event.preventDefault()
> in a "mouseup" event handler.

Mats - Thank You!

Comment 39

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8648486 [details] [diff] [review]
fix

Taking this to fix this regression. 

Mats, do you think this is safe enough (and important enough) to be part of a potential 40 dot release? thanks

Comment 40

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/f973a86d54b1

Comment 41

[Mats Palmgren (inactive)]

It should be very safe since it simply reverts the part that caused the problem.

If it's important enough depends on how widespread it is, which I don't know.
(And you can still use the keyboard to avoid the problem although many users
might not realize that).  There are a few duplicates though, so I think I'm in
favor of taking it if you're doing a 40.0.3 anyway for other reasons.

Comment 42

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/6e7fa796c61c

Comment 43

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5e40a35a76cb

Comment 45

[Miro Trifonov]

When the problem is going to be solved? It has been a week since I reported a problem with the drop-down menu. When the new updated version will come out? Note - in the developers version of Firefox it works ok, but not in the mainstream one, how can that be?

Comment 46

[Sylvestre Ledru [:Sylvestre]]

(In reply to Miro Trifonov from comment #45)
> When the problem is going to be solved? 
Maybe this week.
> Note - in the developers version of Firefox it works ok, but not in the
> mainstream one, how can that be?
This is the nature of the development model used by Firefox... Fixed lands in mozilla-central first, get uplifted to mozilla-aurora, mozilla-beta and mozilla-release.

Mats, could you fill the uplift request to release?
Thanks. I will probably take it.

Comment 47

[Mats Palmgren (inactive)]

Comment on attachment 8648486 [details] [diff] [review]
fix

Approval Request Comment
[Feature/regressing bug #]:1153586
[User impact if declined]: can't select value in combobox controls using the mouse on some sites
[Describe test coverage new/current, TreeHerder]:none
[Risks and why]: low risk, return to previous behavior
[String/UUID change made/needed]:  none

Comment 48

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8648486 [details] [diff] [review]
fix

Thanks. The number of duplicate is a good sign that we want to take it in the dot release. Especially if it is safe.

Comment 49

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-release/rev/686af2679861

Comment 50

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked.

Comment 51

[Sylvestre Ledru [:Sylvestre]]

Added to the release notes. A better wording would be appreciated
Current:
"On some sites, the selection in a select combox box using the mouse could be broken (1194733)"

Comment 52

[Andrei Vaida [:avaida]]

Reproduced the issue on an affected build-- Firefox 40.0.2 (20150812163655), using the testcase posted by Loic.

This is verified fixed on Firefox 40.0.3 (20150826023504) and 41.0b4 (20150824144923), using Windows 10 Pro x64 (10525) and Ubuntu 14.04 (x86). I've also confirmed that this fix did not break Bug 1153586 and Bug 1106824.