This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20491 - [Custom]: Need to actually define the upgrade algorithm so it's interoperably implementable
Summary: [Custom]: Need to actually define the upgrade algorithm so it's interoperably...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 17103
  Show dependency treegraph
 
Reported: 2012-12-22 00:45 UTC by Boris Zbarsky
Modified: 2013-04-10 20:49 UTC (History)
0 users

See Also:


Attachments

Description Boris Zbarsky 2012-12-22 00:45:53 UTC
Spec says:

>  "For each element ELEMENT in TREE whose custom element name is NAME: "

In what order?  What happens when the various events that fire during this algorithm trigger handlers that mutate TREE?

This thing needs to be very clearly defined.  As a start, I would recommend not firing any events until after all the other work is done.
Comment 1 Dimitri Glazkov 2013-01-12 00:38:14 UTC
(In reply to comment #0)
> Spec says:
> 
> >  "For each element ELEMENT in TREE whose custom element name is NAME: "
> 
> In what order? 

Good point, needs to be in tree order.

What happens when the various events that fire during this
> algorithm trigger handlers that mutate TREE?

Can you help me understand what you mean here? The algorithm does suppress observers currently (although this might not be the right thing). Which other events are you talking about it?

> 
> This thing needs to be very clearly defined.  As a start, I would recommend
> not firing any events until after all the other work is done.

If you're talking about elementreplace and elementupgrade events, I don't see any harm in them being fired after each upgrade?
Comment 2 Boris Zbarsky 2013-01-12 01:08:18 UTC
> Which other events are you talking about it?

Mutation events, for one thing. 

But also, suppressing mutation observers may well not be ok.  See the separate bug filed on that.

But most importantly, the elementreplace and elementupgrade events.

> I don't see any harm in them being fired after each upgrade?

Let me re-ask: What happens when the various events that fire during this algorithm trigger handlers that mutate TREE?
Comment 3 Dimitri Glazkov 2013-04-10 20:49:20 UTC
The spec has been updated to address this a while back.