Open Bug 1079547 Opened 10 years ago Updated 2 years ago

HTML foster-parenting algorithm no longer requires foster parents to be elements

Categories

(Core :: DOM: HTML Parser, defect, P5)

Product:
Core
Component:
DOM: HTML Parser
Version:
35 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: adamk, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36

Steps to reproduce:

Consider the following HTML page:

<body>
  <table>
    <script>
      var fragment = document.createDocumentFragment();
      fragment.appendChild(document.querySelector('table'));
    </script>
    <div></div>
  </table>
</body>

According to the current HTML spec, this should end up foster-parenting the <div> into the document fragment (since it's the <table>'s parent when the foster-parenting algorithm runs). But the spec used to require foster parents to be elements, and so Firefox puts the div, instead, as a child of <body>.

In Blink, I'm about to land https://codereview.chromium.org/640433002, which changes that behavior to match the spec (it was changed to support the <template> element, according to Hixie on #whatwg). It'd be nice to keep us compatible, so if you think this is the wrong way to go, please let me know. Alternatively, it should be easy to update your parser to match the spec (see step 2 of https://html.spec.whatwg.org/#appropriate-place-for-inserting-a-node).
OS: Linux → All
Hardware: x86_64 → All
Summary: HTML foster-parenting algorithm no longer requires → HTML foster-parenting algorithm no longer requires foster parents to be elements
Component: Untriaged → HTML: Parser
Product: Firefox → Core

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.