Opened 8 years ago
Closed 8 years ago
#36459 closed defect (bug) (duplicate)
Inconsistent triggering of backtick shortcut for code tags
Reported by: | Clorith | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.5 |
Component: | TinyMCE | Keywords: | |
Focuses: | javascript | Cc: |
Description
The backticks to trigger <code>
blocks is inconsistent in when it wants to trigger, some times it doesn't convert at all, other times it'll randomly convert it a while after you've stopped typing and I've been unable to lock down why this happens.
Currently tested on Chrome 49.0.2623.112 and reported in https://wordpress.org/support/topic/text-pattern-for-code-not-working-in-latest-trunk-version (which also includes a preview gif of the issues)..
I've tried with the code block being the only text on a line, as well as it being inline with other content, both ways seem to kick in when they feel like it with no observable pattern.
I've attached a screenshot showing the current random behavior as well.
Attachments (4)
Change History (19)
#1
@
8 years ago
In IE11 (11.0.9600.18098) it seems to be triggering every time, up until you try to use an uppercase letter inside a backtick, then it starts behaving inconsistently across the board again.
#3
@
8 years ago
Here's the body of the extended screenshot
<body id="tinymce" class="mce-content-body content post-type-post post-status-draft post-format-standard locale-en-us mceContentBody webkit wp-editor wp-autoresize html5-captions has-focus" data-id="content" contenteditable="true" style="overflow-y: hidden;"> <h2>A whole new world</h2> <p>A new <code>fantastic</code> point of view</p> <p>No one to tell us `no` or `where` to go</p> <p>`Or say we're only dreaming`</p> <p>Was it the `newlines` causing this?</p> <h2>I'll make a man out of you</h2> <p>Let's get down to `business`.</p> <p>To <code>defeat</code> the huns.</p> <p>Did they send me <code>daughters</code> when I asked for <code>sons</code>.</p> <p>You're the <code>sadest</code> bunch I ever saw, but you can <code>bet</code> before we're through</p><p>`Mister` I'll make a man out of you</p> </body>
The line breaks after each h2
and p
tag are mine for readability
#4
follow-up:
↓ 5
@
8 years ago
I can consistently reproduce this in Chrome 49.0.2623.112 and Firefox 45.0.1 in OSX if I very quickly hit the spacebar immediately after the closing backtick.
<body id="tinymce" class="mce-content-body content post-type-post post-status-draft post-format-standard locale-en-us mceContentBody webkit wp-editor wp-autoresize html5-captions has-focus" data-id="content" contenteditable="true" style="overflow-y: hidden;"> <p>`the spacebar was hit very quickly after this closing backtick` </p> </body>
#5
in reply to:
↑ 4
@
8 years ago
Replying to jeremyfelt:
I can consistently reproduce this in Chrome 49.0.2623.112 and Firefox 45.0.1 in OSX if I very quickly hit the spacebar immediately after the closing backtick.
<body id="tinymce" class="mce-content-body content post-type-post post-status-draft post-format-standard locale-en-us mceContentBody webkit wp-editor wp-autoresize html5-captions has-focus" data-id="content" contenteditable="true" style="overflow-y: hidden;"> <p>`the spacebar was hit very quickly after this closing backtick` </p> </body>
You are quite right, if I hit the buttons fast enough, as in practically at the same time, I can trigger the code block consistently every time.
This is a bit awkward though (at least on a Norwegian keyboard) as the backtick is a shift-key combination to access to begin with (and this should perhaps be a pattern recognition, not a timing dependent one?)
#6
@
8 years ago
Replying to Clorith:
Replying to jeremyfelt:
I can consistently reproduce this in Chrome 49.0.2623.112 and Firefox 45.0.1 in OSX if I very quickly hit the spacebar immediately after the closing backtick.
<body id="tinymce" class="mce-content-body content post-type-post post-status-draft post-format-standard locale-en-us mceContentBody webkit wp-editor wp-autoresize html5-captions has-focus" data-id="content" contenteditable="true" style="overflow-y: hidden;"> <p>`the spacebar was hit very quickly after this closing backtick` </p> </body>You are quite right, if I hit the buttons fast enough, as in practically at the same time, I can trigger the code block consistently every time.
I think this is the opposite for me. When I type at a slower pace, the code block is generated. If I type something very quickly after the closing backtick, it breaks.
The gif above should show the behavior.
Additional findings:
- Once a paragraph experiences a non-working backtick, any remaining uses on that line won't work either.
- This does not impact new paragraphs. Things reset.
#7
@
8 years ago
Can confirm the additional findings, also if the first one is broken you can't "fix" the first one without removing any additional ones first, they seems to block each other out so to speak.
I still can't make it trigger by typing slowly, I do need to hit the space bar and the backtick almost at the same time for them to convert to code tags, odd.
I'm no wizard with gifs unfortunately so mine get larger in size but the behavior for my part is apparent in http://imgur.com/Q3JNWJj
#8
@
8 years ago
I enabled the OSX Norwegian keyboard layout to try and reproduce. I'm still able to (via Shift - \) create code blocks at a normal pace.
However, wherever ` could be used as a modifier to add a grave accent, it definitely interrupts the process. If used before a character that does not get the accent, it works as normal.
English keyboard: `a code block` and `this code block` Norwegian keyboard: à code block and `this code block`
When typing the closing backtick, I get the indicator that it's waiting to be used as a modifier until I type something else. I wonder if the backtick's use as a modifier key is confusing the JS?
This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-editor by jeremyfelt. View the logs.
8 years ago
#11
@
8 years ago
- Milestone changed from 4.5 to Future Release
Bumping this to a future release. There's not much we can do when processing backticks on some keyboard layouts because of the way these are communicated from the OS to the browser. We'll probably look closer at how these patterns are processed. Related: #33300
#12
@
8 years ago
The backtick problem on keyboards that require a modifier might be solved by loosening the checks on keyCode
values in the keyup
event handler. I've tried testing it by setting up a Norwegian layout but I'm not sure I have the right set up. If it does solve the problem, it's quite a small change really as the checks are only done for optimization reasons.
The quick typing issue is trickier as it's caused by typeahead getting into the selection on keyup
which means that the current character needn't be a backtick. The change in the patch allows for one extra typeahead but if you're very quick you can put two in at least.
The broken backtick issue causing others in the same paragraph not to work can be fixed by looking for the endOffset
first and then looking backwards for the start.
There's a couple of other changes, to ignore backticks that are empty or contain a single white space, and to ignore backticks when they're in the code nodes themselves.
#13
@
8 years ago
- Keywords has-patch added
- Version changed from trunk to 4.5
@iseulde What are your thoughts on 36459.patch?
#15
@
8 years ago
- Component changed from Editor to TinyMCE
- Keywords has-patch needs-refresh removed
- Milestone Future Release deleted
- Resolution set to duplicate
- Status changed from new to closed
Closing as one problem was addressed in #36585, and the other is being addressed in #37693.
For keyboards that also use the key for accents, pressing space afterwards will not combine it with another character. I believe that's just how it works. I used to have a Belgian keyboard that worked like this.
Please test and reopen if there are still issues.
The backticks triggering in one instance, but not the others