[Bug 23206] [Custom]: The base element queue doesn't prevent custom element processing running ahead of imports

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23206

--- Comment #1 from Dominic Cooney <dominicc@chromium.org> ---
Here's a stab at a more operational algorithm that I think might be feasible:

There is a DOCUMENT QUEUE.

Each document has a BASE ELEMENT QUEUE.

When the parser pops an Custom Element, frazzle the element.

Additionally, when a <link rel="import" ...> is inserted into a document,
frazzle that element too.

To frazzle ELEMENT:

If ELEMENT's owner document is not in DOCUMENT QUEUE:
  Insert ELEMENT's owner document into DOCUMENT QUEUE
If ELEMENT is not in owner document's BASE ELEMENT QUEUE:
  Insert ELEMENT into owner document's BASE ELEMENT QUEUE

At a microtask checkpoint:

For each DOCUMENT in DOCUMENT QUEUE:
  If DOCUMENT "is an import"*:
    Skip DOCUMENT
  Otherwise:
    Process DOCUMENT's BASE ELEMENT QUEUE

* Being an import is a dynamic condition. If the <link> tag that begot you
orphans you, you're not an import any more?

(I didn't do any DOCUMENT QUEUE emptying. The BEQs become empty so repeatedly
processing them is a no-op. But an implementation would remove a document that
has finished parsing from the DOCUMENT QUEUE.)

To process a BEQ:

For each ELEMENT in BEQ, in order:
  If ELEMENT is an IMPORT:
    If ELEMENT has an imported document:
      Process the ELEMENT's imported document's BEQ (ie recurse).
    If the ELEMENT's IMPORT READY FLAG is not set:
      Stop these steps. Commentary: Everything (including the link
      element) is left in BEQ for next time.
  Remove ELEMENT from the BEQ
  Process ELEMENT's associated CALLBACK QUEUE (if any)

Commentary:

There are complicating factors motivating this craziness:

- <link rel="import" ...> can be inserted and removed, bringing multiple
documents into existence as it does so (I think?) so we need the document queue
as a catch-all to make sure we eventually start calling people's callbacks.

- <link rel="import" ...> doesn't necessarily have an associated document, so
we need to use the link tags themselves to keep track of things.

The ordering is going to be defined, but extremely wild, if you move a link tag
(particularly to a different document.) The wildness if because we use a link
tag to find a document to recurse to, but that might not be the one begotten
from that insertion; time might have marched on? You get what you deserve.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 11 September 2013 06:52:39 UTC