respond
respond copied to clipboard
madoublet
In editor, text selected using "select all" should be deleted when new text is typed
Consider an editable text element such as a paragraph, containing some text.
If I press control-A within that field and then begin typing some new text, the expected behavior is for the existing content to be deleted, and for the new text to take its place. Every web site, word processor, desktop app, etc. ever made has worked this way, so it's a well-established convention.
In Respond, the existing text is not deleted - rather, it is deselected, and then the new text is prepended to the beginning.
I'm trying to fix this myself but not having any luck. I have been reading up on contenteditable. I've also installed the respond-ui project and am digging through that to see if I can figure out how to fix this. I've looked through src/app/edit/edit/edit.component.ts and understand the basics. What I don't yet understand is which Angular route is used to serve the editor up in an iframe.
Can you offer any direction on which files I should look at, or in general how I could go about fixing this issue? Thanks!
Oh man, good luck. I have been trying to get this to work for awhile. It is a browser bug. When you delete all the text in a content-editable field, the field no longer becomes editable. I believe I tried to fix this in Respond by adding the default text back into the field but it leads to some buggy behavior.
The editor code is here: https://github.com/madoublet/respond/tree/master/public/editor
The editor is loaded here: https://github.com/madoublet/respond/blob/master/app/Http/Controllers/EditController.php
I will take a look at it again next time I feel like banging my head against the wall. I was honestly hoping browser vendors would have fixed this by now.
Here's a Codepen showing a simple DIV that is contenteditable. It works as expected there, but not in Respond.
Thanks for the pointers. I'll take a look at the editor code now.
Oops, I forgot the link to the Codepen. Here it is: https://codepen.io/anon/pen/LgZNMB
That does seem to work now. I am honestly not too sure then. I have the same problem in my other product. I will take a look at some point in the next few days.
Yep, that Codepen even handles deletion of rich text with bold, italics, and hyperlinks without any problems.
I spent some more time working with /editor/editor.js but I couldn't figure it out. I will wait to see if you have any more luck when you look at it.
After some investigation, the problem is caused by the menu being injected into the element. Basically, when you try to click back on the element when it is empty, it tries to click on the child elements (the element menu). I think the solution is to remove the menu from the element and adjust the position based on the selected element. I will add this to my list, but it certainly won't happen right away.
Nice detective work. I used the Chrome inspector to delete the menu from the DOM, and now the contenteditable field behaves as expected.
I did a little bit of Googling and learned about something called Element Queries, which are basically CSS media queries that target specific elements. Not sure if it would be going overboard to add this EQCSS library to Respond, but it does appear that it will allow any element to be positioned relative to some other arbitrary element that can be anywhere in the DOM structure, i.e. it doesn't have to be a sibling.
Just one possible solution.
The problem is that the drag handle needs to be in the element to work properly. So, I think it is easier to tackle the selection problem versus trying to figure another way to make drag-and-drop work.
Crossing my fingers that this might be a solution:
https://stackoverflow.com/questions/15659247/prevents-some-elements-from-being-edited-when-using-contenteditable
Sorry, accidentally closed it. I will take a look at it. The contentEditable=false is already in place around the containing div.
According to the StackOverflow you also have to set the x-respond-menu element to display: inline. I tried that and it didn't fix it for me, either, but didn't you say that you have some code in there that adds the default text back into the field when it's empty? Maybe it would work if we got rid of that and set the menu to inline?
I just fixed this in Fixture and I propose we do it the same way in Respond. The way Fixture works is that there is a menu that is created outside the editable item. This item is re-positioned every time an editable item is focused. When you click on the resize item, it injects a draggable handle into the div to allow you to move it around. On drag stop or reposition, that handle is removed. This prevents this weird situation we have in Respond where an empty div is not clickable. It does add an extra click to drag, but this is a small price to pay to fix this bug. I also plan on adding quick up and down arrows for quick repositioning (as this is probably the most common re-order use case).
This sounds fine, and I agree that an extra click is a small price to pay to put this issue to rest.
The new contextual menu is now live. See screenshot below. I plan to bring a few more things over from Fixture where ti makes sense.
