Closed Bug 92264 Opened 19 years ago Closed 8 years ago

Support element.outerHTML property

Categories

(Core :: DOM: Core & HTML, enhancement)

enhancement
Not set

Tracking

()

RESOLVED FIXED
mozilla11
Tracking Status
blocking2.0 --- -

People

(Reporter: maznoe, Assigned: hsivonen)

References

(Blocks 2 open bugs, )

Details

(Keywords: dev-doc-complete, html5, testcase, Whiteboard: [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?])

Attachments

(2 files, 3 obsolete files)

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>
Attached file testcase
johnny , 
this looks like serious problem can u please look in to this
Status: UNCONFIRMED → NEW
Ever confirmed: true
looks like a invalid bug...
Element.outerHTML is not supported in mozilla, use element.innerHTML or the HTML
DOM, WONTFIX.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
verified
Status: RESOLVED → 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."

Duplicate of this bug: 368689
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
Duplicate of this bug: 454275
So...what's going to happen with this?
Duplicate of this bug: 464008
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
Status: VERIFIED → REOPENED
OS: Windows 98 → All
Hardware: x86 → All
Resolution: WONTFIX → ---
Summary: outerHTML returns undefined → Support element.outerHTML property
Coping the whiteboard from Bug 312156.
Keywords: html5
Whiteboard: [parity-webkit] [parity-IE] [parity-opera] [evang-wanted]
Assignee: jst → nobody
blocking2.0: --- → ?
Severity: normal → enhancement
Status: REOPENED → NEW
Keywords: testcase
This won't happen for Firefox 4 unless someone steps up to own this. Not blocking.
blocking2.0: ? → -
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' :) )
Whiteboard: [parity-webkit] [parity-IE] [parity-opera] [evang-wanted] → [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?]
Attempting...
Assignee: nobody → Ms2ger
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
Keywords: dev-doc-needed
Target Milestone: --- → mozilla6
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.
Whiteboard: [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?] → [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?][sr:dchan]
Whiteboard: [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?][sr:dchan] → [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?][secr:dchan]
Target Milestone: mozilla6 → ---
Attached patch WIP (obsolete) — Splinter Review
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.
Assignee: Ms2ger → nobody
Henri, could you perhaps take this? If not, assign this to me.
Assignee: nobody → hsivonen
OK.
Status: NEW → ASSIGNED
Attached patch Ms2ger's patch, rebased (obsolete) — Splinter Review
Attachment #561994 - Attachment is obsolete: true
Should I continue to keep the authorship data separate for the two parts or should I just qfold these?
Just fold them
Folded them.
Attachment #573226 - Attachment is obsolete: true
Attachment #573228 - Attachment is obsolete: true
Attachment #573431 - Flags: review?(bugs)
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.
Attachment #573431 - Flags: review?(bugs) → review+
(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.
Flags: in-testsuite+
Target Milestone: --- → mozilla11
...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.)
https://hg.mozilla.org/mozilla-central/rev/14903b2f3f45
Status: ASSIGNED → RESOLVED
Closed: 19 years ago8 years ago
Resolution: --- → FIXED
(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.
Depends on: CVE-2012-1946
Whiteboard: [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?][secr:dchan] → [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?][sec-assigned:dchan]
No longer depends on: CVE-2012-1946
Flags: sec-review?(dchan+bugzilla)
Why do we need a secreview for this? This is just syntax sugar and doesn't expose any new capabilities to the web platform.
Whiteboard: [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?][sec-assigned:dchan] → [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?]
Flags: sec-review?(dchan+bugzilla) → sec-review+
Depends on: 1358448
You need to log in before you can comment on or make changes to this bug.