Last Comment Bug 92264 - Support element.outerHTML property
: Support element.outerHTML property
Status: RESOLVED FIXED
[parity-webkit][parity-IE][parity-ope...
: dev-doc-complete, html5, testcase
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- enhancement with 10 votes (vote)
: mozilla11
Assigned To: Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01)
:
Mentors:
http://html5.org/specs/dom-parsing.ht...
: 121303 158871 368689 454275 464008 (view as bug list)
Depends on: CVE-2012-1946 750428
Blocks: html5 domparsing
  Show dependency treegraph
 
Reported: 2001-07-25 09:44 PDT by Matthew Aznoe
Modified: 2012-12-02 17:49 PST (History)
42 users (show)
dchanm+bugzilla: sec‑review+
hsivonen: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
testcase (441 bytes, text/html)
2001-07-25 10:17 PDT, Sivakiran Tummala
no flags Details
WIP (11.13 KB, patch)
2011-09-23 01:40 PDT, :Ms2ger (⌚ UTC+1/+2)
no flags Details | Diff | Splinter Review
Ms2ger's patch, rebased (11.18 KB, patch)
2011-11-09 09:17 PST, Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01)
no flags Details | Diff | Splinter Review
Additional changes on top of Ms2ger's patch (12.71 KB, patch)
2011-11-09 09:18 PST, Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01)
no flags Details | Diff | Splinter Review
Implement outerHTML (22.79 KB, patch)
2011-11-09 23:22 PST, Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01)
bugs: review+
Details | Diff | Splinter Review

Description Matthew Aznoe 2001-07-25 09:44:07 PDT
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>
Comment 1 Sivakiran Tummala 2001-07-25 10:17:13 PDT
Created attachment 43529 [details]
testcase
Comment 2 Sivakiran Tummala 2001-07-25 10:18:22 PDT
johnny , 
this looks like serious problem can u please look in to this
Comment 3 Sivakiran Tummala 2001-07-25 10:29:25 PDT
looks like a invalid bug...
Comment 4 Johnny Stenback (:jst, jst@mozilla.com) 2001-07-25 10:36:33 PDT
Element.outerHTML is not supported in mozilla, use element.innerHTML or the HTML
DOM, WONTFIX.
Comment 5 Sivakiran Tummala 2001-07-25 10:43:00 PDT
verified
Comment 6 Boris Zbarsky [:bz] 2002-01-22 22:05:22 PST
*** Bug 121303 has been marked as a duplicate of this bug. ***
Comment 7 Ramón García Fernández 2002-01-23 05:58:14 PST
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.
Comment 8 Wesha 2002-07-23 10:54:59 PDT
*** Bug 158871 has been marked as a duplicate of this bug. ***
Comment 9 Bamm Gabriana 2004-08-21 05:21:41 PDT
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."

