storeSelection/restoreSelection for dialogs about hallo HOT 5 CLOSED

Fixed by ea0084c

from hallo.

This seems to have been reintroduced after the jQuery.browser fix in 1.0.2, or is it just me? I cannot get the new one to insert links anymore — the selection is immediately lost when the dialog is opened, and ultimately adding the link does not succeed.

from hallo.

Okay, it's pretty funky. After a boatload of headscratching, trying to pinpoint where the issue lay, and also trying to use the rangy save and restore module instead of the internal Hallo logic, I finally discovered that it's some kind of synchronicity issue.

Wrapping the selection restore statement and the create link statement in a settimeout call with just a very small delay, like 100ms, and voilà! Everything works properly.

This is pretty far from what anyone would call a fix, though, and I'm guessing the problem would surface elsewhere, too, unless the real issue is addressed. I'm just not too into the whole codebase to give an educated guess as to what may be causing this.

This is in Chrome, btw., and I just gave it a test run in Firefox. Here, no timeout hack is needed — it just works.

I experienced the behavior occasionally with the previous revision in Chrome, but it only happened with specific editables, and not consistently with those either. That's not to say that any change in the new revision may have caused it, because I've also updated other libraries since then.

Perhaps this is a webkit bug introduced by some kind of aggressive JS optimizations?

from hallo.

Specifically, and this is JS, sorry — still don't really know Coffee Scripts:

      if (widget.lastSelection.startContainer.parentNode.href === void 0) {
        setTimeout(function () {
          widget.options.editable.restoreSelection(widget.lastSelection);
          document.execCommand("createLink", null, link);
        }, 100);
      } else {

The interesting thing here is that it's the restoreSelection that must be delayed. The first call (made before these lines of code) isn't successful.

from hallo.

Okay, some further details. Thinking synchronicity issues, I browsed through the Rangy code and the Hallo code, and AFAICT no asynchronus code is being executed in restoring the selection, nor in the surrounding code.

What I've discovered is that Chrome will fail to restore the selection so long as the jQuery UI modal is open. This is true for the Hallo selection restore logic as well as for the Rangy one (saveSelection() / restoreSelection()). If I set a timeout on the selection restoriation and link insertion of, say, 2 seconds, and a timeout on the closing of the modal of, say, 4 seconds, the operation will still fail. (But still succeed in Firefox (and you can see the selection reappearing at 2 seconds in)).

If I don't use timeout hacks at all, but instead close the modal immediately after reading the value of the URL input field, everything works as expected.

I'm not sure what the issue is, but it's clear to me that the presence of the modal prevents the selection restoration from succeeding. I'm thinking it's a Rangy or Chrome issue rather than a Hallo one, though.

In either event — the quick fix is to close the modal as soon as it's no longer needed and before doing DOM modifications of any kind. Perhaps also for modals other than the link module, not sure :)

Either way, illustrated: DanielSmedegaardBuus@6fcc4d1

from hallo.