Combobox: Several issues in IE11

[mythic2]

I know the widget is not ready for prime time yet, here are some experiences when using IE11. Note, that none of those happens while testing in Chrome:

• popup is not visible - combobox adds "fill" css class on the embedded list. When I check the list in developer tools, "flex: 1" is expanded, among others, to -ms-flex-preferred-size: 0px; flex-basis: 0px. If I add

.fill {
    -ms-flex-preferred-size: auto;
    flex-basis: auto;
}

to my local css file, popup renders correctly in both IE and Chrome.

• it is not possible to click on the dropdown arrow, one has to click on the text [EDITED: this point is transferred to Combobox: the dropdown arrow is not clickable on IE #397]
• when popup is shown a cursor starts blinking in the input box sugesting that one can edit text there. When user hits baskspace, it goes to previous page in internet explorer.

[AdrianVasiliu]

You're again right, I reproduce these three IE11-specific issues on my IE11/Win7. Honestly, on desktop, so far it was tested with latest Chrome and FF, and IE10 on Windows 7, not with IE11. We'll work on fixing it. Thanks again.

[mythic2]

No problem. Delite(ful) is going to make my life much easier one day (once you stop renaming everything :-)) so this is just way to show gratitude for your work!

[AdrianVasiliu]

:-)

(I hope we'll soon stabilize the API, for now we're still at 0.x version numbers...)

[AdrianVasiliu]

popup is not visible

Besides your suggested solution

.fill {
    -ms-flex-preferred-size: auto;
    flex-basis: auto;
}

(@dmandrioli, any lights about it?), in my testing it also started working if I give up on embedding the List inside a LinearLayout here:
https://github.com/ibm-js/deliteful/blob/0.4.0/ComboBox.js#L349-L355. LinearLayout was supposed to help but it appears to be harmful on IE in this dynamic dropdown case (wasn't able to reproduce on IE11 with other LinearLayout tests), and removing the LinearLayout doesn't seem to be harmful for FF or Chrome. This seems to hold with deliteful's current master as well as with @dmandrioli's changes currently in https://github.com/dmandrioli/deliteful/compare/listdirect-ci (soon to be merged).

I'll choose the final solution after seeing @dmandrioli feedback on your suggested addition, and after the merge of https://github.com/dmandrioli/deliteful/compare/listdirect-ci.

when popup is shown a cursor starts blinking in the input box sugesting that one can edit text there

If combo.autoFilter is true, this is expected since you actually can type into the input box, but indeed it's confusing when autoFilter is false since the input element is readonly. Now, this seems to be the "normal" behavior of IE10 and IE11 with <input readonly="readonly">, see for instance http://stackoverflow.com/questions/7917592/html-cursor-showing-in-readonly-input-text . Apparently, IE's rationale is that you can still select (then copy) text in a readonly element - but, to avoid confusion, the cursor shouldn't blink... Anyway. Not sure the workarounds suggested here and there are sane ones (such as onfocus="this.blur()").

When user hits baskspace, it goes to previous page in internet explorer.

Just to be sure, you only got that when combo.selectionMode is "multiple", right?

[dmandrioli]

any lights about it?

These two css properties are not used in LinearLayout and 'auto' is the default value, so I'm not surprised this is not a solution.

LinearLayout was supposed to help but it appears to be harmful on IE in this dynamic dropdown case

This CSS in Combobox.less .d-combobox-list > .d-list-container { position: relative; height: auto; width: auto; } is anticipating the merging of #341. This PR is on hold and won't be merged as-is. The branch listdirect is trying to avoid this CSS workaround and the need for a LinearLayout wrapper. But it's not ready for now.

