Mihai Sucan [:msucan] Reporter
	Description • 13 years ago

There is no way to cancel caret navigation within an editable element when the user right-clicks inside it, if the element already had focus.

STR:

1. create a document with a contentEditable element.
2. add a mousedown event handler for the contentEditable element and call event.preventDefault() for event.which === 3 (for right-click).
3. load the document.
4. left click inside the editable.
5. right click in some other location within the editable.

Expected result: the default action is prevented - the caret does not navigate to the right click location.

Actual result: the default action is not prevented - the caret moves to the new mouse location when I right click and any previous selection is lost.

This happens only when the editable has focus. Otherwise preventDefault() works fine (if the editable has no focus).

	Mihai Sucan [:msucan] Reporter
	Comment 1 • 13 years ago

STR:

1. load the TC.
2. left click inside the editable element.
3. right click inside the editable element, at a different location.

Expected result: no caret navigation happens.

Actual result: caret location changes.

This test case works as expected in Chrome 15 and Opera 11.6.

I tested on Linux with Firefox 9 beta and with the latest Firefox fx-team build.

Please note that this bugs affects the Eclipse Orion project and our developer tools that use the Orion editor.

	Mihai Sucan [:msucan] Reporter
	Comment 2 • 13 years ago

Testing info: I tried to do event.stopPropagation() and to call preventDefault and stopPropagation from a capturing event, on a parent element, and I also tried to do this for mouseup and for click events, and all combinations I could think of. Nothing seems to stop the caret move on right click.

	(no longer active)
	Comment 3 • 13 years ago

Is this blocking you guys?  I can work on it, but if it's not urgent, I'd like to work on other stuff.

	Mihai Sucan [:msucan] Reporter
	Comment 4 • 13 years ago

(In reply to Ehsan Akhgari [:ehsan] from comment #3)
> Is this blocking you guys?  I can work on it, but if it's not urgent, I'd
> like to work on other stuff.

This is not blocking Orion at this time, however we do have a workaround for the bug in the Orion code. As usual, we want to reduce the number of bugs we workaround for.

Thank you very much Ehsan!

	(no longer active)
	Comment 5 • 13 years ago

(In reply to Mihai Sucan [:msucan] from comment #4)
> (In reply to Ehsan Akhgari [:ehsan] from comment #3)
> > Is this blocking you guys?  I can work on it, but if it's not urgent, I'd
> > like to work on other stuff.
> 
> This is not blocking Orion at this time, however we do have a workaround for
> the bug in the Orion code. As usual, we want to reduce the number of bugs we
> workaround for.

So I take it that it's OK to put this on the back burner for now?

Let me know if this becomes a priority in the future.  Thanks!

	Mihai Sucan [:msucan] Reporter
	Comment 6 • 13 years ago

(In reply to Ehsan Akhgari [:ehsan] from comment #5)
> (In reply to Mihai Sucan [:msucan] from comment #4)
> > (In reply to Ehsan Akhgari [:ehsan] from comment #3)
> > > Is this blocking you guys?  I can work on it, but if it's not urgent, I'd
> > > like to work on other stuff.
> > 
> > This is not blocking Orion at this time, however we do have a workaround for
> > the bug in the Orion code. As usual, we want to reduce the number of bugs we
> > workaround for.
> 
> So I take it that it's OK to put this on the back burner for now?

That is correct.

> Let me know if this becomes a priority in the future.  Thanks!

Will do. Thank you!