#28595 closed defect (bug) (fixed)
wpviews: "catch" the cursor and create a fake cursor so that the "cursor" can be set on either side of the view
Reported by: | avryl | Owned by: | |
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | 3.9 |
Component: | TinyMCE | Keywords: | has-patch |
Focuses: | javascript | Cc: |
Description
Also fixes #28594, #28593 and #28257.
Patch coming. Atm this works perfectly well in Safari and Chrome. It needs some adjustments for Firefox. Haven't tested IE yet, brrr.
So this patch adds a body and two <p> tags before and after it. The body now is contenteditable="false", the parent wrap is not. Now the view can "catch" the cursor. We can detect it and create a fake cursor on the relevant side of the view. Keyboard input can be manipulated for those positions.
The fake cursor is as high as the view and you can't see the difference between the real and the fake one with the naked eye. :)
Moving around in the editor with arrow keys feels a lot more natural now.
Attachments (21)
Change History (60)
comment:3 avryl — 2 months ago
In the next patch, moving the cursor next to a view should also work in Firefox. No more double cursors. This should also fix the resize icon that was visible for less than a second. Let me know if you can still spot it.
Pressing backspace will remove the node before the view if it's empty, instead of moving the cursor there.
If the cursor is anywhere in or next to the view where it shouldn't be, the cursor wil be set properly.
If the editor is loaded and the first thing in it is a view, focussing the editor will set the cursor before the first view.
comment:4 avryl — 2 months ago
So at the moment this works perfectly well for me in Safari, Chrome and Firefox.
The only thing left is setting the cursor properly when clicking before or after the view. In Chrome and Safari the cursor will always be placed after the view. Firefox doesn't do anything.
Now I should make this work for the latest IE versions. :(
comment:5 avryl — 2 months ago
Of course it only works half in in IE 11. Sigh. Will try to fix it tomorrow.
comment:10 avryl — 2 months ago
A couple of issues:
- When a view is selected, pressing the up or down arrow key should immediately move the cursor to the block above or below the view instead of before or after the view.
- Selecting some text that touches the view will remove part of it when pressing backspace.
- When a view is the first block in the editor and the page is loaded, the cursor is correctly set before the view, but it doesn't react to key presses. (The editor doesn't seem to be focussed.)
comment:11 avryl — 2 months ago
.6 fixes issue 1.
comment:12 avryl — 2 months ago
.7 fixes issues 1 and 2.
comment:13 avryl — 2 months ago
Left some whitespace in .7
comment:14 avryl — 2 months ago
.11 fixes the three issues above + hides the cursor on blur + fixes the case where the cursor is before or after the view and wrongly moves it.
comment:15 azaozz — 2 months ago
In 29010:
comment:16 avryl — 2 months ago
Another issue: the colour of the cursor doesn't change based on the colour and background of the theme, so if the colour is white-ish, then the native cursor has that colour, but the "fake" cursor stays black. This can be solved by getting the colour of the body when TinyMCE loads (with a small timeout so any CSS has the time to load) and change it again whenever the post format changes.
comment:17 avryl — 2 months ago
And another issue... If the body has some padding on the left, clicking on the padding before a view doesn't set the cursor.
comment:18 azaozz — 2 months ago
In 29022:
comment:19 avryl — 2 months ago
comment:20 azaozz — 2 months ago
In 29126:
comment:21 azaozz — 2 months ago
In 29127:
comment:22 avryl — 2 months ago
.17: Cast off commands targeted to a view, except undo, redo and RemoveFormat. Disable the link button when a view is selected.
comment:23 azaozz — 2 months ago
In 29182:
comment:24 azaozz — 2 months ago
In 29183:
comment:25 azaozz — 2 months ago
In 29184:
comment:26 avryl — 8 weeks ago
Things left here:
- We need to colour the cursor based on the body's font colour.
- If the body has padding on the left or right, clicking just next to the view won't work.
comment:27 follow-up: ↓ 30 avryl — 8 weeks ago
Refreshed the earlier patch to colour the cursor.
comment:28 avryl — 8 weeks ago
Another thing... We're going to have to use the mousedown event instead of the click event to place the cursor next to the view. A normal cursor is also set on mousedown. In Safari the cursor is now set after the view on mousedown by the browser, and before the view on click by us. That looks weird. :)
comment:29 avryl — 8 weeks ago
I tried this in iOS...
- The native cursor never hides. I'm not sure if we can work around that. I think the cursor just always takes some space if the editor is focussed.
- I can't select a view. No matter how many times I click on it. :)
Other than that it seems to work quite well. It's just hard to set the cursor next the view because there's not much space before or after it. The looks of the cursor is also different. Thick blue vs. thin black.
comment:30 in reply to: ↑ 27 azaozz — 8 weeks ago
Replying to avryl:
Refreshed the earlier patch to colour the cursor.
Thinking we should use CSS3 currentcolor instead, works in IE9+.
(iOS Safari) I can't select a view. No matter how many times I click on it. :)
I can but only after I close the keyboard... Seems no 'click' event is fired in iOS Safari in contenteditable if the keyboard is open!?
comment:31 azaozz — 8 weeks ago
In 29245:
comment:32 avryl — 8 weeks ago
Do we need to do anything special here for RTL? Or does that automatically resolve somehow by having a different keyboard/computer?
comment:33 azaozz — 7 weeks ago
In 29273:
comment:34 azaozz — 7 weeks ago
In 29298:
comment:35 azaozz — 6 weeks ago
- Resolution set to fixed
- Status changed from new to closed
This works well, good job @avryl! New tickets for any bugs please.
comment:36 follow-up: ↓ 38 azaozz — 5 weeks ago
In 29463:
comment:37 azaozz — 4 weeks ago
comment:38 in reply to: ↑ 36 ocean90 — 4 weeks ago
comment:39 azaozz — 3 weeks ago
In 29536:
Of course it flashes, but it looks like this.