302819 - Editor fails to remove nodes from content when document.body is changed

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050719 SeaMonkey/1.0a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050719 SeaMonkey/1.0a

When I change editor.contentWindow.document.body.innerHTML then I cannot delete
any text from a content of document by pressing 'delete' or 'backspace' keys
(commandDispatcher doesnt work too in this case). If I'll insert some text then
I will be able to remove text from a content.

Reproducible: Always

Comment 1

[alexander :surkov (:asurkov)]

Attachment: testcase

put this sample into package and run it with '-chrome' command line argument

Comment 2

[Boris Zbarsky [:bzbarsky]]

Needs testcase that doesn't need to be chrome...

Comment 3

[alexander :surkov (:asurkov)]

Attachment: nochrome testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

Confirming.  brade, glazou, any idea what's up here?

Comment 5

[Kathleen :Brade]

I'd look at nsEditor::GetRootElement() and mRootElement to see if those are causing the problem.

Comment 6

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

The reporter may have to call nsHTMLEditor::BeginningOfDocument()

Comment 7

[Ioana (away)]

Windows 2000 support has been dropped a while ago. Please only reopen this bug if you can reproduce it on Windows XP or older with current Firefox builds.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Ioana, there appears to be nothing win2k-specific about this bug.  Please don't resolve bugs as wontfix based on their (bogus, automatically set by Bugzilla) OS field without actually trying to reproduce them.

Comment 9

[Ioana (away)]

Comment 0 specified clearly Win2k (see user agent) and I didn't see any other OSs specified in comments, it wasn't just the OS field.

Is there a specific OS you want this tested on?

Comment 10

[Boris Zbarsky [:bzbarsky]]

It doesn't matter what the UA string said, just like it doesn't matter what the Bugzilla OS field (populated from the UA string says).

For a bug like this, which is about basic DOM functionality, any OS should give the same behavior.

Comment 11

[Ioana (away)]

There is no editor on the testcase page when opened in Firefox 3.6, 4.0.1, 25 and 26 (later ones with the Remote XUL add-on).

Does anyone have a testcase where this issue can be reproduced?

Comment 12

[Martijn Wargers (dead)]

There is a permission denied error, because the testcase uses netscape.enablePrivilege.
Normally, you could set the security.turn_off_all_security_so_that_viruses_can_take_over_this_computer pref to true in about:config, then testcase should be testable, but I still get this permission denied error after that.

But I was able to test it this way, by installing this extension:
http://people.mozilla.org/~mwargers/extensions/[e-mail]
Then I moved the editor.xul file to the root of my hard drive (on Windows, it has to moved to file:///C:/testfiles/
Then I can access the editor.xul file from: chrome://testdirectory/content/editor.xul

This seems to be wfm in Firefox23 on my macbook pro.