#29115 closed defect (bug) (fixed)
Unexpected enter, and other graphical glitches with cursor near wp-view.
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | 4.0 |
Component: | TinyMCE | Keywords: | |
Focuses: | ui, javascript | Cc: |
Description (last modified by )
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)
Change History (26)
#4
@
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.
#5
@
11 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In 29535:
#6
@
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
@
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
@
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:
↓ 10
@
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
@
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
.
#11
@
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
@
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
@
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
@
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.
#16
@
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.
#19
@
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
@
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:
↓ 23
@
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
@
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
@
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
@
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.
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"