Comment 10 Dave Townsend [:mossop] 2007-01-30 05:49:21 PST
*** Bug 368689 has been marked as a duplicate of this bug. ***
Comment 11 Dave Townsend [:mossop] 2008-09-08 13:19:15 PDT
*** Bug 454275 has been marked as a duplicate of this bug. ***
Comment 12 Susurrus 2008-09-08 14:49:58 PDT
So...what's going to happen with this?
Comment 13 Dave Townsend [:mossop] 2008-11-10 05:07:06 PST
*** Bug 464008 has been marked as a duplicate of this bug. ***
Comment 14 Paul Irish 2010-04-10 12:45:33 PDT
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. :)
Comment 15 Kohei Yoshino [:kohei] 2010-06-07 07:15:23 PDT
Reopen per comment 14
http://dev.w3.org/html5/spec/apis-in-html-documents.html#outerhtml
Comment 16 Kohei Yoshino [:kohei] 2010-06-07 10:55:45 PDT
Coping the whiteboard from Bug 312156.
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2010-07-29 18:17:16 PDT
This won't happen for Firefox 4 unless someone steps up to own this. Not blocking.
Comment 18 Jonas Sicking (:sicking) PTO Until July 5th 2010-11-19 13:59:49 PST
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' :) )
Comment 19 :Ms2ger (⌚ UTC+1/+2) 2011-03-12 13:12:05 PST
Attempting...
Comment 20 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-03-31 05:38:19 PDT
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.)
Comment 21 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-04-01 07:23:50 PDT
(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
Comment 22 Jonas Sicking (:sicking) PTO Until July 5th 2011-05-11 13:00:47 PDT
Any chance this can make FF6? Branching is in a week.
Comment 23 :Ms2ger (⌚ UTC+1/+2) 2011-05-12 13:01:59 PDT
I'm certainly unable to get it fixed in time, and will probably have little time until July.
Comment 24 :Ms2ger (⌚ UTC+1/+2) 2011-09-23 01:40:21 PDT
Created attachment 561994 [details] [diff] [review]
WIP
Comment 25 Olli Pettay [:smaug] 2011-10-09 04:02:39 PDT
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?
Comment 26 Olli Pettay [:smaug] 2011-10-26 14:28:20 PDT
Ping?
Comment 27 :Ms2ger (⌚ UTC+1/+2) 2011-10-29 06:15:41 PDT
It doesn't look like I actually find time to finish this, sorry.
Comment 28 Olli Pettay [:smaug] 2011-10-29 06:24:11 PDT
Henri, could you perhaps take this? If not, assign this to me.
Comment 29 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-10-29 07:09:49 PDT
OK.
Comment 30 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-11-09 09:17:25 PST
Created attachment 573226 [details] [diff] [review]
Ms2ger's patch, rebased
Comment 31 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-11-09 09:18:30 PST
Created attachment 573228 [details] [diff] [review]
Additional changes on top of Ms2ger's patch

Should I continue to keep the authorship data separate for the two parts or should I just qfold these?
Comment 32 :Ms2ger (⌚ UTC+1/+2) 2011-11-09 13:12:54 PST
Just fold them
Comment 33 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-11-09 23:22:20 PST
Created attachment 573431 [details] [diff] [review]
Implement outerHTML

Folded them.
Comment 34 :Ms2ger (⌚ UTC+1/+2) 2011-11-10 03:15:57 PST
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 35 Olli Pettay [:smaug] 2011-11-10 03:31:42 PST
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.
Comment 36 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-11-10 04:11:52 PST
(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.
Comment 37 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-11-10 04:52:11 PST
...and backed out due to Windows build breakage
https://hg.mozilla.org/integration/mozilla-inbound/rev/b1eca63a0bd4
Comment 38 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-11-10 05:02:04 PST
...and relanded:
https://hg.mozilla.org/integration/mozilla-inbound/rev/14903b2f3f45

(With an NS_METHODIMP replaced with nsresult.)
Comment 39 Marco Bonardo [::mak] (Away 6-20 Aug) 2011-11-11 02:14:24 PST
https://hg.mozilla.org/mozilla-central/rev/14903b2f3f45
Comment 40 Steffen Wilberg 2011-11-16 03:04:51 PST
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
Comment 41 Marek Stępień [:marcoos, inactive] 2011-11-21 15:38:10 PST
Started and MDN article for this property:
https://developer.mozilla.org/en/DOM/element.outerHTML
Comment 42 Janet Swisher 2011-12-15 15:32:41 PST
(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?
Comment 43 Marek Stępień [:marcoos, inactive] 2011-12-15 15:49:10 PST
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.
Comment 44 Simon Charette 2011-12-15 20:50:15 PST
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/
Comment 45 Henri Sivonen (:hsivonen) (Not doing reviews or reading bugmail until 2016-08-01) 2011-12-15 23:52:57 PST
(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.)
Comment 46 Juriy "kangax" Zaytsev 2011-12-16 10:42:24 PST
(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.
Comment 47 Marcus Better 2012-02-14 06:11:24 PST
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?
Comment 48 Olli Pettay [:smaug] 2012-02-14 06:17:03 PST
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.
Comment 49 Marcus Better 2012-02-14 06:19:16 PST
(In reply to Olli Pettay [:smaug] from comment #48)
> Couldn't you use "outerHTML" in HTMLElement.prototype.

Isn't that what I am doing?
Comment 50 Olli Pettay [:smaug] 2012-02-14 06:20:32 PST
typeof HTMLElement.prototype.outerHTML
is not the same as
"outerHTML" in HTMLElement.prototype
Comment 51 Marcus Better 2012-02-14 06:27:32 PST
Ok, we can certainly do that.
Comment 52 Jonas Sicking (:sicking) PTO Until July 5th 2012-08-15 16:43:23 PDT
Why do we need a secreview for this? This is just syntax sugar and doesn't expose any new capabilities to the web platform.

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