#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: | iseulde | 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)
#3
@
10 years 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.
#4
@
10 years 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. :(
#10
@
10 years 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.)
#14
@
10 years 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.
#16
@
10 years 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.
#17
@
10 years 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.
#22
@
10 years ago
.17: Cast off commands targeted to a view, except undo, redo and RemoveFormat. Disable the link button when a view is selected.
#26
@
10 years 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.
#28
@
10 years 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. :)
#29
@
10 years 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.
#30
in reply to:
↑ 27
@
10 years 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!?
#32
@
10 years ago
Do we need to do anything special here for RTL? Or does that automatically resolve somehow by having a different keyboard/computer?
#35
@
10 years ago
- Resolution set to fixed
- Status changed from new to closed
This works well, good job @avryl! New tickets for any bugs please.
Of course it flashes, but it looks like this.