Last Comment Bug 434998 - contentDocument.execCommand gives error in <editor> FF3 RC1 (NS_ERROR_FAILURE)
: contentDocument.execCommand gives error in <editor> FF3 RC1 (NS_ERROR_FAILURE)
: dev-doc-complete
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: All All
: -- critical (vote)
: mozilla8
Assigned To: :Ehsan Akhgari (busy, don't ask for review please)
: 671248 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2008-05-21 04:50 PDT by Per-Kristian Nordnes (skogsmaskin)
Modified: 2011-10-17 14:27 PDT (History)
9 users (show)
ehsan: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

A test XUL file. Please put it in chrome. (1.63 KB, application/vnd.mozilla.xul+xml)
2008-05-22 11:00 PDT, Per-Kristian Nordnes (skogsmaskin)
no flags Details
Testcase using commandManager (1.59 KB, application/vnd.mozilla.xul+xml)
2008-05-28 08:59 PDT, Peter Van der Beken [:peterv]
no flags Details
Patch (v1) (6.15 KB, patch)
2011-07-14 15:50 PDT, :Ehsan Akhgari (busy, don't ask for review please)
roc: review+
Details | Diff | Review

Description Per-Kristian Nordnes (skogsmaskin) 2008-05-21 04:50:37 PDT
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; nb-NO; rv:1.9) Gecko/2008051202 Firefox/3.0
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; nb-NO; rv:1.9) Gecko/2008051202 Firefox/3.0

I'm updating my extension for Firefox 3, and I have a XUL editor, where 
xulEditor.contentDocument.queryCommandState('bold') now fails and gives the following error:

Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMNSHTMLDocument.queryCommandState]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"

Worked fine in Firefox 2. Can't seem to get around this. Any ideas?

Reproducible: Always

Steps to Reproduce:
1. Set up a XUL editor field in chrome.
2. Try to query the commandstate within the editing document using xulEditor.contentDocument.queryCommandState('bold')
Comment 1 Per-Kristian Nordnes (skogsmaskin) 2008-05-22 11:00:22 PDT
Created attachment 322137 [details]
A test XUL file. Please put it in chrome.
Comment 2 Mark Finkle (:mfinkle) (use needinfo?) 2008-05-27 06:29:17 PDT
I can confirm that this worked in 1.9b2pre, but does not work in latest 1.9pre
Comment 3 Mark Finkle (:mfinkle) (use needinfo?) 2008-05-27 06:30:21 PDT
Per-Kristian - a narrowed regress range would be helpful. See if you can find the Firefox nightly that started throwing exceptions.
Comment 4 Per-Kristian Nordnes (skogsmaskin) 2008-05-27 06:35:31 PDT
Thank you for the confirmation mfinkle, I'll see if I can find it.
Comment 5 Per-Kristian Nordnes (skogsmaskin) 2008-05-27 07:37:25 PDT
It happened in
Comment 6 Per-Kristian Nordnes (skogsmaskin) 2008-05-27 13:30:40 PDT
mfinkle found out that <browser> doesn't have these problems, so a temporary workaround is to user browser instead of editor. Then in order to get <editor> stuff:

var myBrowser = document.getElementById('myBrowser');
var editingSession = myBrowser.webNavigation.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIEditingSession);
myBrowser.contentDocument.designMode = 'on';
var editor = editingSession.getEditorForWindow(myBrowser.contentWindow);
var commandManager = myBrowser.webNavigation.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsICommandManager);
var htmlEditor = editor.QueryInterface(Components.interfaces.nsIHTMLEditor);

Works for now, until this bug is fixed.
Comment 7 Mark Finkle (:mfinkle) (use needinfo?) 2008-05-27 13:58:16 PDT
For some reason the mEditingState is set to eOff when checked here:

I'm not sure why yet.
Comment 8 Chris Pearce (:cpearce) 2008-05-27 16:16:35 PDT
Maybe this was caused by Bug 428844, which was checked in on 2008-04-17? That changed how we tore down the editor. The old editor is tore down before the new one is setup, maybe that's failing...
Comment 9 Peter Van der Beken [:peterv] 2008-05-28 04:53:37 PDT
mEditingState is eOff because SetDesignMode considers setting designMode='on' to be redundant for a document that is already editable, see Fixing this will probably require quite a bit of changes.

What does using an editor element with designMode="on" give that a simple editor element or a browser element with designMode="on" doesn't? Unless there's an important advantage I don't think this is a high priority bug.
Comment 10 Per-Kristian Nordnes (skogsmaskin) 2008-05-28 07:15:32 PDT
It has property commandManager, and methods getHTMLEditor and getEditor for instance.

But the critical point is that the editor element simply doesn't work for what it is designed for, to edit stuff. So all extensions and such using a <editor> will not work, and break stuff when it comes down to executing commands like bold, italic, link, etc. I can't see how that can not be critical?
Comment 11 Peter Van der Beken [:peterv] 2008-05-28 08:28:38 PDT
Executing commands like cmd_bold, ... with the commandManager is broken?
Comment 12 Peter Van der Beken [:peterv] 2008-05-28 08:59:18 PDT
Created attachment 322786 [details]
Testcase using commandManager

Using the commandManager works fine for me?
Comment 13 Per-Kristian Nordnes (skogsmaskin) 2008-05-28 14:20:01 PDT
Using commandManager like that works here too. But not contentDocument.execCommand (and similar calls) as it did before 2004-04-18.

Quote from

Once editable, the document can have special formatting and other HTML pieces added to it using the document.execCommand method:

    var editor = document.getElementById("myEditor");

    // toggle bold for the current selection
    editor.contentDocument.execCommand("bold", false, null);

I suppse it's not only my code that will suffer from this bug.
Comment 14 Rob Reid 2008-10-13 11:12:00 PDT
I have a similar problem in FF3 when trying to use execCommand on an iframe editor see This bug did not exist in FF1 or 2 and works in other browsers.
Comment 15 philippe sampont 2009-02-11 15:30:08 PST
Same error with Fx 3.1 on linux. 
But I have fixed the problem by adding contenteditable="true" in a HTML element of the content document.
Comment 16 :Ehsan Akhgari (busy, don't ask for review please) 2011-07-14 15:28:07 PDT
*** Bug 671248 has been marked as a duplicate of this bug. ***
Comment 17 :Ehsan Akhgari (busy, don't ask for review please) 2011-07-14 15:50:44 PDT
Created attachment 546023 [details] [diff] [review]
Patch (v1)

For <xul:editor>, the HTML document's mEditingState ended up being eOff, which effectively disables the execCommand API.  This patch is a simple fix for that.
Comment 18 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-07-14 18:11:42 PDT
Comment on attachment 546023 [details] [diff] [review]
Patch (v1)

Review of attachment 546023 [details] [diff] [review]:
Comment 19 :Ehsan Akhgari (busy, don't ask for review please) 2011-07-15 07:13:41 PDT
Comment 20 Mozilla RelEng Bot 2011-07-15 09:10:58 PDT
Try run for fe3b8f619f5c is complete.
Detailed breakdown of the results available here:
    success: 148
    warnings: 13
    failure: 2
Total buildrequests: 163
Comment 21 Eric Shepherd [:sheppy] 2011-10-17 14:27:03 PDT
This bug fix is noted here:

Note You need to log in before you can comment on or make changes to this bug.