You should remove the CSS workaround and remove the LinearLayout wrapper.
This should fix Combobox layout for 0.5 with the current List implementation. You will have the momentum scrolling issue on iOS (#270).

I continue to work on listdirect branch and will produce a PR when ready (Combobox tested, build running, etc)

[mythic2]

When user hits baskspace, it goes to previous page in internet explorer.

Just to be sure, you only got that when combo.selectionMode is "multiple", right?

Nope, that happens with the default selectionMode "single" as well.

[AdrianVasiliu]

@mythic2

Nope, that happens with the default selectionMode "single" as well.

Okay, I now understand it better. With my IE 11.0.9600.17358 / Win7, in samples/ComboBox.html of deliteful v. 0.4.0 I only get it on the combo with selectionMode = "multiple", not on the one with "single". But the thing which matters is whether the input element is readonly: it only hurts on readonly inputs, which in this sample is only the case for the "multiple" one.

I hope you can confirm that it only hurts with either autoFilter = false or selectionMode = "multiple" (which forces autoFilter at false, which means the input element is readonly). This is important because the workaround I know (prevent-defaulting the backspace keydown event) is only applicable for readonly inputs, otherwise it would forbid from deleting characters on editable inputs.

[AdrianVasiliu]

@dmandrioli

These two css properties [-ms-flex-preferred-size: auto; flex-basis: auto;] are not used in LinearLayout and 'auto' is the default value, so I'm not surprised this is not a solution.

Well, I'm not sure why you say it is not a solution. Not that it's necessarily the best solution, but as @mythic2 said, adding these settings to the fill CSS class does fix the issue in IE11. More exactly, according to my testing, adding just one (any) is enough. And a detail, http://msdn.microsoft.com/en-us/library/windows/apps/dn252001.aspx refers to auto as "initial value", not "default value" for flex-basis.

You should remove the CSS workaround and remove the LinearLayout wrapper.
This should fix Combobox layout for 0.5 with the current List implementation.

Yes, I already said that I found removing the LinearLayout wrapper being a workaround for the issue currently hurting IE11, even without removing the CSS workaround. Now, you say this CSS workaround "is anticipating the merging of #341" - its initial motivation was precisely to bring to the combo a (useful) bit of #341, as long as it isn't merged yet. So to be sure I can safely remove it, I'd need to test for non-regression on all browsers. Not sure why you think I should remove it (as long as #341 or a variation around it isn't merged yet), maybe there's a clear reason that I don't see?

You will have the momentum scrolling issue on iOS (#270).

Yes, unfortunately.

I continue to work on listdirect branch and will produce a PR when ready (Combobox tested, build running, etc)

Okay, thanks for the info.

[mythic2]

Yep, that seems to be correct: autoFilter = false is the root problem.

[AdrianVasiliu]

Good, thanks, so I do have an usable workaround in hands.

And a clarification: the browser still navigates to the previous page when pressing backspace while the focus is anywhere else on the page (say, on some non-editable text). This has nothing to do with the Combobox widget; if an app wants to prevent it it would apply the same kind of workaround at the level of the page itself. The purpose of the workaround (prevent-defaulting for readonly inputs) at the level of Combo is to avoid the misleading situation where the cursor blinks in a readonly input, thus motivating the user to possibly hit backspace...

[dmandrioli]

its initial motivation was precisely to bring to the combo a (useful) bit of #341, as long as it isn't merged yet.

I don't understand, It would have been useful if #341 had been merged?
Currently in master, the List takes its computed height. I'm trying to keep this behaviour in listdirect branch. So this a workaround for something that won't happen (the merge of #341) and that's why I think you must (if you prefer ;)) remove the CSS workaround. For the LinearLayout wrapper, it's probably useless unless you need to stack the List with something.

[AdrianVasiliu]

I don't understand, It would have been useful if #341 had been merged?

What I was saying is that it was initially thought useful (by me, possibly wrongly) as long as #341 is NOT merged yet. Okay, so you do see a logical reason to remove it. I'll go for the removal after testing for non-regression (as I said) on all supported browsers.

For the LinearLayout wrapper, it's probably useless unless you need to stack the List with something.

Again, what I found is even worse than that: not only it's useless but it's even harmful on IE 11. So, yes, I remove it. That said, I guess it normally should also work with the List inside a LinearLayout, maybe this will be the case once a fix for #341 will be on board.

[AdrianVasiliu]

5620cdc fixes two of the points (invisible dropdown, and backspace issue).
I don't close the issue for now because I don't have yet a good solution for "it is not possible to click on the dropdown arrow, one has to click on the text". This is related with pointer-events: none not being effective on IE for allowing the click events to pass through the CSS arrow.

[AdrianVasiliu]

2 out or 3 points being fixed, I transferred "it is not possible to click on the dropdown arrow, one has to click on the text" to a distinct issue: #397 and I close the present one.