In my project, i can't open dropdown menu by spacebar in firefox.
steps:
expected result: the menu could be shown when press spacebar
actual result: the menu not open correct.
After checked the demo in bootstrap(Dropup example, the attached file), i find the same issue also happen.
Do you know this issue? or is there any method to resolve it?
Thanks a lot.

What version of Bootstrap are you using?
The version is 3.3.6
Br,
Robby
From: Chris Rebert [mailto:[email protected]]
Sent: Thursday, July 14, 2016 11:45 PM
To: twbs/bootstrap [email protected]
Cc: Lian, Jianxiao (Nokia - CN/Hangzhou) jianxiao.[email protected]; Author [email protected]
Subject: Re: [twbs/bootstrap] Dropdown not work correct in Firefox (#20303)
What version of Bootstrap are you using?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/twbs/bootstrap/issues/20303#issuecomment-232703859, or mute the threadhttps://github.com/notifications/unsubscribe/ATgkMRlEx4Vs6g-oqldRO4EpMzO-DJ0nks5qVlmFgaJpZM4JMSTL.
Here's a reduced test case.
http://output.jsbin.com/poyotudara/
In FF, I do see the Bootstrap dropdown open, then quickly close when pressing spacebar. So I can confirm that behavior. However, spacebar doesn't appear to open the select box in FF.
This is really probably more of @patrickhlauke's wheelhouse, though.
Confirmed on OS X Firefox, so this isn't platform-specific.
spacebar doesn't appear to open the select box in FF.
FF doesn't do that for vanilla <select>s, so unsurprising.
looking at the behavior of the dropdown, it seems that in FF it's expanded/opened on the keydown, but then closes on the keyup (so if you press SPACE and keep the key down, it remains open...and focus is then moved to the first item; but if you release the key too quickly it closes). worth looking at whatever behavior is happening there, what key events are hooked into, etc (may be missing a preventDefault somewhere too, perhaps)
Yes, i also see the behavior about press SPACE but not release, then it will open.
I just find there are two events will happen when press SPACE, including a 'click' event, and only one event happen in IE and Chrome. but i do not why.
I find a work around method, that is return false for key down&up event, then it will open when press SPACE. but i do not think it is a good solution, so we not use this solution.
Finally, we also feel it is related with FF. So we announce this existed issue and will not fix it.
Thanks for all your response.
I've found some interesting clues that may lead to a resolution of this issue. If I am off in any of my analysis please chime in; I'd like to properly diagnose and attempt a PR.
First, let's look at the handlers placed on .dropdown elements:
.on('click.bs.dropdown.data-api', clearMenus)
.on('click.bs.dropdown.data-api', '.dropdown form', function (e) { e.stopPropagation() })
.on('click.bs.dropdown.data-api', toggle, Dropdown.prototype.toggle)
.on('keydown.bs.dropdown.data-api', toggle, Dropdown.prototype.keydown)
.on('keydown.bs.dropdown.data-api', '.dropdown-menu', Dropdown.prototype.keydown)
It's important to note that when a user highlights the <button> element by tabbing into it, when the user presses either the ENTER or SPACE keys, the browser is automatically going to initiate a click event on the highlighted <button> element, separate from the delegated keydown events. And, inside of the Dropdown.prototype.keydown method we're invoking above, we're going to trigger another click event in this case by using $this.trigger('click')
So, why does this work in Chrome and not in Firefox? I decided to console.log(e) in Dropdown.prototype.toggle and this is what I found:
If you comment out the .on('keydown... delegations, and try the TAB, SPACE sequence in both Chrome and Firefox, the browser is invoking it's synthetic click event, which yields the desired results in both browsers (and mobile!) as the .on('click... events are still firing as a result or the user clicking SPACE in the highlighted <button> element. Chrome and Firefox both log an event with a populated originalEvent attribute.
If you leave the event delegations as is, you will see that Chrome only logs one event, which is the organically created "click" event in our event delegations (Looking in to how Chrome filters the events here). Firefox, however, logs two events. The organically created "click" event from our delegation, and the synthetic event it's creating. One interesting thing to note is that Firefox's synthetic event contains a timestamp attribute with the value of 0. Seemingly related to this 12 year old bug in Firefox.
So, a couple solutions come to mind:
1) Remove the keydown delegations all together. The intended results are yielded on mobile Chrome dev tools, Chrome and Firefox. Further testing needed.
2) In the Dropdown.prototype.toggle method, replace clearMenus() with if(e.timeStamp > 0) clearMenus() so as to ignore Firefox's synthetic element.
Any thoughts on this? I'm going to continue testing in the meantime... Thanks!
The inconsistent dropdown behavior in Firefox is related to a bug that's impacting keydown
When using keydown to capture events in Firefox, preventDefault is not behaving as one would expect. After keydown fires, a subsequent and unwanted keypress event fires despite the preventDefault which is why the dropdown opens, then closes immediately.
Per these docs from 2014 the bug/behavior should have been fixed:
Starting with Gecko 25, a call of preventDefault() of keydown event prevents to dispatch following keypress event. This is valid behavior for D3E spec and the other major web browsers behave so. On the other hand, Gecko 24 or earlier dispatched keypress event even if preventDefault() of preceding keydown event is called. Although the keypress event's defaultPrevented attribute was true in this case.
A potential modification to consider would be to immediately return from the Dropdown.prototype.keydown method if the space key is hit. The subsequent keypress would still fire and initiate the click event on the dropdown, should we change this line:
if (!/(38|40|27|32)/.test(e.which) || /input|textarea/i.test(e.target.tagName)) return
to this:
if (!/(38|40|27)/.test(e.which) || /input|textarea/i.test(e.target.tagName)) return
This seems to be a very light weight solution to this problem - @patrickhlauke any thoughts on this?
Bootstrap 3 is no longer being officially developed or supported.
All work has moved onto our next major release, v4. As such, this issue or pull request is being closed as a "won't fix." For additional help and support, we recommend utilizing our community resources. Thanks for your understanding, and see you on the other side of v4!
<3,
@mdo and team
Thanks @mdo . Please could you try to address this issue on v4?
I have just tested v4 and the bug persists. Thanks
@maufarinelli Feel free to create a new issue specific to v4 if there's not an open one already.
Most helpful comment
@maufarinelli Feel free to create a new issue specific to v4 if there's not an open one already.