Closed Bug 421640 Opened 16 years ago Closed 16 years ago

contentEditable elements should remember text selection onblur

Categories

(Core :: DOM: Editor, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: tom, Assigned: peterv)

References

()

Details

Attachments

(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; en-gb) AppleWebKit/526.1+ (KHTML, like Gecko) Version/3.0.4 Safari/523.15
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3

Whilst editing within a contentEditable element, clicking outside it to another element (such as a <button>) results in any text selection being lost.

This is contrary to what IE, Safari and Opera all do, and makes document.execCommand very difficult to use. The selection should be remembered, as it is with a normal non-editable element, so execCommand can act upon the selected text.

Reproducible: Always
Attached file testcase (obsolete) —
Attached file fixed testcase
Attachment #308096 - Attachment is obsolete: true
This one is important since there is no way to work around it. You can't restore the DOM Range on some element types for example images or tables.

So a scenario might be if you select an image then click on the edit image button the selection will be lost and then there is no way to restore the selection to the image so that you get the nice image resize controls back.
Flags: blocking1.9?
+'ing.  P2.  Assigning to peterv.

Peter, please comment if we should change blocking status here.
Assignee: nobody → peterv
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
This is going to be hard to fix without regressing shift-tabbing out of a document with contentEditable regions.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attached file workarounds
These hacks aren't keyboard-accessible.  But Safari and Opera both clear the selection if you Shift+Tab out of the contenteditable area, so maybe it's not important for the hack to be keyboard-accessible.
Given the regression risk and the availability of a workaround, I don't think this should block Gecko 1.9.  (This bug isn't a regression, just a shortcoming of a new feature in Gecko 1.9.)
The demo works somehow, when you change the onclick, to onmousedown.
Taking the advice in comment #7.  -'ing this, but marking wanted 1.9.0.x+. 

Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+
Hmm, I still think this needs to be a blocker since image editing is not possible if this bug isn't fixed.

But I guess it could be resolved by adding the possibility so make real control selections of images with JavaScript at least then one could build around this problem but now it's impossible. But I guess that is another bug/feature request that needs addressing instead.
I think this is a regression, because i can not use the contentEditable property like i used the designMode Element. I've created a Richt-Text Editor, that uses an iframe with designmode. In Browsers that support contentEditable, i use this instead, because I need some uneditable areas in the document. All browsers with contentEditable-support, but Firefox 3 work the same way and do not loose the focus when leaving the iframe. 
I've got some options for workarounds: 
- for buttons i can use the onmousedownevent, but that is not intuitive for users
- in other cases i can save the selection at the ifram.oblur event.

But that just would be hacks. So i think this is a regression or a major incompatibility with other browser. I look forward to see this bug fixed as announced in bug 406596. Keep up the good work.
This absolutely is a regression. It worked fine in Firefox 3 betas 1 and 2, it was broken in beta 3 onwards.
Renominating, since the last few comments make good points.

Does the patch in bug 406596 also fix this bug?
Flags: blocking1.9- → blocking1.9?
True.  I'll put this back on the blocker list, but if it comes to this being the last bug blocking the release of firefox, we'll ask ourselves the hard question of to unblock or not again.
Flags: blocking1.9? → blocking1.9+
The patch in bug 406596 should fix this, yes.
Fixed by the fix for bug 406596. Test checked in as part of the fix for bug 406596.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
Version: unspecified → Trunk
verified fixed using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050804 Minefield/3.0pre and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050614 Minefield/3.0pre
Status: RESOLVED → VERIFIED
Flags: wanted1.9.0.x+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: