Opened 3 years ago

Closed 2 years ago

#18932 closed defect (fixed)

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

Reported by: rmaccracken Owned by:
Priority: blocker Milestone: 1.10.5
Component: Dijit - Form Version: 1.11.2
Keywords: Cc:
Blocked By: Blocking:

Description

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.

Change History (14)

comment:1 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by dylan

Milestone: tbd1.12.1

comment:6 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by 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.

comment:9 Changed 3 years ago by dylan

Milestone: 1.12.11.12.2

comment:10 Changed 3 years ago by 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.

comment:11 Changed 3 years ago by dylan

Priority: undecidedblocker

@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.

comment:13 Changed 3 years ago by 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/ .

comment:14 Changed 2 years ago by dylan

Milestone: 1.12.21.10.5
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.