Caret jumps to mouse position or start when selecting option from toolbar select menu

[acrylic-origami]

Steps to reproduce:

1. Type multiple lines of text, preferably in a large font size.
2. Access a toolbar menu (e.g. font size) and select an option that overlaps with the editor space (the second option usually works).
3. Repeat until clicking either the toolbar select menu or one of the options causes the caret to jump.

Using Quill Snow theme. The number of times to repeat is inconsistent and seems to be independent of frequency, but generally it's around 5-10 times. As far as I can tell, it occurs on Chrome 44 and Opera 31 (OS X Yosemite). Cannot reproduce in Firefox 39 or Safari 8.0.6.

[muhleder]

Might be related to this one.
#415
We're seeing some weird jumping issues in some cases as well. Inconsistent behaviour as well, sometimes it happens, sometimes it doesn't.

[jhchen]

I'm not understanding step 2, particularly the overlaps editor space part. Can you clarify?

[acrylic-origami]

@jhchen Hopefully the image will help clarify what I mean. Selecting an option on top of the editor space will sometimes cause the editor will focus and the caret will jump under the mouse cursor as if the menu weren't there. I specify "overlapping the editor space" in case the behaviour is different if, say, there is a large margin between the toolbar and the editor.

@muhleder Yup, sounds exactly like what I'm experiencing. I suspect that focusing "through" the select menu is another symptom of the problem. I tried to give your fork a spin, but the issues were only exacerbated? I can't apply any styles at all without caret-jumping and editor-unfocusing. I'll have scrutinize a bit more, but would you mind explaining how your change works?

[muhleder]

@acrylic-origami Sure, so from reading other related issues the jumping is caused by the focus called in initFormat()

https://github.com/muhleder/quill/blob/ca9cd7b6b1005969a26239a8f60762a476562edb/src/modules/toolbar.coffee#L43

so I removed that but then @quill.getSelection() was not able to get the selected text from the editor.

Looking at @quill.getSelection()

https://github.com/muhleder/quill/blob/ca9cd7b6b1005969a26239a8f60762a476562edb/src/quill.coffee#L161

it's really just a proxy for @Quill. getRange()

https://github.com/muhleder/quill/blob/ca9cd7b6b1005969a26239a8f60762a476562edb/src/core/selection.coffee#L18

which has an ignoreFocus option. So I added the ability to set that option in @quill.getSelection(), and called it from initFormat(), and the initFormat() then picked up the range properly.

This behaviour in this issue doesn't come from initFormat() I believe, so there may be another call to @quill.focus() in whichever function handles the dropdown here?

[acrylic-origami]

@muhleder I spent a few hours tinkering around and still can't rectify the bugs I'm getting with your fork. If text is highlighted, the format is applied normally. However, with a collapsed selection and without this call to @quill.focus(), the format isn't applied.

In the process though, I may have found the underlying cause of both our issues, and strangely it appears to be race condition-related? Editor.checkUpdate() is called periodically based on this setInterval which subsequently makes a call to @selection.update(). Comparing @selection.range before and after this call, I can confirm that selecting an option from a toolbar select before @selection.update() somehow interrupts execution and makes a separate call to update(), moving the caret (and leading to a discrepancy in the before- and after- Range objects). I feel that this SO answer may be relevant.

Removing the setInterval call actually reproduces your issue every time a toolbar item is selected. I have no idea why this is, and I don't know if there is an elegant way to clean up the event handling that is causing these problems. I suspect not...

[jhchen]

I believe this is the same root cause as #487 where the mouse action is a slight drag, not merely a click.