Right now, a XBL <constructor> runs before Custom Elements inside of its
<content> get upgraded. This leads to unexpected behavior where deck.selectedIndex = N
causes selectedIndex to get set as an expando property on the DOM node rather
than running the setter defined by the Custom Element.
Once the Custom Element does finally get upgraded, the selectedIndex getter and
setter don't get attached since there's an expando property with the same name.
This isn't a case we want to have to support from calling code. So this patch fixes
this one case by manually upgrading the element inside the constructor before
anything accesses the node. In Bug 1470242 we are planning to make this happen
behind the scenes so we don't need to do this for every CE inside of <content>.
MozReview-Commit-ID: 3D0QbOOJvDI
Right now, a XBL <constructor> runs before Custom Elements inside of its
<content> get upgraded. This leads to unexpected behavior where deck.selectedIndex = N
causes selectedIndex to get set as an expando property on the DOM node rather
than running the setter defined by the Custom Element.
Once the Custom Element does finally get upgraded, the selectedIndex getter and
setter don't get attached since there's an expando property with the same name.
This isn't a case we want to have to support from calling code. So this patch fixes
this one case by manually upgrading the element inside the constructor before
anything accesses the node. In Bug 1470242 we are planning to make this happen
behind the scenes so we don't need to do this for every CE inside of <content>.
MozReview-Commit-ID: LbXKKVeBYyQ
This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG