Unexpected enter, and other graphical glitches with cursor near wp-view.

[programmin]

Using the WP 4.0 beta (4.0-beta2-20140803), and Twenty Eleven theme, I was seeing some weird behavior. Steps to see the problem:

1) Choose one audio file and create an audio playlist on one line of the editor.

2) With the cursor immediately before or after the playlist (cursor will appear very tall), press ctrl, shift, alt, any key - and it inserts an enter for no apparent reason. (Tested in Firefox, Chromium)

In Chromium it's even worse, when cursor is before the playlist and you click away from the browser to another window, the browser's editor contents blink on and off incessantly.

I was also occasionally seeing two cursors - the normal one and the tall one (ticket #28595?) at the same time when before the view.

[programmin]

To clarify, the blinking-the-entire-post-contents bug happened (still happens in beta 3) on Chromium 34:

"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36"

but not version 36:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/36.0.1985.125 Chrome/36.0.1985.125 Safari/537.36"

[programmin]

Still happening on 4.0 beta4. Is this bug in-progress?

[iseulde]

Yeah, we should exclude some other keys... Currently alt inserts a paragraph, shift removes the view... I'll make a patch.
And the double cursor happens after inserting a view.

[azaozz]

In 29535:

TinyMCE wpView: ignore more keys when the caret is around a view. Part props avryl, fixes #29115.

[programmin]

To be clear, is this fixing Chrome 34's blink when focusing other browser window as well? Or do we assume most Chrome users keep up-to-date?

[programmin]

Still seeing this bug with Shift/Ctrl/Alt keys, after latest update with nightly beta plugin.

This was with 2014 theme, only beta-tester and Akismet plugins active.

[iseulde]

Tested in Chrome 36.0.1985.143 and Firefox 31.0 on a Mac. Pressing cmd/ctrl/alt/fn/shift/shift lock does not trigger anything for me.

[programmin]

I just grabbed the latest from svn, cleared cache and verified that that new isSpecialKey function is in the JS that's running in the browser. While this seems to fix the problem in Firefox, I'm still seeing this behavior in Chromium (36.0.1985.125 Ubuntu 14.04 (283153)), in fact it is worse. Shift, alt, as well as the arrow keys are inserting paragraph for no apparent reason.

The "key" for shift and arrow buttons is 229, in the parameter for isSpecialKey, this may be different on Linux+Dell keyboard, than on Mac+Mac keyboard?

[azaozz]

Replying to programmin:

What kind of keyboard layout are you using? Don't mind excluding keyCode 229, but don't see it ever mapped to the Shift key? Ref: ​https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.keyCode.

Are there any other keyCodes we need to consider? Looking further at the above list: seems we should exclude all keyCodes >= 224 and also >= 144 && <= 150.

[programmin]

I'm using the default English keyboard layout in Ubuntu 14.04. In Text Entry Settings I only have "English (US)" on my list.

The problem is not just that it's the wrong key number - it seems TinyMCE is calling keydown event with 229 before the actual key number, as you can see in this fiddle: ​http://fiddle.tinymce.com/yueaab

The console output when pressing left, down, right buttons gives:

229
37
229
40
229
39

Oddly enough, I'm not seeing this bug in Midori on Ubuntu, or Chrome on Windows, so it must be a bug with Tinymce conflicting a certain version of Chrome/webkit.

[azaozz]

Ha, so there are two events fired on every keydown? Don't think this has anything to do with TinyMCE. It's most likely a browser bug. To test, add something like:

jQuery(document).on('keydown', function(e){ console.log(e.keyCode); });

from the console.

[programmin]

No, I don't see 229 firing for jQuery events ever, just the TinyMCE keydown events.

jQuery and normal events don't have this odd bug in Chromium.

[azaozz]

Hmm, maybe it is contentEditable specific? Don't see any code in TinyMCE that would fire a "fake" keydown event before the "real" one. In any case, seems we should exclude all keys above keyCode 224.

[azaozz]

In 29606:

TinyMCE wpView: exclude more non-printable keyCodes in isSpecialKey(), fixes #29115

[programmin]

Nice! That fixes the arrows inserting paragraphs, but I'm still seeing buggy behavior with the arrow keys:

If you try this content, and try to arrow down to below the playlist, it won't go past the playlist:

<div>

[playlist ids="449"]

</div>
<div>[nggallery id=2]</div>

Furthermore if you're keying up to top, it traps the cursor to that playlist, you can't move cursor below again.

[iseulde]

This worked before [29606]. Looking...

[iseulde]

Sorry ignore the last comment, I had some other problem.

[iseulde]

Not sure if we should try to fix this... The views are really not intended for use inside divs. If you remove them from the playlist, the problem is gone. We could work around it, but I don't think it's a good idea to try this for 4.0.

[iseulde]

When using the arrow keys, we look if the view has any siblings and move the cursor to the relevant one. If not, it just leaves the cursor where it is. In this case, we should look for siblings all the way up to the body and move the cursor there. Making a patch and we'll see how much of a change it requires.

[programmin]

I hope this can work within divs, as forced_root_block='div' is a very popular mce setting, and has worked great in 3.9.

Thank you for looking into this.

[iseulde]

Hm, and forced_root_block=div doesn't break anything else in WordPress? :) That'd be surprising.

[azaozz]

Replying to programmin:

This seems too complex for a quick fix. Not sure how popular forced_root_block: 'div' is, but it seems to break at least 4-5 other places a bit, the arrow keys being pretty minor.

Better to make new ticket for 4.1.

[programmin]

4-5 bugs where, can you give me the issue ids? Other than some wp-view bugs like this I haven't noticed major problems with forced_root_block = div.