373406 - Gecko ignores third (id) parameter in execCommand() when inserting elements

Status: NEW

(Core :: DOM: Editor, defect)

Description

[David D. Kilzer (ddk)]

Attachment: Test case demonstrating bug

Copied from WebKit Bugzilla comment number 3:

"The execCommands to insert these types of elements expect a string as the third argument execCommand((commandID, userInterface, value)), and use that argument to set the id of the inserted element.  At first I thought that FCKEditor might be omitting the value argument (which we support) since we turn omitted string arguments into "undefined", but then I found that FCKEditor is *actually* passing "undefined" for value.  The reason you don't see id="undefined" in FireFox is because they ignore the value parameter and don't use it to set the id of inserted elements, as per the spec."

I know this is a "Core" bug, but I wasn't sure which version of Gecko is included in Firefox 2.0.0.2.

Comment 1

[David D. Kilzer (ddk)]

Bug is still present in Minefield 3.0a3pre from 09-Mar-2007 06:07 AM.

Comment 2

[Phil Ringnalda (:philor)]

(In reply to comment #0)
> The reason you don't see
> id="undefined" in FireFox is because they ignore the value parameter and don't
> use it to set the id of inserted elements, as per the spec."

"the spec"? According to http://www.mozilla.org/editor/midas-spec.html inserthorizontalrule doesn't take a value. While there are certainly reasonable arguments for making it take one, and use it as the id, it's not an issue of spec-compliance, because http://msdn.microsoft.com/workshop/author/dhtml/reference/commandids.asp is not the spec Midas implements, just where they stole the names.

Comment 3

[FredCK]

(In reply to comment #2)
> (In reply to comment #0)
> > The reason you don't see
> > id="undefined" in FireFox is because they ignore the value parameter and don't
> > use it to set the id of inserted elements, as per the spec."
> 
> "the spec"? According to http://www.mozilla.org/editor/midas-spec.html
> inserthorizontalrule doesn't take a value. While there are certainly reasonable
> arguments for making it take one, and use it as the id, it's not an issue of
> spec-compliance, because
> http://msdn.microsoft.com/workshop/author/dhtml/reference/commandids.asp is not
> the spec Midas implements, just where they stole the names.
> 

Sorry Phil, but yours seams to be the easy answer for the problem. 

The implementation of execCommand in Firefox came to reflect IE's implementation, giving the same functionality to developers. The midas specs page you have referred is know to be poor of information, with sections clearly pointing to IE "standards": "This section needs to be written.  It can be called similarly to IE implementation.".

MS introduced execCommand with IE4, way before Mozilla ever thought to implement it. So, they are a de facto standard for it, I don't believe Mozilla wanted to propose a different implementation.

I know we like to go against MS, but their documentation regarding this feature is richer and developers will be happy to use that as the reference, and make it work in the same way in all browsers. Otherwise we'll continue with the useless browsers war that just bring troubles to our end users.

Comment 4

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

The current spec ignores the value parameter for insertHorizontalRule:

http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-inserthorizontalrule-command

This is a de jure standard, not de facto.  I could update the spec to require making the value work as an id, but why is it desirable?  It doesn't seem useful.  How often do you want an id on <hr>?

Comment 5

[FredCK]

I believe the point of having an id on <hr> is to be able to easily retrieve that <hr> for further processing right after the insertHorizontalRule call.

I'm not stating that I'm using that feature (in fact, CKEditor almost never uses execCommand now). I just find the above use case reasonable... and more than anything else, I'm advocating cross-browser compatibility.

Comment 6

[:ehsan akhgari]

I think the argument for cross-browser compat is a good one.  Also the use case in comment 5 makes sense to me.