1218390 - html select not triggered ( not open ) on click in firefox 41.0.2

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[Daniel]

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

Steps to reproduce:

On my html ( running on tomcat web server as jsp ) i have a drop down box.

I am clicking on the box arrow trying to open it to select one of the options.


Actual results:

Nothing happened.


Expected results:

The drop down should open so the user will be able to select one of the options.

My Remarks:
1. My FF version is 41.02.
2. This is an existing code that used to work fine until FF new version.

Comment 1

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Please provide a simple html page as reduced test case which allows developers to reproduce the issue.

Comment 2

[Gingerbread Man]

(In reply to Daniel from comment #0)
> 1. My FF version is 41.02.
> 2. This is an existing code that used to work fine until FF new version.

Do you literally mean it used to work in 41.0 but stopped working in 41.0.2? The only change in that version is a security patch that almost certainly didn't touch code related to this.

Comment 3

[Daniel]

Hi

No , the last tested version was 39.

Thanks

Comment 4

[Boris Zbarsky [:bzbarsky]]

This bug really does need a testcase or a link to the page showing the problem.  It doesn't need to be reduced, but it needs to be HTML + CSS + script that actually shows the bug.  Without that it's hard to tell what's going on.  For example, there could well be script on the page that does browser sniffing, detects Firefox 41 as "Firefox 4" and does something weird as a result...

Comment 5

[Daniel]

Here is the link : https://62.219.46.199:9443/BioWeb

You gets a login screen : user = admin , pass = 123 ( first time you need to allow popups )
The landing page contains a list of cases on the left side. choose A-13-003335 by selecting it.
Click the gallery tab on the top , now the gallery page is open.

Try to click any drop down box to open it. --> no result.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Here is the link : https://62.219.46.199:9443/BioWeb

Thanks, that's very helpful.

So the dropdown boxes we're talking about here are the "Slide", "Left", "Right" ones near the top of the gallery page, right?

I can confirm that they're not opening for me in a 41 build, or a devedition build (43) but they work correctly in a nightly (44).

I tried some nightlies, and the problem got fixed in this checkin range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=68718290640b0ca195344fa5cc4c55fbc260e19e&tochange=9ed17db42e3e46f1c712e4dffd62d54e915e0fac by this commit: http://hg.mozilla.org/mozilla-central/rev/24515d221f0a

And indeed if in a nightly I toggle the "dom.select_events.enabled" preference to false the problem reappears.

Nothing in that changeset was jumping out at me, so I took a more careful look at what's going on with the page.  What happens is that the default action of the mousedown event is prevented when clicking on those <select>s.  So the <select> doesn't open, since opening it is the default mousedown action.

And the default action is prevented because there is an onmousedown handler that returns false.  This handler is on the document in this case.  That handler comes from this code on line 5482 of classify1.js:

      document.onmousedown=new Function ("return false");

and the full context there is:

    if (typeof document.onselectstart!="undefined")
    {
      document.onselectstart=new Function ("return false");
    }
    else
    {
      document.onmousedown=new Function ("return false");
      document.onmouseup=new Function ("return true");
    }

OK, so that explains why the changes for bug 571294 change the behavior here; after those changes, document.onselectstart is defined (in nightly only) and hence this code that nerfs mousedown is never reached.

So why did this use to work in 39?  I just checked, and in 39 this testcase:

  data:text/html,<script>document.onmousedown = function() { return false; }</script><select><option>a<option>b

does not open the select when it's clicked.  But this one, more closely matching the page:

  data:text/html,<script>document.onmousedown = function() { return false; }</script><select onmousedown="this.focus()"><option>a<option>b

does open the select in 39, but not in 40.

Looks like what changed here is the patch for bug 1153586 (at a guess that's the relevant change; I haven't verified) made nsListEventListener::HandleEvent actually check the "is default prevented?" flag on the event.  Before that we'd open the dropdown even if default was prevented, as long as the <select> was focused, as you can tell in my first data: testcase if you tab to the <select> before clicking on it.

So where does that leave us?  Our new behavior in terms of handling mousedown is definitely more correct.  I just checked, and both Safari and Chrome handle my two data: testcases like we do: they don't open the dropdown.  The difference is that they ship onselectstart, so the page doesn't change document.onmousedown for them.

So it looks to me like the page has a bug if onselectstart is not implemented: it unconditionally kills off mousedown events.  Then it worked around its bug by relying on another bug: it focuses the <select> on mousedown, which used to cause us to make it drop down.  We fixed the bug it was using for its workaround in bug 1153586, so now we're following the spec but the page is back to being broken.

As far as I can tell we're not doing anything incorrectly here (except for not yet implementing onselectstart, of course).  The page should probably be checking the event target in the mousedown handler on document and not returning false if the target is <select>...