Chrome Version : 13.0.782.112 m and 15.0.859.0 canary This problem only happens on Chrome This problem is affecting the editor in Orion Project URLs (if applicable) : http://eclipse.org/orion/ What steps will reproduce the problem? 1. Use the following HTML <!DOCTYPE html> <html> <head> <title>test</title> <script> function myOnLoad() { var el = document.getElementById("myDiv"); el.addEventListener("selectstart", function(e) { e.preventDefault() }); var range = document.createRange(); range.setStart(el.firstChild, 0); range.setEnd(el.firstChild, 0); var sel = window.getSelection(); sel.addRange(range); } </script> <style> .myClass { width:100px; height:100px; background:yellow; position: absolute; top: 200px; left: 200px; // user-select:none; // NO OP // -webkit-user-select:none; //WORKS BUT window.getSelection().addRange() also stops working } </style> </head> <body onload="myOnLoad()"> <div id="myDiv" contentEditable="true" class="myClass" > sample text that should not get selected </div> </body> </html> 2. Click and hold in the text content in the div. 3. Move the mouse (still holding the mouse button down) inside the bounds of the div, selection does not happen (correct) 4. Move the mouse outside the bounds of the div, text selection starts (wrong) 5. Move back inside the bounds of div and keep moving the mouse, text selection happens (wrong) What is the expected result? text selection should never happen. What happens instead? text selection start to happen. Please provide any additional information: This used to work, I suspect that this was working as recent as chrome 12.
> This problem only happens on Chrome It also happens in WebKit nightlies, of course. Also, Firefox allows selecting the text without problem (perhaps it doesn't support this event at all?) What does IE do? It's not clear to me if selectstart should be dispatched on the div, given that selection dragging starts outside it.
The current WebKit behavior matches that of MSIE9. Won't fix.
(In reply to comment #2) > The current WebKit behavior matches that of MSIE9. Won't fix. The test case in the initial comment works for me on IE9. how did you test ?
Created attachment 108521 [details] test case
(In reply to comment #4) > Created an attachment (id=108521) [details] > test case For me, using the testcase. the IE behavior is different than webkit. Is it the same for you? I can easily cause text selection in webkit by moving the mouse outside the yellow box.
(In reply to comment #5) > For me, using the testcase. the IE behavior is different than webkit. > > Is it the same for you? I can easily cause text selection in webkit by moving the mouse outside the yellow box. Right. On IE, you need to drag mouse top-down. Nonetheless, IE lets you select text. The difference comes from the way hit-testing in IE & WebKit work.
(In reply to comment #6) > Right. On IE, you need to drag mouse top-down. Nonetheless, IE lets you select text. The difference comes from the way hit-testing in IE & WebKit work. After trying several times I managed to cause the bug in IE, I need to place the caret after the offset at line end, or before the offset at line start. Then move the mouse the opposite direction. Nothing but a bug in IE. Nevertheless, I don't have the bug in IE for my project. There, I could stop the mouse down event to prevent text selection, then use element.setCapture() to receive all the mouse events to implement my own text selection behavior. In Webkit, I could stop the mouse down the same way (stopping native text selection). But then I lose the capture, and there is no setCapture() API in webkit...
(In reply to comment #7) > After trying several times I managed to cause the bug in IE, I need to place the caret after the offset at line end, or before the offset at line start. Then move the mouse the opposite direction. > > Nothing but a bug in IE. This isn't a bug. selectstart event fires in the element where mousedown occurred. If you start selection in the middle of "aaa" and extend it to the middle of "bbb", you can always select the text in the box. > Nevertheless, I don't have the bug in IE for my project. There, I could stop the mouse down event to prevent text selection, then use element.setCapture() to receive all the mouse events to implement my own text selection behavior. > > In Webkit, I could stop the mouse down the same way (stopping native text selection). But then I lose the capture, and there is no setCapture() API in webkit... Try -webkit-user-select:none; and getSelection().setPosition.
(In reply to comment #8) > This isn't a bug. selectstart event fires in the element where mousedown occurred. If you start selection in the middle of "aaa" and extend it to the middle of "bbb", you can always select the text in the box. > Yes, but I'm not starting selection in the middle of "aaa" or "bbb". I start with a mouse down on the div element. The behaviour is different based on the letter (of "sample text that should not get selected ") that I click. It is a bug. > > Try -webkit-user-select:none; and getSelection().setPosition. I tried -webkit-user-select:none; It doesn't work for me, see my initial comment: // -webkit-user-select:none; //WORKS BUT window.getSelection().addRange() also stops working as for getSelection().setPosition(), could you please explain how I could use that to solve my problem? I have a contentEditable div. I want to take control over all text selection (keyboard and mouse), stop the UA and implement my own handlers. I need to set the DOM selection myself. I need mouse capture to start in mouse down, as I need to implement drag selection and auto scrolling.
(In reply to comment #9) > I start with a mouse down on the div element. There's no way I can select the text if I start mouse-down inside the div. The mouse down has to happen outside of the div potentially on the left or on the right of the div. > The behaviour is different based on the letter (of "sample text that should not get selected ") that I click. It is a bug. I'm not observing this behavior. > I have a contentEditable div. > I want to take control over all text selection (keyboard and mouse), stop the UA and implement my own handlers. > I need to set the DOM selection myself. Why do you want to do this? Sounds like it'll be a bad UX. Regardless, if you really want to implement such a behavior, then you'd have to listen to selectstart at the document level, not per each element.
(In reply to comment #10) > I'm not observing this behavior. Try this: Open the attachment in comment 4 https://bugs.webkit.org/attachment.cgi?id=108521 Click-and-hold in the middle of the div (in the word "not" for example). Make sure you hold the left button down. Move the mouse pointer upwards, till you are about 20px above the div (outside of the div); move the mouse pointer to the left and to the right back and forth. Text selection occurs. Happens to me on Windows 7 running the chrome 14.0.835.202 Can you make it happen now ?