From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2+) Gecko/20010725 BuildID: 2001072503 When trying to access the outerHTML property for an object, Mozilla returns an undefined instead of the HTML code for the object. The innerHTML property appears to be working correctly. Reproducible: Always Steps to Reproduce: 1. Create an HTML element 2. Access the objects's outerHTML property. 3. Actual Results: JavaScript returned an "undefined" for the outerHTML property. Expected Results: JavaScript should have returned the HTML code of the requested tag. Here is sample code demonstrating the problem: <form enctype="multipart/form-data" method="post" action="test3.html" name="mainform" onsubmit="return false;" > <select name="list" size="1"> <option value="0" selected>1</option> <option value="1">2</option> <option value="2">3</option> <option value="3">4</option> <option value="4">5</option> </select><br> <input type="button" name="clickme" value="Click Me!" onclick="alert( document.mainform.list.outerHTML );"> </form>

johnny , this looks like serious problem can u please look in to this

looks like a invalid bug...

Element.outerHTML is not supported in mozilla, use element.innerHTML or the HTML DOM, WONTFIX.

verified

*** Bug 121303 has been marked as a duplicate of this bug. ***

Why not implementing outerHTML? I understand the feelings of Mozilla developers imitating technically inferior Internet Explorer. Mozilla has more general mechanisms (DOM level 2 and Mozilla extension createContextualFragment ) that make emulating outerHTML in Javascript quite straightforward (See http://webfx.nu/dhtml/ieemu/htmlmodel.html ) Unfortunately, only the web developer can turn on the emulation in his web pages. The end user cannot do anything. (Correct me if I am mistaken. I tried very hard). However, we are in a time where Mozilla 0.9.x/Netscape 6.x accounts for only 1 % of the hits in web servers. Commercial web servers, often developed by mediocre consultories, test only against Internet Explorer, which accounts for 95 % of the hits in web pages. They use IE extensions probably without even knowing that they are extensions. Worse even, most users do not know about Javascript. They simply see that Mozilla/Netscape 6 does not work with most commercial web sites. So they use IE. Furthermore, implementing outerHTML in Mozilla is quite straightforward using the same method for emulating it from javascript. (See the web page cited above). For all these reasons, I respectfully request you to implement outerHTML.

*** Bug 158871 has been marked as a duplicate of this bug. ***

This is the best time to reconsider this bug. Now that document.all has been added it seems timely to "secretly" implement a few other IE extensions as well, including innerText, outerText, outerHTML and insertAdjacentHTML. This will make more existing pages work before Firefox hits 1.0. As Brendan said in Bug 248549, "We could even emulate other IE DOM level 0 quirks, but let's take this one step at a time, with much-appreciated evangelism help."

So...what's going to happen with this?

outerHTML is now in HTML5. http://dev.w3.org/html5/spec-author-view/apis-in-html-documents.html#outerhtml Seems like it's a good time to re-consider adding support. :)

Reopen per comment 14 http://dev.w3.org/html5/spec/apis-in-html-documents.html#outerhtml

Coping the whiteboard from Bug 312156.

This won't happen for Firefox 4 unless someone steps up to own this. Not blocking.

We should do this for the release after firefox 4. Ms2ger expressed some interest (or rather, I hassled him and he didn't say 'no' :) )

Attempting...

This will be easier to implement on top of bug 563322 and all its deps. (And implementing this without those would almost certainly conflict with those patches.)

(In reply to comment #20) > This will be easier to implement on top of bug 563322 and all its deps. Available from http://hg.mozilla.org/users/hsivonen_iki.fi/patches/file/cb1efab4a046

Any chance this can make FF6? Branching is in a week.

I'm certainly unable to get it fixed in time, and will probably have little time until July.

Comment on attachment 561994 [details] [diff] [review] WIP >+nsGenericHTMLElement::SetOuterHTML(const nsAString& aOuterHTML) >+{ >+ nsINode* parent = GetNodeParent(); >+ if (!parent) { >+ return NS_OK; >+ } >+ >+ if (parent->NodeType() == nsIDOMNode::DOCUMENT_NODE) { >+ return NS_ERROR_DOM_NO_MODIFICATION_ALLOWED_ERR; >+ } >+ >+ if (!parent->IsElement()) { >+ >+ } Assert that parent is document, and throw NO_MODIFICATION_ALLOWED_ERR >+ >+ if (GetOwnerDoc()->IsHTML()) { >+ nsCOMPtr<nsIDOMDocumentFragment> df; >+ nsresult rv = NS_NewDocumentFragment(getter_AddRefs(df), >+ GetOwnerDoc()->NodeInfoManager()); >+ NS_ENSURE_SUCCESS(rv, rv); >+ nsCOMPtr<nsIContent> fragment = do_QueryInterface(df); >+ nsContentUtils::ParseFragmentHTML(aOuterHTML, >+ fragment, >+ static_cast<nsIContent*>(parent)->Tag(), >+ static_cast<nsIContent*>(parent)->GetNameSpaceID(), >+ GetOwnerDoc()->GetCompatibilityMode() == >+ eCompatibility_NavQuirks, >+ PR_TRUE); >+ parent->ReplaceChild(fragment, this, &rv); Actually, if this is the last child of parent, could we use html5 parser to parse to the context node (==parent)? That should be faster than parsing to fragment and moving fragment to document. >+ return rv; >+ } >+ >+ nsCOMPtr<nsIDOMDocumentFragment> df; >+ nsresult rv = nsContentUtils::CreateContextualFragment(parent, >+ aOuterHTML, >+ PR_TRUE, >+ getter_AddRefs(df)); >+ NS_ENSURE_SUCCESS(rv, rv); >+ nsCOMPtr<nsINode> fragment = do_QueryInterface(df); >+ return NS_OK; And do something to fragment?

Ping?

It doesn't look like I actually find time to finish this, sorry.

Henri, could you perhaps take this? If not, assign this to me.

OK.

Should I continue to keep the authorship data separate for the two parts or should I just qfold these?

Just fold them

Folded them.

Comment on attachment 573431 [details] [diff] [review] Implement outerHTML >+nsGenericHTMLElement::SetOuterHTML(const nsAString& aOuterHTML) >+{ >+ if (parent->IsElement()) { >+ localName = static_cast<nsIContent*>(parent)->Tag(); >+ namespaceID = static_cast<nsIContent*>(parent)->GetNameSpaceID(); parent->AsElement()->Tag() / parent->AsElement()->GetNameSpaceID(), perhaps.

Comment on attachment 573431 [details] [diff] [review] Implement outerHTML > NS_IMETHOD GetInnerHTML(nsAString& aInnerHTML); > NS_IMETHOD SetInnerHTML(const nsAString& aInnerHTML); >+ NS_SCRIPTABLE NS_IMETHOD GetOuterHTML(nsAString& aOuterHTML); >+ NS_SCRIPTABLE NS_IMETHOD SetOuterHTML(const nsAString& aOuterHTML); Drop NS_SCRIPTABLE >+[scriptable, uuid(5247a06f-50ba-450e-8370-d10516fb9d59)] > interface nsIDOMHTMLElement : nsIDOMElement You need to update uuid of all other html elements. update-uuids script should be useful for that. http://people.mozilla.org/~sfink/uploads/update-uuids No need to ask review for that change. Could you file a followup to get rid of that body element creation in XML case.

(In reply to Olli Pettay [:smaug] from comment #35) > Comment on attachment 573431 [details] [diff] [review] [diff] [details] [review] > Implement outerHTML > > > NS_IMETHOD GetInnerHTML(nsAString& aInnerHTML); > > NS_IMETHOD SetInnerHTML(const nsAString& aInnerHTML); > >+ NS_SCRIPTABLE NS_IMETHOD GetOuterHTML(nsAString& aOuterHTML); > >+ NS_SCRIPTABLE NS_IMETHOD SetOuterHTML(const nsAString& aOuterHTML); > Drop NS_SCRIPTABLE Done. > >+[scriptable, uuid(5247a06f-50ba-450e-8370-d10516fb9d59)] > > interface nsIDOMHTMLElement : nsIDOMElement > You need to update uuid of all other html elements. > update-uuids script should be useful for that. > http://people.mozilla.org/~sfink/uploads/update-uuids > No need to ask review for that change. Done. Thanks for the review. Landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/0fb81504b0aa > Could you file a followup to get rid of that body element creation in XML > case. Good point. Filed bug 701338.

...and backed out due to Windows build breakage https://hg.mozilla.org/integration/mozilla-inbound/rev/b1eca63a0bd4

...and relanded: https://hg.mozilla.org/integration/mozilla-inbound/rev/14903b2f3f45 (With an NS_METHODIMP replaced with nsresult.)

The spec has moved from HTML5 to DOM Parsing: http://html5.org/specs/dom-parsing.html#outerhtml See http://www.w3.org/Bugs/Public/show_bug.cgi?id=11204

Started and MDN article for this property: https://developer.mozilla.org/en/DOM/element.outerHTML

(In reply to Marek Stępień :marcoos from comment #41) > Started and MDN article for this property: > https://developer.mozilla.org/en/DOM/element.outerHTML Do you feel this article is complete? Or is some information still missing?

I'd say it's ok as a Gecko documentation article now. There might be some non-Gecko browser quirks that still need to be documented and the mobile browser support table could be improved with IE/Opera/Webkit version numbers.

Here's some differences between browsers implementations that might be worth documenting: https://gist.github.com/1355781 And the actual test: http://kangax.github.com/jstests/outerHTML_test/

(In reply to Simon Charette from comment #44) > Here's some differences between browsers implementations that might be worth > documenting: > https://gist.github.com/1355781 > > And the actual test: > http://kangax.github.com/jstests/outerHTML_test/ The only bug mentioned on gist is that Opera doesn't escape > in an attribute value. If you run the test in Firefox, you see bug 573918. It's not clear that docs for outerHTML need to document these minor serialization bugs. (In reply to Janet Swisher from comment #42) > (In reply to Marek Stępień :marcoos from comment #41) > > Started and MDN article for this property: > > https://developer.mozilla.org/en/DOM/element.outerHTML > > Do you feel this article is complete? Or is some information still missing? Looks complete enough. (I edited it a bit.)

(In reply to Henri Sivonen (:hsivonen) from comment #45) > (In reply to Simon Charette from comment #44) > > Here's some differences between browsers implementations that might be worth > > documenting: > > https://gist.github.com/1355781 > > > > And the actual test: > > http://kangax.github.com/jstests/outerHTML_test/ > > The only bug mentioned on gist is that Opera doesn't escape > in an > attribute value. I haven't looked much into it. I remember there were few inconsistencies with outerHTML representation back in the days. Now that serialization is standardized and standard is being followed by implementors, I'm guessing things are a little less hectic.

In Firefox 11 (Linux), we now have the problem that accessing HTMLElement.prototype.outerHTML throws an error: "Could not convert JavaScript argument" We have code that does typeof HTMLElement.prototype.outerHTML for feature detection. This breaks such code. Is this on purpose? Should I file a bug?

As far as I know, throwing in that case is the correct behavior, per WebIDL spec. You're trying to access outerHTML with wrong 'this' object. Couldn't you use "outerHTML" in HTMLElement.prototype.

(In reply to Olli Pettay [:smaug] from comment #48) > Couldn't you use "outerHTML" in HTMLElement.prototype. Isn't that what I am doing?

typeof HTMLElement.prototype.outerHTML is not the same as "outerHTML" in HTMLElement.prototype

Ok, we can certainly do that.

Why do we need a secreview for this? This is just syntax sugar and doesn't expose any new capabilities to the web platform.