Also removes the UA cache attached to nsILoadGroup and nsIRequestContext and the "http-on-useragent-request" observer notification.
If overriding the user agent is needed "http-on-modify-request" is equally usable (but should be used rarely, for performance reasons). A better way is using nsIDocShell.customUserAgent.
Depends on D14750
Differential Revision: https://phabricator.services.mozilla.com/D14751
--HG--
extra : moz-landing-system : lando
This patch removes the use of UserAgentOverrides from browser.js
The UA change when in desktop mode now uses nsIDocShell.customUserAgent, while the feature landed in bug 838332 that is only performed for t.co URLs is removed, as it landed 4 years ago and was limited to Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D14749
--HG--
extra : moz-landing-system : lando
The geckoview-junit tests make a few http requests to the server and in doing so
rely on robocop resources. This patch creates a junit-specific location in the test
package and uses those files instead.
Differential Revision: https://phabricator.services.mozilla.com/D45544
--HG--
extra : moz-landing-system : lando
Formerly this assertion for Firefox was added because it didn't work for Fennec,
and other mobile apps. Meanwhile we shouldn't have this hard restriction anymore,
given that no exception is thrown by the code when running with GeckoView based
app, and also the Thunderbird support would benefit from it.
As we know this method doesn't quit the GeckoView app, and geckodriver itself
has to ensure to gracefully/force stop the process on Android.
Differential Revision: https://phabricator.services.mozilla.com/D39811
--HG--
extra : moz-landing-system : lando
If the run task generates bad profile data, the merge step in the
profile-use task will fail. However, retrying the profile-use task
doesn't fix the problem, and there isn't a straightforward way to retry
the run task in this situation. Instead we can add a clang toolchain to
all the run tasks, and perform the merge there.
This means the output from the run task will always be a successfully
merged file called 'merged.profdata', and we no longer need to perform
the merge as part of the profile-use build as a GENERATED_FILES step.
Depends on D45262
Differential Revision: https://phabricator.services.mozilla.com/D45263
--HG--
extra : moz-landing-system : lando
The tp5 files were only ever used by fennec mochitest-chrome; they can
be safely removed now.
Differential Revision: https://phabricator.services.mozilla.com/D45066
--HG--
extra : moz-landing-system : lando
Adds overloads to GeckoSession.loadUri() that accept additional HTTP request headers
Differential Revision: https://phabricator.services.mozilla.com/D40951
--HG--
extra : moz-landing-system : lando
use more specific match patterns in the enhanced search experiment to improve performance and avoid test failures
Differential Revision: https://phabricator.services.mozilla.com/D45026
--HG--
extra : moz-landing-system : lando
Remove test manifest annotations that specifically target fennec,
or likely target the android 4.3 emulator.
Differential Revision: https://phabricator.services.mozilla.com/D45018
--HG--
extra : moz-landing-system : lando
This is not the minimal patch for this issue. The minimal patch is a
one-liner that adds `MOZ_ANDORID_MMA=1` to
mobile/android/config/mozconfigs/android-aarch64/nightly. However,
the underlying issue is that the mozconfigs have not stayed internally
consistent. To reduce the likelihood of a repeat of this
inconsistency, it would be best to extract the shared flags and reduce
duplication and the risk for inconsistent updates. There's two ways
to do that: teach `moz.configure` to have the correct defaults or
share some small stanza across mozconfigs. The former is non-trivial
and not worth the risk at this time. The latter is trivial but more
effort than this is worth. Here's something in the middle: making all
the mozconfigs have minimal differences with the mainline mozconfig
for `android-api-16`. This at least allows easy auditing of the
mozconfigs with `diff`.
Differential Revision: https://phabricator.services.mozilla.com/D44865
--HG--
extra : moz-landing-system : lando
We need this for host binaries to work correctly in the case where the
clang we're using is linking against a newer version of, say,
`libstdc++` than is on the system.
Differential Revision: https://phabricator.services.mozilla.com/D43529
--HG--
extra : moz-landing-system : lando
Assuming the URL string the JAR reader receives has been completely URL-encoded,
we need to decode not just the first nested jarUrl, as already happens through
getZipFile(), but all subsequent path components, too.
At least for jar:-URLs received from Gecko, the above assumption certainly seems
to be true.
Differential Revision: https://phabricator.services.mozilla.com/D44033
--HG--
extra : moz-landing-system : lando