Combobox: the dropdown arrow is not clickable on IE

[AdrianVasiliu]

On IE 10 and 11, to open the dropdown the user cannot click on the dropdown arrow; however, clicking the combo element outside the arrow does open the dropdown.

Originally reported by @mythic2 in #382.

[AdrianVasiliu]

The dropdown arrow is created in CSS:

.d-combobox::after {
    content: "\25BC";
    pointer-events: none; /* allow clicks to pass through */
    ...
}

(in https://github.com/ibm-js/deliteful/blob/master/Combobox/themes/Combobox_template.less).

The trouble is that pointer-events: none; does the trick on Chrome and FF for allowing click events to pass through the arrow, but it is not effective on IE 10 and 11. I don't have yet a good solution for it.

[dmandrioli]

Additionally, the dropdown arrow should have a pointer cursor, not a text cursor.
To reproduce:
Run tests/functional/Combobox-prog.html
Move the mouse over the arrow of the combo with

id: "combo-single-autoFilter", selectionMode: "single", autoFilter: true

[AdrianVasiliu]

@dmandrioli

the dropdown arrow should have a pointer cursor, not a text cursor.

Browsers behave differently in terms of cursor. For instance, Chrome/Win7 shows a pointer cursor by default on a <input readonly>, while FF and IE11/Win7 show the text cursor for a readonly input... (I guess the rationale being that you can still select the text.)

It goes better with the pointer cursor set explicitely for input[readonly]. However, as you can see in
http://jsfiddle.net/adrian_vasiliu/n10h8ogq/ with pure HTML/CSS, for the read-write inputs (that is, our autoFilter: true case), setting the pointer cursor just on the arrow is not enough on either Chrome or FF (Win7). Differently than on IE11/Win7, I'd need to additionally set cursor: pointer on the input itself, even if it is an editable input, which is not a very good thing... Any hint?

[dmandrioli]

OK, maybe it should be designed differently. When you will implement the keyboard navigation of a combobox like <input type="search" value="Read-write input (search)">, I suppose you will have to allow the focus of the text area, the cross button and the arrow button.
I don't think it's possible to focus ::after or ::before elements and I wonder if the cross and the arrow buttons should not be tags positioned on top of the combobox.

[AdrianVasiliu]

@dmandrioli

maybe it should be designed differently. [...] I suppose you will have to allow the focus of the text area.

With the current design, the combo does get the key events, thus is able to forward them to the List, and, thanks to KeyNav.focusDescendants = false, navigating through list items will not give the focus to list items.

I wonder if the cross and the arrow buttons should not be tags positioned on top of the combobox.

If you refer to the relative z order between arrow and input, the arrow pseudo-element is already in a layer on top of the input (you can see it thanks to the background color in this modified version: http://jsfiddle.net/adrian_vasiliu/07mwpgbm/).
Also, even if I'd give up on use the ::after pseudo-element for the arrow, the use of a separate element for the arrow doesn't seem to solve the cursor problem: the cursor of the input still takes precedence over the one set for the arrow element. See the rough sketch in http://jsfiddle.net/adrian_vasiliu/sd11jknv/.

[dmandrioli]

OK, some more remarks:

• about the cursor

The cursor on the arrow is not correct because mouse is disabled by:

  /* allow clicks to pass through */
  pointer-events: none;

So maybe you can explicitly manage mouse events on the arrow and not rely on the pass through to have the correct cursor.

• about keyboard nav

  navigating through list items will not give the focus to list items.

In tests/functional/Combobox-prog.html, I tried to select, only with the keyboard, a country in the second combobox. List items seem to be focused when iterating on items using ARROWS? For me it seems correct.
However, SPACE does nothing and I'm not able to select an entry in the list.
Typing ENTER submit the form.

[AdrianVasiliu]

The cursor on the arrow is not correct because mouse is disabled by pointer-events: none;
So maybe you can explicitly manage mouse events on the arrow and not rely on the pass through to have the correct cursor.

Right, and moreover it seems I need anyway to not rely on the pass through because it doesn't work on IE. Now, this is a bit unfortunate, for 2 reasons:

• The events aren't managed by Combobox itself, but by its superclass delite/HasDropDown, which listens to pointerdown events on widget.buttonNode (which is the input element of the combo). But it should be doable, at the price of exposing as protected the private event handler of delite/HasDropDown.
• Unless I'm missing something, there's no way I could listen to events on a pseudo-element, so it would force to not use anymore the ::after for creating the dropdown arrow.

Anyway, despite the drawbacks, if no better solution will show up, I'll go in this direction.

I tried to select, only with the keyboard

Since you previously wrote "when you will implement the keyboard navigation", I thought you already know the keyboard navigation is not yet implemented. This will come next (#362). Anyway, so this is why it doesn't work...

[dmandrioli]

One more thought, if you remove pointer-events, you have the correct cursor and you can still listen for click events on the d-combobox? Or maybe using pointer-events have another benefit I miss?

[AdrianVasiliu]

One more thought, if you remove pointer-events, you have the correct cursor and you can still listen for click events on the d-combobox?

Oh, that does the trick indeed! Thanks!
More exactly, it can even keep listening for pointer events, not click events. Remains to make the optimal choice of cursor for the input itself (outside the arrow). My view of the best compromise:

• Use cursor: pointer for readonly input (autoFilter: false).
• Leave the text cursor for editable input (autoFilter: true).
  That is, the entire combo (input + arrow) has the pointer cursor in readonly mode, while in editable mode the editable area has the pointer cursor even though clicking it also opens the dropdown just as clicking the arrow. Would you (@dmandrioli) be okay with it?

Or maybe using pointer-events have another benefit I miss?

Well, that's something to ask for delite/HasDropDown, which is the one currently listening for pointer events for opening/closing the dropdown. But I guess a benefit is that it's an easy way to escape from the 300ms delay of click events.

[AdrianVasiliu]

that does the trick indeed

Hm, it does entirely the trick on Chrome and FF / Win7, but not on IE11/Win7... While the arrow does become clickable (which is great), the pointer cursor does not show up on the arrow on IE11 unless cursor: pointer is set on the input too, not only on the arrow. See http://jsfiddle.net/n10h8ogq/2/ .
In other words, the price for solving the cursor issue in IE11 would be to set the pointer cursor even for an editable input, which is not good...

[dmandrioli]

Too bad, it confirms my feeling that ::before and ::after pseudo classes are not consistent across browsers. It remains to try to use an actual DOM node for the arrow...or considering it's not worth it.

[AdrianVasiliu]

Too bad, it confirms my feeling that ::before and ::after pseudo classes are not consistent across browsers.

Well, as said above (#397 (comment)), browsers are inconsistent already for the cursor of a readonly input element, without any ::before or ::after into the picture.

It remains to try to use an actual DOM node for the arrow...or considering it's not worth it.

My preference would go towards keeping the pseudo-element for the arrow, while making a choice among a) enforcing pointer cursor for all inputs (including editable) and b) setting pointer cursor only on readonly inputs, thus not having pointer cursor on the arrow on IE. After all, a) might be not that bad, knowing that the pointer cursor is correctly conveying the information that you can click the input (not only the arrow), and once the dropdown opens you do get the text blinking caret as hint that you can type into it.

[dmandrioli]

My preference would go towards keeping the pseudo-element for the arrow, while making a choice among a) enforcing pointer cursor for all inputs (including editable) and b) setting pointer cursor only on readonly inputs, thus not having pointer cursor on the arrow on IE. After all, a) might be not that bad, knowing that the pointer cursor is correctly conveying the information that you can click the input (not only the arrow), and once the dropdown opens you do get the text blinking caret as hint that you can type into it.

Looks good enough and it won't break anything if you change the arrow implementation in the future.

[AdrianVasiliu]

Pushed in 69b213e. Besides fixing the non-clickable dropdown arrow in IE, it also sets the pointer cursor in such a way that it works in all desktop browsers.

[AdrianVasiliu]

And thanks @dmandrioli for your useful suggestions.