There are domains that we give extra permissions.
Those should be hosted and operated by Firefox.
input.mozilla.org isn't and it also doesnt use extra permissions anymore.
Differential Revision: https://phabricator.services.mozilla.com/D13948
--HG--
extra : rebase_source : be9879b6f89ee6979975e697e052220fc839785e
extra : amend_source : 8a45cbbeadcda306313034ac22d6f43612780e3a
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D25406
--HG--
extra : moz-landing-system : lando
This autofill popover was being displayed in the incorrect place because the display rect we were providing to the `AutofillManager` was the rect for the `GeckoView` and not the rect for the HTML element that the autofill popover was relating to.
1. Add view dimensions to info passed to autofill in `GeckoViewAutoFill`.
2. Use those view dimensions to calculate the correct location on the screen using `pageToScreenMatrix` in `GeckoSession`.
The resulting locations were incorrect, as the values used by `pageToScreenMatrix` were out of date. The `GeckoSession` was only notified about updated metrics during first composite, which meant that when the metrics changed during zoom and scroll on soft keyboard presentation, `GeckoSession` was unaware of it.
3. Update `GeckoSession` with new screen metrics when they change and not only during first composite.
Despite this change ensuring that `GeckoSession` always had the correct values for the viewport size and location, the request to provide the autofill location was made before the zoom and scroll was complete, meaning that even then out of date values were used during the calculation. The intial solution was to fire an event once zoom was complete, but despite this event being fired after the new screen size had been calculcated in `AsyncCompositionManager`, `GeckoSession` did not receive the values until after the event had been processed (the calls were out by 0.024ms).
5. Call new method `onScreenMetricsUpdated` inside `SessionTextInput` after screen metrics have been updated. Call `AutofillManager#notifyViewEntered` from this function.
This was not my preferred solution to this, but timing issues meant I could not find/think of an alternative way of delaying the calculation of the autofill popover location until after `GeckoSession` had been updated.
This patch currently fixes things on GV apps. Occasionally, on Fennec, the autofill view is out of alignment slightly. This needs further work.
Differential Revision: https://phabricator.services.mozilla.com/D24397
--HG--
extra : moz-landing-system : lando
Skip mochitest-chrome test failing frequently on android/pgo. This directory of tests
only runs on Android 4.3, so the manifest annotation is simple.
Discussed in bug; see comment 17.
Differential Revision: https://phabricator.services.mozilla.com/D25274
--HG--
extra : moz-landing-system : lando
To prevent new buffer object from being created per frame, either
Sample.CREATOR has to keep track of all buffers from every remote codec,
or the client must memorize seen buffers and avoid asking for them again
and again. The former saves client code from modifications but complicates
the implementation of Sample, a data structure class, while the latter
requires changes to client code but avoid overcomplicating Sample.CREATOR
implementation.
The 2nd approach is taken:
- move SampleBuffer out of Sample, and update clients accordingly
- add a new IPC method for clients to get the buffers only when needed
Differential Revision: https://phabricator.services.mozilla.com/D24590
--HG--
extra : moz-landing-system : lando
Bug 1493317 enables AccessibleCaret in unit tests. No need to manually
flip the pref.
Differential Revision: https://phabricator.services.mozilla.com/D24963
--HG--
extra : moz-landing-system : lando
Also ensure that LightweightThemeManager.updateOneTheme() returns
even if the update request fails.
Differential Revision: https://phabricator.services.mozilla.com/D24981
--HG--
extra : moz-landing-system : lando
Bug 1533425 makes Gecko try to load from $ARCH/greprefs.js, etc on
Android. This patch teaches the packager to put preferences into
those architecture-specific locations for that code to find.
Differential Revision: https://phabricator.services.mozilla.com/D24984
--HG--
extra : moz-landing-system : lando
We really want GeckoView's single remote debugigng setting to
determine whether the engine can be remote controlled, but we're not
quite there yet. The devtools use an abstract UNIX socket for this
purpose, but Marionette uses a TCP socket that defaults to port 2828,
and that means we see cross-App clashes for that port.
Functionally this means that enabling Marionette reverts to the "old
method": either pass the "--marionette" command line argument or set
the `MOZ_MARIONETTE=1` environment variable to enable. Callers remain
responsible for ensuring that the Marionette port is available.
Differential Revision: https://phabricator.services.mozilla.com/D25138
--HG--
extra : moz-landing-system : lando
- Use Bengali (bn-BD) as base
- Keep amazon-in on Desktop (from bn-IN)
- Remove rediff (from bn-IN)
Differential Revision: https://phabricator.services.mozilla.com/D23480
--HG--
extra : moz-landing-system : lando
Although I change to use editor by previous fix of bug 676268, it is not
good for non-editable content. cmd_copy can support editable and non-editable.
GV already uses cmd_copy for this.
Differential Revision: https://phabricator.services.mozilla.com/D24642
--HG--
extra : moz-landing-system : lando
Kris Maglione
Noemi Erli
Chris Manchester
Oana Pop Rus
L10n Bumper Bot
Frederik Braun
Francesco Lodolo (:flod)
Emily Toop
Dorel Luca
Petru Lingurar
Csoregi Natalia
James Willcox
Geoff Brown
John Lin
Brindusan Cristian
Mark Banner
Botond Ballo
Ting-Yu Lin
Andrew Swan
Nick Alexander
Agi Sferro
Eugen Sawin
Ian Moody
Makoto Kato
Randall Barker