Moving video only functions from MediaConduitInterface to VideoSessionInterface
Differential Revision: https://phabricator.services.mozilla.com/D20879
--HG--
extra : moz-landing-system : lando
Ordinarily, when a page doesn't explicitly specify its viewport dimensions using
a <meta> viewport tag, we treat is as a non-mobile-friendly desktop page and do
some special viewport handling.
For some document types however we might want to override that behaviour and
treat the page as if "<meta name="viewport" content="width=device-width>" had
explicitly been specified anyway.
Differential Revision: https://phabricator.services.mozilla.com/D20953
--HG--
extra : moz-landing-system : lando
Based on the current implementation of nsContentUtils::IsPlainTextType(), we
could just call that function again if we need to know whether we're
dealing with plain text content or not later on, but doing it this way ensures
we're always consistent with the current code in StartDocumentLoad(), which
includes some additional sanity checks.
Differential Revision: https://phabricator.services.mozilla.com/D20952
--HG--
extra : moz-landing-system : lando
I want to turn on word-wrapping for plain text documents on mobile. However
currently, these are rendered with the desktop viewport by default, leading to
still tiny font sizes and still having to scroll horizontally if you then
pinch-zoom in to achieve a readable font size.
While font inflation would solve that problem, the layout of plain text
documents is so simple that we can also just render them using a
"width=device-width" viewport instead.
This test will test that plain text documents will be rendered as they would
include a <meta name="viewport" content="width=device-width"> tag.
Differential Revision: https://phabricator.services.mozilla.com/D20951
--HG--
extra : moz-landing-system : lando
Especially in view of the patches for bug 1501665, which seem to have some-
what misunderstood the reason for the choice of viewport width here.
Differential Revision: https://phabricator.services.mozilla.com/D20950
--HG--
extra : moz-landing-system : lando
This is important to allow creating BrowsingContexts outside of the process
where they are going to be used. This is largely a re-arrangement of existing
code.
There is currently no way to do this type of attaching for browsing contexts in
existing BrowsingContextGroups, which creates some limitations, but happens to
be sufficient for us in the current situation.
Differential Revision: https://phabricator.services.mozilla.com/D21095
--HG--
extra : moz-landing-system : lando
Nearly all dependencies except moznetwork and moztest already
support Python3. Lets make those releases the minimum allowed
version.
Differential Revision: https://phabricator.services.mozilla.com/D22105
--HG--
extra : moz-landing-system : lando
Instead of trying to figure out which pointer is nullptr, add a more
powerful assertion. Since the nullptr already causes a crash, this won't
cause any regression.
Differential Revision: https://phabricator.services.mozilla.com/D22085
--HG--
extra : moz-landing-system : lando
We've implemented several fixes to upstream `winapi-rs` that are
necessary for other work. We might as well make our upstream branch
track upstream `winapi-rs` instead of keeping track of the cherry-picked
fixes that we need.
Differential Revision: https://phabricator.services.mozilla.com/D22008
--HG--
extra : moz-landing-system : lando
We can use this variant in cases where we don't know anything about the
provenant source of the check except its principal.
The principal may not be enough information in the future but at least
porting call sites to this variant will allow us to have a small number
of functions to extend in the future when we want to enable enabling
fingerprinting resistance in certain frames (e.g. third-party tracking
frames.)
Depends on D21990
Differential Revision: https://phabricator.services.mozilla.com/D21991
--HG--
extra : moz-landing-system : lando
in bug 1524862, the test checked against a pref value that was different between Nightly and Beta. it now checks for default values.
Differential Revision: https://phabricator.services.mozilla.com/D21938
--HG--
extra : moz-landing-system : lando
In bug 1264235 we have some indication that observed bugs with the
startup cache might have been resolved, but we don't really know
until we collect data. Collecting these stats will give us the
ability to have more certainty that the startup cache is functioning
correctly in the wild.
Differential Revision: https://phabricator.services.mozilla.com/D19573
--HG--
extra : moz-landing-system : lando
