Make WordPress Core

Opened 11 years ago

Closed 11 years ago

Last modified 4 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 11 years ago.

Download all attachments as: .zip

Change History (26)

#1 @programmin
11 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
11 years ago

  • Description modified (diff)

#3 @programmin
11 years ago

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

#4 @iseulde
11 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.

@azaozz
11 years ago

#5 @azaozz
11 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
11 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
11 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
11 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
11 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
11 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: 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.

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

#11 @programmin
11 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: 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.

#12 @azaozz
11 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
11 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
11 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
11 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
11 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:

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

#17 @iseulde
11 years ago

This worked before [29606]. Looking...

#18 @iseulde
11 years ago

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

#19 @iseulde
11 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
11 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
11 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
11 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
11 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
11 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.


4 years ago

Note: See TracTickets for help on using tickets.