Fluent strings load asynchronously, so some text will be empty until that
happens. Once the strings load the page will shift down as the elements
gain the height of the text. Ensure there's always text in the add-on
cards so their height won't change (or at least it's reduced) once
strings load.
Differential Revision: https://phabricator.services.mozilla.com/D23196
--HG--
extra : moz-landing-system : lando
Disabled plugin related tests.
Added `crashreporter` dependency for browser_restore_isAppTab.js.
Differential Revision: https://phabricator.services.mozilla.com/D25504
--HG--
extra : moz-landing-system : lando
It only works with "persisted" theme images, which no longer exist.
Differential Revision: https://phabricator.services.mozilla.com/D25451
--HG--
extra : rebase_source : 8d32e4ceb48ec8bde68e8b42dcf4e2f11c9d60fd
extra : histedit_source : 0bcbae928b6e1517eace567d1e00afc60321ea3c
We still don't have a great way to bundle localizations for built-in add-ons,
since our localization tools are not compatible with the WebExtension
localization format, and there's no way to fetch locales from language packs.
We used to have a fairly complicated mechanism for this which used localized
preference values, pointing to localized string bundle URLs, based on the
add-on ID and the property we wanted to localized. That seems needlessly
complicated at this point, so this patch just allows overrides in two specific
string bundles, one for toolkit, and one for app-specific extensions.
Differential Revision: https://phabricator.services.mozilla.com/D24623
--HG--
extra : rebase_source : 8faf2dee0886d42575c23d011d8bca93480ca6cd
extra : histedit_source : 65d25dcb96a74fb50c1a473075feea041852989d
Most of our tests disable SCOPE_SYSTEM add-ons, which are meant to have been
registered externally, but still rely on SCOPE_APPLICATION addons (i.e., the
default theme), which are meant to be part of the application.
We currently flag the built-in location as SCOPE_SYSTEM in some places and
SCOPE_APPLICATION in others, which leads to those add-ons not being available
to some tests that need them.
--HG--
extra : rebase_source : 3ded0123dc5d56e617624f53effb369084a7958c
extra : histedit_source : 28b7034608eb4c90ecbf41a14581a2ea14ba8e55
There are all sorts of random issues with rootURI sometimes not being set for
sourceBundle add-ons, or callers expecting sourceBundle to never be null. This
patch fixes all of those issues that I came across.
--HG--
extra : rebase_source : 70532631f4e1bbba11e4525237bcc9f2de327a1d
extra : histedit_source : 0d051ad9c53b1146c356c145a72040576beb7b52
The filePath property is used in error messages, and is expected to be a
string. Setting it to a nsIFile object makes those error messages inscrutable.
--HG--
extra : rebase_source : 842d05ac1eb7d1e449b40f111d900b838d884ba4
extra : histedit_source : a31300676a94131e8ae1736a757aca2905c4984f
We want add-ons in the built-in location, particularly the built-in themes, to
appear in the add-on manager so that users can enable and disable them. We
don't want them to be able to uninstall them, though, so this also prevents
users from uninstalling them.
Differential Revision: https://phabricator.services.mozilla.com/D24619
--HG--
extra : rebase_source : b532296087942331ec95a476b5d9bc05eae9c771
When attempting to fetch a local resource which doesn't exist, the fetch
promise rejects, causing the hasResource promise to reject. Since we don't
want hasResource to reject for nonexistent resources, we need to catch this
rejection and treat it as a nonexistent resource.
--HG--
extra : rebase_source : 51a90fc5825bd24d95e704b389e18e5805af9185
It's possible for the application install location to vary from session to
session, particularly when the same profile is used with multiple app
versions, or with both packed and unpacked builds. Resolving resource: URIs at
install time causes problems in those instances, since it will always point to
the inital app location.
Resolving the resource URIs at runtime solves this.
Differential Revision: https://phabricator.services.mozilla.com/D24617
--HG--
extra : rebase_source : 9597c34e7349e6f4a524027c2b041c497c5c6632
All of the consumers of this observer really want it to behave like a promise.
And, for the cases where the DB may or may not already be loaded when those
callers run, getting the logic correct is difficult.
This patch replaces the observer with a promise, and also delays the
resolution of that promise until any built-in add-ons registered during
XPIProvider startup have finished installing. This latter feature is currently
unused, but will be necessary after subsequent patches for code that relies
querying the default theme immediately after provider startup.
--HG--
extra : rebase_source : c9d39158bea0b850d52cbc296cf184a9b9bf10b4
This allows us to install built-in themes at startup only when they're new, or
have changed, without requiring special work from callers, and in particular
without requiring loading the add-on database when no changes are required.
--HG--
extra : rebase_source : 4a5260da24b963c168838cc40eed8e46393b2a7e
