Latest of version of Chrome (55.X) breaks ComboBox

[rmaccracken]

The latest release of Chrome breaks the ability to open a ComboBox? using a mouse click.

To reproduce, go to the docs on ComboBox? and run the first demo. Clicking the arrow does not open the drop-down. It works if you use the keyboard.

After a bit of debugging, there seems to be a race condition. In _SearchMixin.js, the following line is executed: this._queryDeferHandle = this.defer(startQuery, this.searchDelay);

But before that defer executes startQuery, the closeDropDown method is called which aborts the query.

Please provide a fix ASAP as this is affecting existing customers who have upgraded to the latest Chrome.

[rmaccracken]

Sorry - looks like I may be mistaken. I was able to reproduce it with the 1.7 version of ComboBox?, but not the 1.10 version.

​https://dojotoolkit.org/reference-guide/1.7/dijit/form/ComboBox.html ​https://dojotoolkit.org/reference-guide/1.10/dijit/form/ComboBox.html

I am still having a problem in our software using 1.11.2, but I cannot point to a simple test case.

[rmaccracken]

This may be related to the following: ​https://bugs.dojotoolkit.org/ticket/18655 ​https://bugs.dojotoolkit.org/ticket/18645

[jroufa]

After updating my Chrome to Version 55.0.2883.75 (64-bit), I cannot reproduce this issue on either of the links from comment 1 or locally using version 1.11.2 or the latest 1.12.0-rc2. If you can provide us with a test case, I would be happy to review this issue further.

[rmaccracken]

We may have found the root of the problem. We are using the new flat theme, and in that case, the arrow element (one with classes "dijitReset dijitInputField dijitArrowButtonInner") that receives focus when the arrow is clicked actually has no size. Instead, there is a "::before" psuedo-element that shows the arrow.

When that arrow is clicked in Chrome, instead of that arrow getting the focus, instead the focus is actually going to the Toolbar that contains the ComboBox?.

One of our engineers has fixed this by changing the CSS of the arrow button so that it has size. We're not sure if this is the best fix (don't like hard-coding height and width), but seems to work.

Here are the changes to CSS we made:

.dijitComboBox .dijitButtonNode {
    position: relative;
}

.dijitArrowButtonInner {
    color: transparent;
    position: absolute;
    top: 0;
    right: 0;
    height: 24px !important;
    width: 22px;
}

Lastly, the height and width was made to include the margins around the arrow icon so that clicking on the whole arrow button will work rather than just the arrow icon itself.

So to sum up, I'm not sure if this is a flat-theme problem, a ComboBox? issue when it has a parent widget (we have cases where it has a parent Toolbar or a widget of our own that is derived from _Widget, _TemplatedMixin, _WidgetsInTemplateMixin), or both.

[bitranch]

We're having this same issue on sites running 1.11.2 (both ComboBox? and FilteringSelect?). The above css workaround doesn't fix the issue, although it does make the ComboBox? randomly work. Without the css changes, it fails 100% of the time.

[bitranch]

On further testing, we've discovered that "long" clicking the arrow (holding the down-click for a half to a full second) will always successfully open the select list. It appears that, for some reason, Chrome is treating a normal click as two click events.

[dylan]

Received some outreach from the Chrome team:

Hi Dylan.

We (in Google Chrome) recently got a bug with Dojo checkboxes that got exposed through Chrome 55 PointerEvents?.

In short, we see some double-handling of pointerdown and mousedown which seems to be messing up a checkbox state in Chrome when the checkbox is placed inside a title-pane.

We are not dojo experts, would appreciate if you can point us to someone in Dojo who can take a look at the repro. (We tried the #dojo IRC channel w/o any luck.)

Thanks in advance.

[mustaq]

Thanks dylan for forwarding our (Chrome) concern here. See the Chrome bug for a repro: crbug.com/676538

Re bitranch's comment 7 above: I think "treating a normal click as two click events" is caused through handling both pointerdown and mousedown. The recommended way to prevent such double-handling is to cancel (preventDefault) the pointerdown which makes Chrome to suppress mouse events until the next pointerup.

[dylan]

@bill, any chance you have time to look into this soon? We've received many reports of the issue, so it's a change we need to make and backport.

[mssskhalsa]

With Chrome 55.0.2883.87 on Windows 10 I cannot reproduce this issue at all.

Tested:

​https://dojotoolkit.org/reference-guide/1.7/dijit/form/ComboBox.html ​https://dojotoolkit.org/reference-guide/1.10/dijit/form/ComboBox.html ​http://download.dojotoolkit.org/release-1.11.2/dojo-release-1.11.2/themes/flat/tests/flat.html ​http://yiweima.github.io/flatdojo/

A reproducible test case is needed to debug this.

[dylan]

From what I can tell, this issue was fixed in Dojo 1.10.5 and newer releases as well.

See a revised JSFiddle at ​http://jsfiddle.net/dylan/k5agxn2g/1/ .