Support element.outerHTML property

RESOLVED FIXED in mozilla11

Status

()

Core
DOM: Core & HTML
--
enhancement
RESOLVED FIXED
16 years ago
2 months ago

People

(Reporter: Matthew Aznoe, Assigned: hsivonen)

Tracking

(Blocks: 2 bugs, {dev-doc-complete, html5, testcase})

Trunk
mozilla11
dev-doc-complete, html5, testcase
Points:
---
Dependency tree / graph
Bug Flags:
sec-review +
in-testsuite +

Firefox Tracking Flags

(blocking2.0 -)

Details

(Whiteboard: [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?], URL)

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

16 years ago
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

16 years ago
Created attachment 43529 [details]
testcase

Comment 2

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

Updated

16 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

16 years ago
looks like a invalid bug...
Element.outerHTML is not supported in mozilla, use element.innerHTML or the HTML
DOM, WONTFIX.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX

Comment 5

16 years ago
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.

Comment 8

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

Comment 9

13 years ago
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."

Updated

11 years ago
Duplicate of this bug: 368689

Updated

9 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
Duplicate of this bug: 454275

Comment 12

9 years ago
So...what's going to happen with this?
Duplicate of this bug: 464008

Comment 14

7 years ago
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
Blocks: 568516
Coping the whiteboard from Bug 312156.
Keywords: html5
Whiteboard: [parity-webkit] [parity-IE] [parity-opera] [evang-wanted]
Assignee: jst → nobody

Updated

7 years ago
blocking2.0: --- → ?

Updated

7 years ago
Severity: normal → enhancement
Status: REOPENED → NEW

Updated

7 years ago
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' :) )

Updated

7 years ago
Whiteboard: [parity-webkit] [parity-IE] [parity-opera] [evang-wanted] → [parity-webkit][parity-IE][parity-opera][evang-wanted][wanted2.1?]
Attempting...
Assignee: nobody → Ms2ger
(Assignee)

Comment 20

6 years ago
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.)
(Assignee)

Comment 21

6 years ago
(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

Updated

6 years ago
Keywords: dev-doc-needed
Target Milestone: --- → mozilla6

Updated

6 years ago

Updated

6 years ago
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.
Keywords: sec-review-needed
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]

Updated

6 years ago
Target Milestone: mozilla6 → ---
Created attachment 561994 [details] [diff] [review]
WIP
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
(Assignee)

Comment 29

6 years ago
OK.
Status: NEW → ASSIGNED
(Assignee)

Comment 30

6 years ago
Created attachment 573226 [details] [diff] [review]
Ms2ger's patch, rebased
Attachment #561994 - Attachment is obsolete: true
(Assignee)

Comment 31

6 years ago
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?
Just fold them
(Assignee)

Comment 33

6 years ago
Created attachment 573431 [details] [diff] [review]
Implement outerHTML

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+
(Assignee)

Comment 36

6 years ago
(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
(Assignee)

Comment 37

6 years ago
...and backed out due to Windows build breakage
https://hg.mozilla.org/integration/mozilla-inbound/rev/b1eca63a0bd4
(Assignee)

Comment 38

6 years ago
...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
Last Resolved: 16 years ago6 years ago
Resolution: --- → FIXED

Comment 40

6 years ago
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

Comment 42

6 years ago
(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.

Comment 44

6 years ago
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/
(Assignee)

Comment 45

6 years ago
(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.)
(Assignee)

Updated

6 years ago
Keywords: dev-doc-needed → dev-doc-complete
(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

5 years ago
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.

Comment 49

5 years ago
(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

Comment 51

5 years ago
Ok, we can certainly do that.
Depends on: 750109
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]
Depends on: 750428

Updated

5 years ago
No longer depends on: 750109

Updated

5 years ago
Depends on: 750109
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?]

Updated

5 years ago
Flags: sec-review?(dchan+bugzilla) → sec-review+
Blocks: 816409

Updated

2 months ago
Depends on: 1358448
You need to log in before you can comment on or make changes to this bug.