If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Focusing and removing a contentEditable breaks further selection.collapse calls

NEW
Unassigned

Status

()

Core
DOM
5 years ago
9 months ago

People

(Reporter: garryb, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 641331 [details]
firefox_selection_issue.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11

Steps to reproduce:

Basically:
- focus() a contentEditable div
- remove it from the DOM
- call window.getSelection().collapse()

I discovered this issue while making a change to Google's Closure library Editor (TrogEdit). Source inline (and also attached as an HTML file):

<!DOCTYPE html>
<html>
<head>
<title>Gecko Selection Issue</title>
</head>
<body>
<div id="editable" contentEditable="true">Editable Div</div>
<div id="foo">Div to place caret in</div>
<script>
  try {
    // Focus a contentEditable div, then remove it.
    var editable = document.getElementById('editable');
    editable.focus(); // If you comment this line, there's no exception.
    editable.parentNode.removeChild(editable);
    // This now fails.
    window.getSelection().collapse(document.getElementById('foo'), 0);
  } catch(ex) {
    alert(ex);
  }
</script>
</body>
</html>



Actual results:

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsISelection.collapse]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: https://www.corp.google.com/~gboyer/no_crawl/firefox_selection_issue.html :: <TOP_LEVEL> :: line 16"  data: no]



Expected results:

window.getSelection().collapse(node, offset) should put the caret in that node at the offset. If you remove the focus() on the contentEditable div that gets removed, it'll work.

Updated

5 years ago
Attachment #641331 - Attachment mime type: text/plain → text/html

Comment 1

5 years ago
No error:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a9pre) Gecko/2007102504 Firefox/3.0a9pre ID:2007102504
Error:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9b3pre) Gecko/2008010104 Firefox/3.0b3pre ID:2008010104
Bonsailog:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-10-25+03%3A00%3A00&maxdate=2007-10-26+06%3A00%3A00&cvsroot=%2Fcvsroot
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM
Ever confirmed: true
OS: Mac OS X → All
Product: Firefox → Core
Version: 13 Branch → Trunk

Comment 2

5 years ago
Oops, please ignore comment#1. And correct as follows

No error:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a9pre) Gecko/2007102504 Firefox/3.0a9pre ID:2007102504
Error:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9a9pre) Gecko/2007102605 Firefox/3.0a9pre ID:2007102605
Bonsai log:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-10-25+03%3A00%3A00&maxdate=2007-10-26+06%3A00%3A00&cvsroot=%2Fcvsroot
(Reporter)

Comment 3

5 years ago
Wow, this was a regression from a 5 year old build?

Also should add -- explicitly calling blur() before removing the element also avoids the exception.

Comment 4

4 years ago
Setting "contenteditable" to "false" also causes this behaviour.
You need to log in before you can comment on or make changes to this bug.