Rather than aborting adding data, we set the history items to have the current date/time. This seems mildly better than throwing away the history data.
Differential Revision: https://phabricator.services.mozilla.com/D17830
--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
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
assertIn(el, list) should be favored over assertTrue(el in list),
which gives clear details about what is different.
Differential Revision: https://phabricator.services.mozilla.com/D8857
--HG--
extra : moz-landing-system : lando
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d
This lets us use Services.xulStore instead of requiring
Cc["@mozilla.org/xul/xulstore;1"].getService(Ci.nsIXULStore);
MozReview-Commit-ID: 2eXifCPhlGs
--HG--
extra : rebase_source : c65b9395cc192d05d1a348cfbf92f7f59d41dc8f
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
Patch originally by Ganesh, updated by Standard8
MozReview-Commit-ID: AihTLo5OyK1
--HG--
extra : rebase_source : f5a886326dd7f2fb2dba3309199ef277affe6b77
When bug 1433324 made these tests run against activity stream, it made the notification
fire from the test's head.js file itself. Unfortunately, that races with the new tab / home
page actually loading, triggering an `onLocationChange` event in the tabbrowser, which
removes the notification again, meaning it is then no longer there when the test expects
it to be.
This wasn't an issue before, because the notification bar was opened via a message from
within the new tab page, which always arrived after the `onLocationChange` event.
Because the current state is temporary anyway, I'm just changing the test to open 2 tabs
first, and then opening the notification bars, which in practice guarantees this happens
after the `onLocationChange` event.
MozReview-Commit-ID: LOzgjrZBp0H
--HG--
extra : rebase_source : 10568c1ad97b03143d79b2d967ccac42550000a6
