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

VERIFIED FIXED in Firefox 40

Status

()

defect
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: jaybald, Assigned: mats, NeedInfo)

Tracking

(4 keywords)

40 Branch
mozilla43
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox40+ verified, firefox41+ verified, firefox42+ fixed, firefox43+ fixed, firefox-esr31 unaffected, firefox-esr38 unaffected, relnote-firefox 40+)

Details

Attachments

(5 attachments)

Reporter

Description

4 years ago
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

4 years ago
Posted file jquery.ibutton.js

Comment 2

4 years ago
Posted file 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?

Updated

4 years ago
Flags: needinfo?(jaybald)

Comment 3

4 years ago
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.
Keywords: regression, testcase

Comment 4

4 years ago
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

4 years ago
Reproduced on Ubuntu14.04 and Windows7 without e10s. 

[Tracking Requested - why for this release]: Regressed by  Bug 1153586
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Form Controls
Ever confirmed: true
Flags: needinfo?(mats)
Product: Firefox → Core
Summary: Version 40.0.2 has issue with jquery ibutton plugin → [Not e10s] Version 40.0.2 has issue with jquery ibutton plugin

Comment 6

4 years ago
(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.
Assignee

Comment 8

4 years ago
Posted file Testcase #2
I think this is the essence of what they do.
Assignee: nobody → mats
Flags: needinfo?(mats)
Assignee

Comment 9

4 years ago
Posted patch fixSplinter Review
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/mpalmgren@mozilla.com-8028062b728d

Also, please verify it doesn't break bug 1153586 or bug 1106824.
Flags: needinfo?(alice0775)
Assignee

Comment 10

4 years ago
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

4 years ago
(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/
> mpalmgren@mozilla.com-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
Flags: needinfo?(alice0775)

Comment 12

4 years ago
I forgot to mention, I tested the each cases with/without e10s.
Assignee

Comment 13

4 years ago
Thanks Alice, very much appreciated.
Assignee

Updated

4 years ago
Attachment #8648486 - Flags: review?(enndeakin)

Comment 14

4 years ago
Is it useful to add some tests to catch possible future regressions?
(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.

Updated

4 years ago
Duplicate of this bug: 1194316
Assignee

Comment 17

4 years ago
(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

4 years ago
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.
Assignee

Comment 19

4 years ago
> 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...
Assignee

Comment 20

4 years ago
Posted patch mochitestSplinter Review
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

Updated

4 years ago
Duplicate of this bug: 1195675
Assignee

Comment 22

4 years ago
(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.
Tracking for 42 and 43. This regression has been around since Firefox 37.

Updated

4 years ago
Duplicate of this bug: 1196486

Updated

4 years ago
Duplicate of this bug: 1196390

Updated

4 years ago
Attachment #8648486 - Flags: review?(enndeakin) → review+
Assignee

Comment 27

4 years ago
I skipped landing the mochitest since I think it might not be reliable enough.
Flags: in-testsuite?
Duplicate of this bug: 1197347
(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

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

Updated

4 years ago
Duplicate of this bug: 1197533
(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.
... along with another Firefox 40 site-compat issue: Bug 1194055.

Comment 34

4 years ago
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.
seems like you should request uplift to aurora and beta
Flags: needinfo?(mats)
Assignee

Comment 36

4 years ago
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
Flags: needinfo?(mats)
Attachment #8648486 - Flags: approval-mozilla-beta?
Attachment #8648486 - Flags: approval-mozilla-aurora?
Assignee

Comment 37

4 years ago
(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

4 years ago
(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 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
Flags: needinfo?(mats)
Attachment #8648486 - Flags: approval-mozilla-beta?
Attachment #8648486 - Flags: approval-mozilla-beta+
Attachment #8648486 - Flags: approval-mozilla-aurora?
Attachment #8648486 - Flags: approval-mozilla-aurora+
Assignee

Comment 41

4 years ago
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.
Flags: needinfo?(mats)
https://hg.mozilla.org/mozilla-central/rev/5e40a35a76cb
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
Flags: qe-verify+

Updated

4 years ago
Duplicate of this bug: 1197655

Comment 45

4 years ago
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?
(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.
Flags: needinfo?(mats)
Assignee

Comment 47

4 years ago
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
Flags: needinfo?(mats)
Attachment #8648486 - Flags: approval-mozilla-release?
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.
Attachment #8648486 - Flags: approval-mozilla-release? → approval-mozilla-release+
Tracked.
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)"
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.