Select link from autocomplete list using keyboard arrows and return fails in firefox and chrome

Hi ryanrain.
I've just tested this on WinXP Firefox and it works as expected.
I don't own a mac.
Could somebody else confirm this bug?

Same here with Chrome on W7. When typing ie. 'Ro' an autocomplete list appears. By pressing the [ARROW DOWN] key I select one of the suggestions 'Rotterdam' and hit [ENTER]. Now the form is being submitted and the modal window closes. When re-editing the link it's new value is 'Ro', the Link type is URL and the selected protocol is <other>.

Mayby the JS event should be canceled when pressing enter when the autocomplete list is in the DOM?

Yeah I have this problem in both FireFox and Chrome.

Since you're just using the Drupal autocomplete, I wouldn't think this should be a problem. For whatever reason, when clicking enter when the focus is on the auto complete div, the link dialog thinks you want to close it out. I suspect that CKEditor has a click handler on the link dialog for enter keys. I searched the CKEditor JS files for the keycode "13" (for the enter key) but came up short.

Okay, spent a few hours on this (many more than I would have liked to).

I believe the problem is that both autocomplete.js (Drupal) and CKEditor attach "keyup" events to the autocomplete field, and CKEditor's runs first. They listen for, among other things, the "enter" keyup.

autocomplete.js will close out the dialog and assume the user wants to select whatever element was currently selected at the time, and it will insert the appropriate value into the input field.

CKEditor will assume you want to close out the entire link dialog. It does this by attaching that keyup event listener to every text field in the dialog.

The CKEditor code that attaches its keyup event listener runs before this module's code that initializes the autocomplete function. Since browsers execute event listeners in the order they are attached, CKEditor closes out the dialog and does it's thing with whatever is currently in the input field. When autocomplete.js's listener runs to insert the proper data into the textfield, it's already too late.

I'm not quite sure on the solution yet. I can't find any reasonable ways to change the order of event listeners on an element, and don't think there are any opportunities to have the autocomplete code execute before the CKEditor code. I think you could do this if all the listeners were managed in jQuery, but only the autocomplete.js one is added via jQuery, so it has no control over the other event listeners.

I also posted in the CKEditor forums: http://ckeditor.com/forums/CKEditor/Need-to-attach-event-listener-before...

All right, I was able to reproduce this bug with CKEditor 4.3.
Actually, it doesn't happen with CKEditor 3.x.

So it looks like a regression bug of CKEditor itself.

Having the same issue on CKeditor library 4.2.3 with wysiwyg module.

A workaround from this module's perspective could be to use a custom autocomplete.js (I think Drupal makes this possible) in which the event for the return key is not keyup but keydown.

The attached patch overwrites the default drupal autocomplete behavior. It solves the above problem.

I tested this in a configuration where a plain autocomplete (entityreference) field widget was on the same page as the ckeditor and the plain autocomplete field widget seemed to work fine too.

Actually, this overwrite could be performed from any custom module. Still, I think the best place would be in this module to ensure that the overwriting occurs only when needed.

Just a bit of indenting cleanup.

This would break other autocomplete implementations that are executed after CKEditor is loaded, wouldn't it? Perhaps that doesn't happen ever

I do not know what this change exactly means (ie. what is the effect and significance of binding to the keydown instead of the keyup event) but as I said, an autocomplete widget on the same page as the ckeditor seemed to be working fine.

Someone with more knowledge might share it here.

This should be fixed in 7.x-2.x-dev.
@czigor: thanks for your work. I've used your workaround, but overriding only the jsAC instance created by the plugin.

Backported to 6.x-2.x-dev.

So I was trying to fix this issue, and somehow missed this ticket, but I wanted to throw in my $.02 because I think my fix addresses the concerns about altering the Drupal prototype...

Drupal has a Drupal.autocompleteSubmit() function to keep forms from being sumitted while the autocomplete is open (and it thus will allow selection using the return key)...

Thus the real issue is that CKeditor does not know to run this drupal check function... Calling the function from the CKeditor Plugin's Validate section solves the problem quite elegantly.

I don't want to rehash the issue, I just wanted to provide the info in case it were useful.

See: https://drupal.org/comment/8396373#comment-8396373 and https://drupal.org/files/issues/ckeditor_link-autocomplete_on_return_val... if interested.

Haven't tested yet myself, but that solution does seem more elegant. I'll give it a whirl tonight - I thought I looked all thru autocomplete.js and didn't find such a "silver bullet" earlier.

FYI, the change committed at #13-14 does not modify the autocomplete prototype but only the instance used by the plugin. So it does not have any side effect.
Anyway, using Drupal.autocompleteSubmit() might be a better solution indeed. I'll have a look at it.

This issue is occuring on a local instance using CKEditor-4.4.5 (full) using both the 7.x-2.3 and the 7.x-2.x-dev versions. I've tried the patches in this thread with no success either.

Any ideas? Anyone else experiencing this issue again?

(updating details of issue)

The patch in this issue thread fixed it for me. Tested in IE8 - 11, Chrome, Safari. I have also disabled the native ckeditor spellcheck - Scayt - and replaced with browser spellcheck. It's faster and causes less conflicts with other ckeditor javascript I found. Unfortunately browser spellcheck is only available on modern browsers, so IE 9+, but with the ckeditor settings hook you can turn on and off the native spellcheck depending on browser / browser version.

Ok I'll check this.

This should really be fixed this time.