389348 - Triple-click inside contenteditable element is buggy

Status: REOPENED

(Core :: DOM: Selection, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase.
I see 2 issues regarding triple-clicking inside the contenteditable element:

- First time triple-click doesn't work. It probably has something to do with becoming an editor when the element gets focused. I don't see this issue when using tabindex="1", so it doesn't necessarily have anything to do with focus handling.

- Second time triple-click works, but it selects the whole line, so it includes the text outside the contenteditable element. That's not what IE7 is doing. IE7 stops at the contenteditable element's boundaries.

Comment 1

[David Zbarsky (:dzbarsky)]

Also, if you try to press backspace after the first t, it starts putting spaces before the t.

Comment 2

[Mathias Bynens]

FWIW, double-clicking (to select a word) works, but as long as the word is still selected you cannot enter new input. You need to deselect the text first. :(

Comment 3

[(no longer active)]

(In reply to comment #0)
> Created attachment 273515 [details]
> testcase
> 
> See testcase.
> I see 2 issues regarding triple-clicking inside the contenteditable element:
> 
> - First time triple-click doesn't work. It probably has something to do with
> becoming an editor when the element gets focused. I don't see this issue
> when using tabindex="1", so it doesn't necessarily have anything to do with
> focus handling.

I can't reproduce this.

> - Second time triple-click works, but it selects the whole line, so it
> includes the text outside the contenteditable element. That's not what IE7
> is doing. IE7 stops at the contenteditable element's boundaries.

This is the expected behavior.  Triple-click selects a paragraph, and whether or not part of it is editable should not be relevant.  To get the IE7-like behavior, you could just set the display type of the span to inline-block.

(In reply to comment #1)
> Also, if you try to press backspace after the first t, it starts putting
> spaces before the t.

How do you reproduce this?

(In reply to comment #2)
> FWIW, double-clicking (to select a word) works, but as long as the word is
> still selected you cannot enter new input. You need to deselect the text
> first. :(

This is a different bug (it doesn't have anything to do with triple clicking, right?).  Can you please file it separately?

Comment 4

[Mathias Bynens]

(In reply to comment #3)
> This is the expected behavior.  Triple-click selects a paragraph, and
> whether or not part of it is editable should not be relevant.  To get the
> IE7-like behavior, you could just set the display type of the span to
> inline-block.

FWIW, what Firefox is doing here is not just different from IE, but also from WebKit. Only Opera has similar behavior to Firefox. (I don’t know which is the correct behavior as per the spec, although the one IE/WebKit have feels the most natural to me.)

(In reply to comment #3)
> This is a different bug (it doesn't have anything to do with triple
> clicking, right?).  Can you please file it separately?

Sure! I just filed bug 668599.

Comment 5

[(no longer active)]

(In reply to comment #4)
> (In reply to comment #3)
> > This is the expected behavior.  Triple-click selects a paragraph, and
> > whether or not part of it is editable should not be relevant.  To get the
> > IE7-like behavior, you could just set the display type of the span to
> > inline-block.
> 
> FWIW, what Firefox is doing here is not just different from IE, but also from
> WebKit. Only Opera has similar behavior to Firefox. (I don’t know which is the
> correct behavior as per the spec, although the one IE/WebKit have feels the
> most natural to me.)

What if the content editable area doesn't have any borders/outlines?  Then that would seem totally unnatural.

The problem here is that there is no spec to dictate what should happen in this case... :/

Comment 6

[Mathias Bynens]

(In reply to comment #5)
> The problem here is that there is no spec to dictate what should happen in
> this case... :/

I believe Aryeh Gregor is writing a spec for it.

Comment 7

[Martijn Wargers (dead)]

This is originally derived from an IE feature, so in in that case you should normally do what IE does.

Comment 8

[Aryeh Gregor (:ayg) (no longer with Mozilla)]

(In reply to comment #3)
> This is the expected behavior.  Triple-click selects a paragraph, and
> whether or not part of it is editable should not be relevant.  To get the
> IE7-like behavior, you could just set the display type of the span to
> inline-block.

Editability already makes a difference to selections.  Consider this test-case:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1056

If you click in the editable area and drag with the mouse, or position the cursor and select with Shift+arrows, the selection doesn't leave the editable area.  That holds in Firefox 6.0a2, Chrome 14 dev, and Opera 11.50 at least.  (I didn't have IE handy to test, but I assume it's the same.)  Thus we see that as a rule, a selection that you begin in an editable region doesn't leave the region.

That example is with <p>, but I observe the same behavior with <span>.  Even though the text is on the same line, the selection won't go outside if it starts inside.  Except that Gecko and Opera do let it go outside if you create the selection by double- or triple-clicking inside the editable area.

For consistency, I think IE's/WebKit's behavior makes the most sense: double- or triple-clicking inside an editable region should keep the selection in the editable region, just like other ways of selecting that start in an editable region.  However, this is a bit of a corner-case, since inline contenteditable is not exactly common . . .

(In reply to comment #6)
> I believe Aryeh Gregor is writing a spec for it.

I haven't specced what user motions should create exactly what selections.  All browsers (I think, didn't test IE) allow users to create selections that include some editable and some non-editable parts, like by starting the selection in a non-editable part and dragging with the mouse to include editable things.  Whether a double- or triple-click creates such a selection is a bit of a UI detail, and I'm not sure it needs to be specified.  (I do plan to specify some constraints on what types of selections the user is allowed to create, though, as discussed on the whatwg list.)

What to do if the user tries taking an action like delete when some non-editable text is selected is a separate issue, and I will spec that at some point.  Currently my spec does say what to do, but it's probably wrong, since I didn't test in that case.

(In reply to comment #7)
> This is originally derived from an IE feature, so in in that case you should
> normally do what IE does.

Gecko's implemented stuff related to this for over ten years, and WebKit/Opera for a number of years as well, so in practice the IE origin of the features isn't important these days.

Comment 9

[(no longer active)]

OK, sold!  Let's reopen this bug for now...