#17262 closed defect (fixed)
[regression] DropDown and Combo buttons do not close reliably in IE10 (1.9 only)
| Reported by: | vyiu | Owned by: | bill |
|---|---|---|---|
| Priority: | undecided | Milestone: | 1.9.2 |
| Component: | Dijit | Version: | 1.9.0 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
After clicking on a DropDown? Button or Combo Button to open the menu, clicking away or pressing Escape does not reliably close the dropdown. This is reproducible in the dijit Theme Tester, under "Basic Form Widgets."
The problem appears to be in _HasDropDown:221. From 1.8 to 1.9, it changed from triggering from the "mousedown" event to touch.press:
on(this._buttonNode, "mousedown", lang.hitch(this, "_onDropDownMouseDown")),
to:
on(this._buttonNode, touch.press, lang.hitch(this, "_onDropDownMouseDown")),
The routine touch.press attempts to unify the handling of mouse and touch events in IE10+ via MSPointerDown, but has unfortunate side effects. By reverting the line back to the 1.8 "mousedown" syntax, this bug goes away.
It might be helpful when debugging to dump the 'newStack' parameter to the console when focus._setStack is called to see the differences before and after the handler change.
Change History (11)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
| Milestone: | tbd → 1.9.2 |
|---|---|
| Owner: | set to bill |
| Status: | new → assigned |
| Summary: | DropDown and Combo buttons do not close reliably in IE10 (1.9 only) → [regression] DropDown and Combo buttons do not close reliably in IE10 (1.9 only) |
Good catch about the mouse problem... I can also reproduce that on test_Button.html on IE10 on Win8, where clicking a blank area of the screen won't close the drop down.
The reason is that on IE10, after opening the dropdown, neither the menu nor the button gets focus, so dijit/focus considers the stack of active widgets as []. So clicking a blank part of the screen is a no-op because dijit/focus thinks the stack of active widgets hasn't changed.
As you said, that started with the change in c60b357604303443a6099dc83aa66329ac4e7054 to (basically) listen to MSPointerDown rather than mousedown. I'm not sure why that makes a difference though. It isn't the e.preventDefault() in _onDropDownMouseDown().
Incidentally, Chrome is arguably "broken" too: it lists the active widgets as just the button, but not the menu. But that's enough to make the click close the menu.
As for pressing ESC, it still works assuming that you opened the drop down via keyboard. If you open the dropdown via the mouse, then the dropdown doesn't get focus, which is why the ESC key doesn't work. That's still arguably a bug but not high priority. Probably fallout from #11800.
comment:3 Changed 6 years ago by
PS: Oh, it is e.preventDefault(), but in the opposite way I was checking. preventDefault() on mousedown is harmless, but preventDefault() on MSPointerDown stops the button from getting focus.
comment:4 Changed 6 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:7 Changed 6 years ago by
Bill, something seems to be wrong with TimeTextBox?, too. Just go to http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html#. Select tab "Text Input Widgets". Open the TimeTextBox?'s drop down by clicking on the arrow button. Click somewhere else on the screen. The drop down is not (always) closed on IE10. It works nicely with FF. Can you reproduce this?
comment:8 Changed 6 years ago by
Hmm, that's odd, yes on IE10 I can reproduce on http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html but not on local and not on http://bill.dojotoolkit.org/git/dijit/themes/themeTester.html either.
I tried a release build via:
$ ./build.sh copyTests=true mini=false action=clean,release profile=standard releaseDir=../../../release optimize=shrinksafe
And that works too.
comment:9 Changed 6 years ago by
PS: Looks like archive.dojotoolkit.org is broken and contains old code. So, I think the problem in this ticket is indeed fixed.
To clarify, this bug happens only in IE10 with dojo 1.9. It does not happen with other browsers in 1.9, nor does it happen in dojo 1.8 with IE10.