Make WordPress Core

Opened 9 years ago

Closed 9 years ago

Last modified 2 years ago

#29115 closed defect (bug) (fixed)

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

Reported by: programmin's profile programmin Owned by: azaozz's profile azaozz
Milestone: 4.0 Priority: normal
Severity: normal Version: 4.0
Component: TinyMCE Keywords:
Focuses: ui, javascript Cc:

Description (last modified by SergeyBiryukov)

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.

Attachments (1)

29115.patch (1.6 KB) - added by azaozz 9 years ago.

Download all attachments as: .zip

Change History (26)

#1 @programmin
9 years ago

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"

#2 @SergeyBiryukov
9 years ago

  • Description modified (diff)

#3 @programmin
9 years ago

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

#4 @iseulde
9 years ago

  • Milestone changed from Awaiting Review to 4.0

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.

9 years ago

#5 @azaozz
9 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from new to closed

In 29535:

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

#6 @programmin
9 years ago

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?

#7 @programmin
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

#8 @iseulde
9 years ago

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.

#9 follow-up: @programmin
9 years ago

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?

#10 in reply to: ↑ 9 @azaozz
9 years ago

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:

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.

Last edited 9 years ago by azaozz (previous) (diff)

#11 @programmin
9 years ago

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:

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


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.

#12 @azaozz
9 years ago

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.

#13 @programmin
9 years ago

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.

#14 @azaozz
9 years ago

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.

#15 @azaozz
9 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 29606:

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

#16 @programmin
9 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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:


[playlist ids="449"]

<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.

#17 @iseulde
9 years ago

This worked before [29606]. Looking...

#18 @iseulde
9 years ago

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

#19 @iseulde
9 years ago

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.

#20 @iseulde
9 years ago

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.

#21 follow-up: @programmin
9 years ago

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.

#22 @iseulde
9 years ago

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

#23 in reply to: ↑ 21 @azaozz
9 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#24 @programmin
9 years ago

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.

This ticket was mentioned in Slack in #core-editor by talldanwp. View the logs.

2 years ago

Note: See TracTickets for help on using tickets.