As part of this bug, the global ExperimentManager will no longer be
exported from ExperimentManager.sys.mjs and will only be available as a
property on the ExperimentAPI.
Differential Revision: https://phabricator.services.mozilla.com/D248316
Previously if we opened about:preferences for the first time after
disabling studies or telemetry, the "Firefox Labs" entry would appear
briefly and disappear. Now we don't show the element initially if we
would have to hide it soon after because studies or telemetry are
disabled.
Differential Revision: https://phabricator.services.mozilla.com/D246999
Without this, in my testing with the previous patch, the scroll alignment on
the initial load of the settings page is incorrect, with the top of the
section being cut off. As this is the situation we care about (first load after
a browser update), fixing it seemed important.
I spent some time trying to work out why layout is changing - presumably
items above the "Browser Layout" section are either appearing or disappearing
in a way that races with the scroll. I could never reproduce on any loads other
than the first one. But then I realized the code here was overly complex and
that it would probably be nicer for items to appear in the middle of the view
rather than the top anyway. Yes, this means that sometimes the relevant header
is _still_ not _exactly_ in the middle, but that seems much less important.
Differential Revision: https://phabricator.services.mozilla.com/D241628
This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.
Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.
Differential Revision: https://phabricator.services.mozilla.com/D178232
This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.
Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.
Differential Revision: https://phabricator.services.mozilla.com/D178232
This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.
Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.
Differential Revision: https://phabricator.services.mozilla.com/D178232
This should fix the issue experienced by the reporter. It also pushes the
re-entrancy guard into the the 'init' method we define on gCategoryInits
objects, and removes the asynchronicity which was only there for fluent's sake.
Instead of blocking the insertion on fluent, which meant that for the in-page
find functionality we do N initializations and fluent passes, we make each of
the 2 consumers responsible for checking translation has completed. This means
find in page now just has 1 fluent pass, instead of N passes for N categories.
This should speed up the find in page initialization, and means initialization
of a category is now sync instead of async.
Differential Revision: https://phabricator.services.mozilla.com/D178232
Under Flatpak we cannot determine if the application is set as default handler
for http/https protocols and also the application cannot set the system defaults.
In order to avoid user confusion we hide the defaultBrowserBox which
under flatpak shows always: "Firefox is not your default browser" and the
"Make Default..." button does not make any change to the system.
Differential Revision: https://phabricator.services.mozilla.com/D170590
