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
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 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
These functions already specify the override keyword. This change also makes
them more consistent with the overloaded versions of the same functions in these
classes.
Depends on D21968
Differential Revision: https://phabricator.services.mozilla.com/D21975
--HG--
extra : moz-landing-system : lando
Bug 1352924 removed the usage of this class, so we can safely remove the dead
code.
Differential Revision: https://phabricator.services.mozilla.com/D21968
--HG--
extra : moz-landing-system : lando
Since bug 1524480 we set the NS_FRAME_MAY_BE_TRANSFORMED frame bit when needed
in RestyleManager::ProcessRestyledFrames so that it is now redundant to also set
it from KeyframeEffect.
Furthermore, setting frame bits from KeyframeEffect is a little fragile since it
depends on the life cycle of the KeyframeEffect which is independent of the
nsFrame. If we can avoid doing that, we probably should.
Differential Revision: https://phabricator.services.mozilla.com/D21885
--HG--
extra : moz-landing-system : lando
This patch uses the existing xpcshell test certificate infrastructure
(pycert/pykey) to manage the http2 test certificates (and gets rid of some uses
of nsIBadCertListener2 as a bonus).
Differential Revision: https://phabricator.services.mozilla.com/D21814
--HG--
rename : netwerk/test/unit/CA.cert.der => netwerk/test/unit/http2-ca.pem
rename : testing/xpcshell/moz-http2/http2-key.pem => testing/xpcshell/moz-http2/http2-cert.key
extra : moz-landing-system : lando
In order to display blocking icon when the document comes back from the bfcache, we have to notify front end what's the current blocking status.
As the front end side would clear blocking autoplay information when nagivation occurs, and the media might not invoke the play again when they comes back from the bfcache.
Therefore, we should notify front end side that the site is still being blocked, and we should show blocking icon for it.
Differential Revision: https://phabricator.services.mozilla.com/D21582
--HG--
extra : moz-landing-system : lando
By allowing the creation of StrongWorkerRefs in the Canceling state we
ensure that IPC will not fail and lead to crashes.
Differential Revision: https://phabricator.services.mozilla.com/D21920
--HG--
extra : moz-landing-system : lando
The test expects that video is visible. The test needs to wait until the video element becomes visible. And appending a video element to document with loading the test video triggered 'mozentervideosuspend' event. It caused the test failure.
Differential Revision: https://phabricator.services.mozilla.com/D21174
--HG--
extra : moz-landing-system : lando
Ehsan Akhgari
Brindusan Cristian
Jan Henning
Nika Layzell
Yaron Tausky
John Dai
Alex Gaynor
Jean-Yves Avenard
Lee Salzman
Boris Zbarsky
Bryce Van Dyk
Tim Nguyen
Bogdan Tara
Ciure Andrei
Luke Wagner
Jeff Walden
Razvan Maries
Andreea Pavel
Brian Birtles
Emilio Cobos Álvarez
Dana Keeler
Alastor Wu
sotaro