Improved autocomplete control

[ebruchez]

See:

• http://silviomoreto.github.io/bootstrap-select/
• https://select2.org/

[avernet]

Select2 moved along quite nicely since the last time I looked at it.

[ebruchez]

+1 from user to fix issues

[ebruchez]

+1 from customer for rewrite

[ebruchez]

Bugs/requests (which we may or may not address exactly):

• down arrow behavior: "show the same suggestions it shows when clicked as the field is empty"
• scrolling closes list on Safari and IE (SO question)
• pagination/infinite scrolling

Note that pagination/infinite scrolling would be very useful also for Form Builder when listing a large number of controls. Right now, we have to limit list sizes. Although that might be closer from #2397.

[ebruchez]

See also #2397.

[eidstapdemo]

@ebruchez @avernet
Hi

I would like to enquire if you have resolved the following reported bug within Orbeon ?

scrolling closes list on Safari and IE (SO question)

Thanks

[avernet]

@eidstapdemo I imagine you're referring to this Stack Overflow question. I've been trying this just now with Safari, and am not seeing the autocomplete closing when scrolling in Safari (see below). At a more high level, the current implementation which uses the YUI autocomplete component is unlikely to be improved going forward. Instead, we'd like to rewrite the autocomplete control using a new JavaScript widget as its underlying implementation.

[eidstapdemo]

@avernet hi, thank you for your response. We are currently using Internet Explorer and the error occurs only when we try to click on the scrollbar arrows to scroll through the options. It does not occur when we use the mouse scroll wheel to scroll through the options. Will this issue be fixed ?

Thanks.

[avernet]

@eidstapdemo Got it about the issue happening on click while scrolling. And I imagine that I wasn't seeing that issue on Safari as scrolling on macOS is typically isn't done by clicking on the scrollbar, which often isn't even visible before scrolling. Are you using Orbeon Forms CE or Orbeon Forms PE?

• If Orbeon Forms CE, your best bet is to fix the issue on your side and submit a pull request, or to wait until a new control is implemented.
• If Orbeon Forms PE, could you contact us through your Basecamp for support?

[avernet]

I have done some prototyping using Chosen, and like the way the component looks and behaves. Unfortunately:

1. They see the component as replacement for dropdowns, and don't support the list of possible values being dynamically loaded during search (see Req: Including non-specified values harvesthq/chosen#5 and Fetch From Remote Data Source harvesthq/chosen#79). I've managed to dynamically update the list on search by updating the underlying option in the DOM, and dispatching a chosen:updated. I still have some flickering, but this is maybe something we can improve and make acceptable.
2. Accessibility is for us a requirement, and Chosen appears to be very weak in that respect (see Accessibility issues with Chosen harvesthq/chosen#264). There are a number PR (e.g. Accessible <select> elem solution harvesthq/chosen#2013, Adding accessibility to chosen: harvesthq/chosen#2047), but they haven't been merged, and I don't see any code being committed to the project since June of last year, which isn't encouraging.

So I'm going to switch back to Select2, which I find much less eye pleasing, even when using their Bootstrap 2 theme. But I'm not Jony Ive, so will need to get over that.

[avernet]

The Bootstrap CSS interferes, adding a margin to the left of the options, specifically because it adds a .orbeon ul { margin: 0 0 10px 25px }. I'm not sure we ever want this, but for now I'll just override this for this component.

[avernet]

• Update placeholder when the language changes

Also see this Select2 issue discussing how to update the placeholder.

[avernet]

I am encountering a frustrating issue where, in Scala.js, when passing the targetId to DocumentAPI.dispatchEvent, if use "gaga" everything works, but I refer to containerElem.id, then I get the following in the console.

This happens when the page is loaded, and that code doing the DocumentAPI.dispatchEvent doesn't even run at that point. Comparing the generate code in both cases, the following is added when I have a reference to containerElem.id, which looks like code to have access to the outer class. This code runs, and the else branch is taken.

  this$2$2.$$outer$2 = null;
  if ((this$2$1 === null)) {
    throw $m_sjsr_package$().unwrapJavaScriptException__jl_Throwable__O(null)
  } else {
    this$2$2.$$outer$2 = this$2$1
  };

This looks like a Scala.js bug to me, and the exception we get might hide the real problem. I've tried to upgrade from 0.6.27 (which we use) to 0.6.28 (the latest stable version), but this doesn't solve the issue.

[avernet]

I solved the issue mentioned in the previous message by changing the code to have less nested classes, so that reference to containerElem.id would be "simpler" for the compiler. (I take this as further evidence that the issue was caused by a bug in Scala.js.)

[avernet]

• Document that the autocomplete is deprecated since 2019.1.