It was supposed to be doing this already, but we were instead removing _all_ text
nodes, which led the the "Learn More" link not showing up in popupnotifications
Differential Revision: https://phabricator.services.mozilla.com/D20379
--HG--
extra : moz-landing-system : lando
This allows elements to skip explicitly declaring `observedAttributes` and then imperatively
calling `inheritAttribute` on the appropriate child nodes. For simple cases this means less
boilerplate and moving this logic into the base class.
This is an opt-in feature, so more complex cases can continue to manually implement inheriting
behavior as before.
Differential Revision: https://phabricator.services.mozilla.com/D19702
--HG--
extra : moz-landing-system : lando
Move functionality out of XULDocument::AddElementToDocumentPost:
1) Convert all XUL link elements into HTML link elements which have
code to handle when they are added to the DOM.
2) Move handling of the end of a linkset element into nsXULElement's DoneAddingChildren callback.
3) Move document direction reset to where the root element is created.
Differential Revision: https://phabricator.services.mozilla.com/D19739
--HG--
extra : moz-landing-system : lando
This custom element replaces XBL <content> usage by directly prepend the two needed child nodes when the element is connected.
This is doable because
- There isn't any direct access of child nodes under <menulist>. Everyone seems to access via .menupopup, which is usually the only child.
- We don't need to move the children under <menulist>. If we need to and if the child is a <xbl:children> (which could happen if <menulist> is inside an XBL <content> that just get cloned to the document), the layout will get very confused and crash (see finding in bug 1514926)
Differential Revision: https://phabricator.services.mozilla.com/D16149
--HG--
rename : toolkit/content/widgets/menulist.xml => toolkit/content/widgets/menulist.js
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
In order to make the history easier to navigate, this changeset includes the
modifications required to make <xul:browser> actually work as a Custom Element,
and switches the app to use it instead of the XBL browser.
Differential Revision: https://phabricator.services.mozilla.com/D14911
--HG--
extra : moz-landing-system : lando
As part of the conversion, support for notificationsHidden and children that are not notifications is also removed.
Differential Revision: https://phabricator.services.mozilla.com/D10894
--HG--
rename : toolkit/content/widgets/notification.xml => toolkit/content/widgets/notificationbox.js
extra : rebase_source : 36a5412e1e9a9dc591fd486d1123c1f763a6f173
This provides a way to access specific element classes before any associated Custom Element is instantiated, without creating a new global for each class. This can be useful to access static methods, create derived classes in a page, or allow lazy custom constructors.
Differential Revision: https://phabricator.services.mozilla.com/D10893
--HG--
extra : rebase_source : 65516d2013410146b4ed372a965bd859621b74a5
This is another case of a document getting loaded before MainProcessSingleton,
similar to profile manager. There's another wrinkle here, though. The migration
UI can also be loaded _after_ startup (through Bookmarks manager), which is
actually the primary way this UI is surfaced. So we need to also handle customElements.js
getting loaded twice into the same window to avoid attempting to redefine everything.
Differential Revision: https://phabricator.services.mozilla.com/D9713
--HG--
extra : moz-landing-system : lando
There are two reasons for this:
1) It's faster than running the connectedCallback in the middle of document parse, at least for
<radiogroups> in about:preferences
2) It provides a construction sequence more similar to XBL, so the translation from XBL <constructor>
to CE connectedCallback is more likely to be correct. This is because when there is markup like:
<parent-ce><child-ce></child-ce></parent-ce>
the parent-ce node is empty during the first connectedCallback. If we wait for DOMContentLoaded
then the parent-ce has the child-ce node below it.
Differential Revision: https://phabricator.services.mozilla.com/D7944
--HG--
extra : moz-landing-system : lando
They are unnecessary for most every element, and we load multiple dummy.xul
documents even in clean profiles.
Differential Revision: https://phabricator.services.mozilla.com/D7112
--HG--
extra : moz-landing-system : lando
This prevents an exception in browser.xhtml when there's no head, since
it's currently sharing the markup with browser.xul.
Differential Revision: https://phabricator.services.mozilla.com/D6194
--HG--
extra : moz-landing-system : lando
Automatic changes by ESLint, except for manual corrections for .xml files.
Differential Revision: https://phabricator.services.mozilla.com/D4439
--HG--
extra : moz-landing-system : lando
Instead of `<xul:hbox class="textbox-input-box">`, consumers now should use
`<xul:moz-input-box />`. This covers the normal case and also handles
[spellcheck=true] while sharing much of the code within one class.
MozReview-Commit-ID: DjvT8sFq3SQ
--HG--
rename : toolkit/content/widgets/textbox.xml => toolkit/content/widgets/textbox.js
