Limit calls to `inheritAttribute` when using `inheritedAttributes` helper with MozElement Custom Elements
Categories
(Toolkit :: UI Widgets, task, P5)
Tracking
()
Tracking | Status | |
---|---|---|
firefox68 | --- | fixed |
People
(Reporter: bgrins, Assigned: bgrins)
References
Details
Attachments
(1 file, 1 obsolete file)
+++ This bug was initially created as a clone of Bug #1527680 +++
In https://phabricator.services.mozilla.com/D19702#524381 Paolo pointed out that we could drop the caching added in Bug 1523429 (to prevent overriding attrs that were unchanged on the host but had changed on the child).
Once we add the helper in Bug 1527680 we could change the behavior such that inheritAttribute
is less smart, and the helper keeps track of when it needs to do a full sync (on initialization) vs only a changed attr (on attributeChangedCallback).
Updated•6 years ago
|
Comment 1•6 years ago
|
||
Comment 2•6 years ago
|
||
(In reply to alexander :surkov (:asurkov) from comment #1)
Created attachment 9050668 [details]
Bug 1528268 - rework Custom Elements inheritedAttributes, r=bgrins
I doesn't show any good perf numbers for about_preferences_basic [1] I hoped to get for checkbox pref regression bug 1532651, by getting rid of early access to DOM (which forces <label> binding constructed), but the patch might be useful for this bug.
Assignee | ||
Comment 3•6 years ago
|
||
This provides a flipped data structure based on the provided inheritedAttributes,
which looks like:
Object<selector, attrs_to_inherit_comma_separated>
To one that looks like:
Object<attr, Array<Array<selector, attr_to_inherit>>
This should improve performance because:
- We only fetch element at connectedCallback that actually will have attributes inherited.
- When an attribute changes we can quickly inherit only that one.
Assignee | ||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 5•6 years ago
|
||
Backed out 2 changesets (bug 1519502, bug 1528268) for Crashtest failures in toolkit/content/tests/chrome/test_popupincontent.xul. CLOSED TREE
Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=241127128&repo=autoland&lineNumber=4281
Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=904cc7903feb74eeb70b415403fa33f8df4c39ff
Backout:
https://hg.mozilla.org/integration/autoland/rev/90a95d56b18df1b2a658dd8b156486e31b3ee0ec
Assignee | ||
Updated•6 years ago
|
Comment 7•6 years ago
|
||
bugherder |
Comment hidden (Intermittent Failures Robot) |
Comment 9•6 years ago
|
||
Given this many regressions that QA found in Nightly, is there more testing we could ask for here? Any added automated tests?
Assignee | ||
Comment 10•6 years ago
|
||
(In reply to Liz Henry (:lizzard) (use needinfo) from comment #9)
Given this many regressions that QA found in Nightly, is there more testing we could ask for here? Any added automated tests?
A lot of these were duplicates of Bug 1546024, which did add automated test cases to toolkit/content/tests/chrome/test_custom_element_base.xul: https://hg.mozilla.org/mozilla-central/rev/4bc97c0629fa#l2.2. Bug 1545765 also added automated test cases to the same file: https://hg.mozilla.org/mozilla-central/rev/c9e14c54335a#l2.2.
Since this change was affecting the shared base class for our Custom Elements across the UI, the downside is that it's hard to point at any single place in the UI for additional manual testing. The upside is that the landed fixes apply across the entire UI. If we could get manual QA verification on all the regression bugs (even the ones that were duped), we should be in a pretty good place.
Updated•6 years ago
|
Description
•