The remaining uses all need adjustements to in-tree mozconfigs, so they
all need to be done at once.
However, to make things slightly more intelligible, we do this in two
steps. This is step 1: we modify the use_toolchain transform to take care of
the transformation, while keeping the task definitions intact, so that
we only deal with mozconfig and build script adjustements here.
Differential Revision: https://phabricator.services.mozilla.com/D41890
When working on GeckoView, there's no need to produce a Fennec APK.
This commit avoids doing that work at `mach package` time. There are
many other things we'd like to stop doing as we remove Fennec from the
tree, so we add a general flag to guard such things.
Depends on D41447
Differential Revision: https://phabricator.services.mozilla.com/D41448
--HG--
extra : moz-landing-system : lando
Converts zoom.maxPercent and zoom.minPercent to static prefs, which creates a new "zoom" category on StaticPrefList.yaml.
Differential Revision: https://phabricator.services.mozilla.com/D41835
--HG--
extra : moz-landing-system : lando
Converts font.size.inflation.minTwips, font.size.inflation.emPerLine, and font.size.inflation.mappingIntercept to static prefs and removes their associated functions from nsLayoutUtils. There are associated member variables in PresShell, but since documentation specified that these variables are set specifically to prevent changes to the cache from being read until page reload, I made the decision to leave these and set them to the static prefs.
Differential Revision: https://phabricator.services.mozilla.com/D41656
--HG--
extra : moz-landing-system : lando
Right now, there are a lot of things that race to complete before
Gecko creates or first reads the profile. One of those things is
extracting system addons (the `assets/features/` directory of the APK)
to disk, ready for the Gecko profile code to enumerate them.
Bug 1534451 added a non-trivial amount of background
computation during `onCreate`. This tickled the existing race
conditions such that system addon extraction frequently loses the
race, making system addons unreliable.
In addition, for reasons unknown, `PostUpdateHandler` did its work
during `onStart`. But the Gecko profile was created/first read
earlier, in `onCreate`. This widened the race window.
This commit pulls the update handler into `onCreate`, which is at
least early enough for it to have a chance of winning the race; and it
makes the work synchronous, which is the simplest way to ensure that
it is actually in place before Gecko startup (and profile
creation/first read). Since system addons are our "get out of jail"
card in many situations, the cost of extracting earlier seems like a
good trade-off. That is, I'm sure the early disk access will appear
in profiles, and it may even regress Raptor -- but it's a good
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D41687
--HG--
extra : moz-landing-system : lando
The main part of the change is the change to ChildSHistory - make it possible to have Go() to be called asynchronously
and also let one to cancel pending history navigations. History object (window.history) can then use either the sync or
async Go(), depending on the dom.window.history.async pref.
LoadDelegate, which is used by GeckoView, needs special handling, since
it spins event loop nestedly. With session history loads and same-document loads we can just
bypass it.
To deal with same-document case, MaybeHandleSameDocumentNavigation is split to IsSameDocumentNavigation,
which collects relevant information about the request and returns true if same-document navigation should happen,
and then later HandleSameDocumentNavigation uses that information to trigger the navigation.
SameDocumentNavigationState is used to pass the information around.
referrer-policy-test-case.sub.js is buggy causing tests to pass only on Firefox with sync history API.
nested-context-navigations-iframe.html.ini is added because of https://bugzilla.mozilla.org/show_bug.cgi?id=1572932
Differential Revision: https://phabricator.services.mozilla.com/D41199
--HG--
extra : moz-landing-system : lando
This also applies the error listener just to the Javadoc tasks
(previously, it applied to the `apiGenerate*` tasks as well, 'cuz they
inherit from `Javadoc`).
Differential Revision: https://phabricator.services.mozilla.com/D41634
--HG--
extra : moz-landing-system : lando
This changes provide basic support for webextenion tabs and webNavigation listeners by implementing missing objects on which Fennec implementation was relying.
Differential Revision: https://phabricator.services.mozilla.com/D36575
--HG--
extra : moz-landing-system : lando
This makes prefs definition simpler, more consistent, and less error-prone.
The patch also changes the form of the "not Android" condition to one used more
widely in all.js.
Differential Revision: https://phabricator.services.mozilla.com/D41299
--HG--
extra : moz-landing-system : lando
It seems like we can't quite decide whether the change log for a version should
grow top-down or bottom-up. hg blame and the numbering of references seems to
somewhat favour the latter, though.
Differential Revision: https://phabricator.services.mozilla.com/D40881
--HG--
extra : moz-landing-system : lando
This issue is race condition of Gecko thread and InputConnection thread.
When inputting `[ENTER]` in VKB, Switftkey generates keyboard event (down and up), then set empty span to current position.
It means that the following occurs.
1. Inserting CR by [ENTER] key event of Swiftkey.
2. Swiftkey sets empty span with current selection position. Then GV sets new selection with it due to adding span.
3. By 1., text and selection are updated, then GV receives new selection position by 1.
4. Selection notification by 2. is received, then selection is back to previous position unfortunately.
Although we should use 1 and 3's selection, GV uses 4's selection since this is last notification. But 2's selection is current selection until we don't update text. So it is unnecessary to set same selection again by 2.
Also, most IMEs don't send key event by 1, and they replace with new text without 1 and 2 So this issue occurs on Switftkey only.
Differential Revision: https://phabricator.services.mozilla.com/D40926
--HG--
extra : moz-landing-system : lando
It seems like we can't quite decide whether the change log for a version should
grow top-down or bottom-up. hg blame and the numbering of references seems to
somewhat favour the latter, though.
Differential Revision: https://phabricator.services.mozilla.com/D40881
--HG--
extra : moz-landing-system : lando
Oana Pop Rus
Nicholas Nethercote
Alvina Waseem
Brindusan Cristian
Mike Hommey
Nick Alexander
Kristen Wright
Agi Sferro
Ciure Andrei
Olli Pettay
Randall E. Barker
Andrei Lazar
Csoregi Natalia
Dylan Roeh
Narcis Beleuzu
Brad Arant
Cosmin Sabou
chrmod
Jan Henning
Eitan Isaacson
Botond Ballo
Eugen Sawin
Makoto Kato
Daniel Varga
Bogdan Tara