The OfflineAppCacheHelper was apparently introduced after the Sanitizer had been
forked for Fennec and so far nobody bothered to use it there as well.
MozReview-Commit-ID: 42Uk5hfvf9y
--HG--
rename : browser/modules/offlineAppCache.jsm => toolkit/modules/offlineAppCache.jsm
extra : rebase_source : b7010f732ca13583fd2b2c62102b4ea1c13a4cc6
This is the same approach used in the Windows panelUI.css
MozReview-Commit-ID: IiqbGK8zMdw
--HG--
rename : browser/themes/windows/customizableui/menu-arrow.svg => browser/themes/shared/customizableui/menu-arrow.svg
extra : rebase_source : 805beadc2dd6f2961cce3c4ea491bf64a9433bb4
site.principals is not always guaranteed to contain elements, only if
the site has quota storage or AppCache. This patch simplifies the function
to use hosts instead.
This patch fixes a bunch of intermittent/perma failures in sanitize-offlineData.js by:
- Ignoring localStorage for now. LocalStorage is cleared by sending an
observer notification. The flush often happens after several seconds, heavily
interfering with our own test or with subsequent tests. We can not reliably wait
on the operation to finish. Waiting for "domstorage-test-flushed" after calling
Sanitizer.sanitize() fixes the problem, but that notification is intermittently
not triggered for other unknown reasons, which makes it not really viable to use.
- Creating and checking indexedDB data in the chrome process (using SiteDataTestUtils).
- Cleaning up after running the test.
- Ignoring a stray NS_ERROR_ABORT that's hard to track down and doesn't seem to
do any damage right now.
I've also moved the ServiceWorker utility functions into SiteDataTestUtils,
which we're planning to use in all other browser tests that handle site data.
This was done using the script at:
bc5629735d/processors/add-task-async.jsm
MozReview-Commit-ID: KxuS9Cen87
--HG--
extra : rebase_source : c0028e0cd55ba1643610cd30c55c6f4bca7d6e58
extra : histedit_source : ebc84fdec9c2db6176632d62de4e7bdad2a7829d
Apparently BrowserTestUtils.removeTab(gBrowser.selectedTab) does not
close the ?discoTest tab, which causes the test to fail eventually.
See comment 6 of bug 1453163 for more details.
MozReview-Commit-ID: 3UgEaVW083i
--HG--
extra : rebase_source : b1d901a611c27a269fa8129f172cfdafb7f6d81c
The previous commit moved creating installers to be side effect of creating
packages. This makes the installer step not actually do anything. So remove the
step from automation.
Differential Revision: https://phabricator.services.mozilla.com/D864
--HG--
extra : rebase_source : 75b67a6e57031ae189dafe1d9854e4105aa22621
extra : source : fcb756834abbdbe0ae6e59a8cfdf39024f50a226
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 05fe935c1d2a9fbfeef786819bfe5913ed8ef862
extra : source : d6bf22099e2195dcb64c3c3d7700d3edd0850a3a
The previous commit moved creating installers to be side effect of creating
packages. This makes the installer step not actually do anything. So remove the
step from automation.
Differential Revision: https://phabricator.services.mozilla.com/D864
--HG--
extra : rebase_source : 174a366890da295634ef8971d0608ea60979f110
extra : histedit_source : 06fdd0e2ccb93f061ba5a40c2a4137eed9898916
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 2b28b9ff7196d12f4a188c8dddf750b9a5efac5b
extra : histedit_source : 9bc28891950ae8c226cfdefef6f8121ce0b51f58
Marionette is only built when ENABLE_MARIONETTE is defined, but
we unconditionally include its resources in Firefox' packaging
instructions. These resources ought to be guarded with the same
rule to actually make it possible to disable Marionette without
breaking the packaging.
We already do this on Fennec, see
mobile/android/installer/package-manifest.in:373.
MozReview-Commit-ID: 3s8e9sk6KGx
--HG--
extra : rebase_source : 2aa55172bfa1a77090fed37cb2b26fd6a7d27f07
These prefs are on by default now, and so there's no point in keeping them as
override prefs.
MozReview-Commit-ID: Gzs65oS9koD
--HG--
extra : rebase_source : 89d52f7992a0e87f60673f3b7bd6efad627fd040
