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
These tests used to mock out the SiteDataManager to test only the UI for things
like removing site data or sorting. This bug breaks that possibility, because
the SiteDataManager no longer uses its internal data to remove site data but
delegates the logic to ClearSiteDataService.
I don't think it's a loss, that mocking was always a little weird.
Differential Revision: https://phabricator.services.mozilla.com/D18283
--HG--
extra : moz-landing-system : lando
These tests used to mock out the SiteDataManager to test only the UI for things
like removing site data or sorting. This bug breaks that possibility, because
the SiteDataManager no longer uses its internal data to remove site data but
delegates the logic to ClearSiteDataService.
I don't think it's a loss, that mocking was always a little weird.
Differential Revision: https://phabricator.services.mozilla.com/D18283
--HG--
extra : moz-landing-system : lando
re-enable many tests on windows 1803 due to invalid screen resolution whilst testing
Differential Revision: https://phabricator.services.mozilla.com/D19535
--HG--
extra : moz-landing-system : lando
This is a rollup of all the patches that have landed on the cedar project branch:
891252fdd0
Bug 1492475 - Part 1: Migrate most, if not all nsSearchService consumers to use async APIs. r=florian
79b2eb2367
Bug 1492475 - Part 2: Move nsIBrowserSearchService.idl to toolkit/components/search/nsISearchService.idl and update references. r=florian
a947d3cdf0
Bug 1492475 - Part 3: The search service init() method should simply return a Promise. r=florian
c1e172dfac
Bug 1492475 - Part 4: Remove the synchronous initialization flow. r=florian
cd41189eac
Bug 1492475 - Part 5: Since async initialization of the search service now is implicit behavior, remove the distinctive verbiage used internally. r=florian
2ae7189dfa
Bug 1492475 - Part 6: Update the cache build task to work with an actual Promise and re-initialize only once at the same time - all to fix race conditions here. r=florian
c8ee92973f
Bug 1492475 - Part 7: Make the region fetch not block the init flow, to ensure it's as fast as possible. r=florian
c44e674e16
Bug 1492475 - Part 8: Introduce an init flag, which can only be used privately, that allows to explicitly skip waiting for the region check process to complete. r=florian
6c79eaf1d3
Bug 1492475 - Part 9: Update unit tests to stop using 'currentEngine', in favor of 'defaultEngine'. r=Standard8
21b3aa17ee
Bug 1492475 - Part 10: Update unit tests to be fully aware of the new, async signatures of the search service API and remove sync init flow tests. r=mkaply,florian
ce5ba69019
Bug 1492475 - Part 11: Repair incorrect usage of the `identifier` property of nsISearchEngine instances. r=florian
fd177a7994
Bug 1518543 - Fix up the Android (Fennec) nsISearchService shim to work with the new asynchronous API. r=florian
3653d8ee22
Bug 1523708 - Change the search service interaction in the show-heartbeat action to use the new async API. r=florian
Differential Revision: https://phabricator.services.mozilla.com/D18355
--HG--
rename : netwerk/base/nsIBrowserSearchService.idl => toolkit/components/search/nsISearchService.idl
extra : moz-landing-system : lando
These tests used to mock out the SiteDataManager to test only the UI for things
like removing site data or sorting. This bug breaks that possibility, because
the SiteDataManager no longer uses its internal data to remove site data but
delegates the logic to ClearSiteDataService.
I don't think it's a loss, that mocking was always a little weird.
Differential Revision: https://phabricator.services.mozilla.com/D18283
--HG--
extra : moz-landing-system : lando
Uses a different profile depending on the install directory of the application.
installs.ini is used to map a hash of the install directory to a profile
directory.
If no profile is marked as default for the current install we use a heuristic
explained in the code to decide whether to use the profile that would have
been used before this feature.
The feature is disabled in snap builds where the install directory changes for
every version of the app, but multiple instances cannot share profiles anyway.
A boolean flag is used to turn on the feature because in a later patch we need
to be able to turn off the behaviour at runtime.
Includes code folded in from bug 1518634, bug 1522751, bug 1518632 and bug 1523024.
--HG--
extra : rebase_source : 0250c70e992fd8369e52ccee3755cf116a894791
extra : intermediate-source : e69cac07b209ad4ef4229815ffd8138ed64c348e
extra : source : e406bf0bcd665bd0e54ddb13d9ae880004badef1
Uses a different profile depending on the install directory of the application.
installs.ini is used to map a hash of the install directory to a profile
directory.
If no profile is marked as default for the current install we use a heuristic
explained in the code to decide whether to use the profile that would have
been used before this feature.
The feature is disabled in snap builds where the install directory changes for
every version of the app, but multiple instances cannot share profiles anyway.
A boolean flag is used to turn on the feature because in a later patch we need
to be able to turn off the behaviour at runtime.
Includes code folded in from bug 1518634, bug 1522751, bug 1518632 and bug 1523024.
--HG--
extra : rebase_source : b4608f6e8800af4f154daf0e0262f521c8ebd9fd
extra : intermediate-source : ba34b021c8e995ec7fc7c7fbb3dcc5dcf268278c
extra : source : e406bf0bcd665bd0e54ddb13d9ae880004badef1
Because custom elements will be constructed when DOM is constructed,
construct the DOM in the hidden panels will be expensive as we move
more and more widgets to custom elements from XBL.
This patch attempts to counter that by moving all the pane markups
into comment nodes, and use MozXULElement.parseXULToFragment() to
insert it when it is being asked.
They will be loaded lazily from an requestIdleCallback() in findInPage.js.
Differential Revision: https://phabricator.services.mozilla.com/D16787
--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
Because custom elements will be constructed when DOM is constructed,
construct the DOM in the hidden panels will be expensive as we move
more and more widgets to custom elements from XBL.
This patch attempts to counter that by moving all the pane markups
into comment nodes, and use MozXULElement.parseXULToFragment() to
insert it when it is being asked.
They will be loaded lazily from an requestIdleCallback() in findInPage.js.
Differential Revision: https://phabricator.services.mozilla.com/D16787
--HG--
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
