Chrome and Safari either disable this or handle it badly. We don't handle it great so disable it.
Although the document principal looks like it can change I think if that happened at minimum the presshell would be recreated, which creates the ZoomConstraintsClient so we shouldn't need to register to be notified if this changes.
The other option would be to implement support for prevent default of double taps and then have modify pdf.js (if it doesn't already prevent default ctrl wheel events).
Differential Revision: https://phabricator.services.mozilla.com/D109421
When a contentful paint occurs which doesn't come from Tick, we should
not generate a first-contentful-paint entry for it because
1) It violates the spec
2) It usually means some magical paints which we should not expose
to the web.
So this patches stop generating a contentful paint entry for that,
instead asking the next tick to generate the entry.
Depends on D107858
Differential Revision: https://phabricator.services.mozilla.com/D107859
This patch doesn't change behavior; it's just switching us between two
functions that do the same thing. (One is literally a trivial wrapper for the
other.)
We're using the new "InProcess" version of this API as a way of annotating
callsites that have been vetted as behaving properly in out-of-process iframes.
This callsite in nsPresContext.cpp is for some invalidation logic that we only
need to perform when the outer and inner document are part of the same display
list (i.e. part of the same process), as discussed in the adjacent
code-comment. It behaves just fine (doing nothing) if GetCrossDocParentFrame()
fails due to being in an out-of-process iframe.
Differential Revision: https://phabricator.services.mozilla.com/D109145
We shouldn't need mutation change notifications for print/preview changes as the static document bool looks to be set very early to document creation.
Differential Revision: https://phabricator.services.mozilla.com/D108731
This patch creates a new behavior for absolute positioned frames such
that if they have intrinsic size keywords (-moz-fit-content, min-content,
max-content) for their BSize and the margins are auto, instead of taking
as much space as possible, use the actual intrinsic BSize as the BSize.
Users can still use `auto` keyword to make it to fill the available
space.
This change is to align with the spec text for these intrinsic sizing
keywords at https://drafts.csswg.org/css-sizing/#valdef-width-min-content,
per the changes resolved on in https://github.com/w3c/csswg-drafts/issues/3973
This patch modifies the centering.html WPT, to expand the test
cases to test the centering functionalities for not only explicitly specified
height and width, but also the default size and width, in this case the
intrinsic sizing keywords.
Differential Revision: https://phabricator.services.mozilla.com/D106497
These APIs are entirely unused (aside from one usage in a test, which part 1 in
this patch series removed), so this patch shouldn't impact behavior at all.
Historical note: we briefly removed these APIs once before, in this commit:
https://hg.mozilla.org/mozilla-central/rev/c216ff19d690
...but we brought them back because we had a motivating use case at the time.
We don't have any such motivating use cases any more, though. So, this patch
here is essentially a modernized version of that older commit.
Differential Revision: https://phabricator.services.mozilla.com/D108148
Even with the above fixes, this is not enough to fix all the
invalidation issues, because frame update notifications arrive for the
proxies of the inner image, not for the frozen image.
The simpler thing to do here is sync-decoding for print preview like we
do for print documents.
I think imgRequestProxyStatic is the only thing that can suffer from
these issues (because other ImageOps users like image-orientation don't
create a fake proxy).
Depends on D108198
Differential Revision: https://phabricator.services.mozilla.com/D108199
We already have a pref for double tap to zoom with is already enabled by default so it's kind of awkward to add another pref.
Differential Revision: https://phabricator.services.mozilla.com/D107389
Bug 1357785 accidentally omitted the flag on the interface itself. This patch makes thing consistent to prevent potential confusion in feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D107742
Bug 1357785 accidentally omitted the flag on the interface itself. This patch makes thing consistent to prevent potential confusion in feature detection.
Differential Revision: https://phabricator.services.mozilla.com/D107742
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
This seems to match Chrome, and makes our fullscreen implementation more
consistent between desktop and mobile.
Do you know how to best test this? This repros in RDM, but all
fullscreen tests seem disabled on Android...
Differential Revision: https://phabricator.services.mozilla.com/D107365
UnionRectEdges() and UnionEdges() are equivalent, and the later has a
modern interface with a shorter name. Let's remove the former.
Differential Revision: https://phabricator.services.mozilla.com/D107315
I'm not sure whether we should deal with ancestor scales and such. There
seemed to be a discussion about that in D77436 but dealing with
partially-3d-transformed content sounds like a massive pain. For now
this fixes the start point, which is a progression.
Differential Revision: https://phabricator.services.mozilla.com/D106896
I assume nsIFrame::IsAbsolutelyPositioned()'s callers really want to
check whether a frame is a real abspos frame, not just check a frame has
a abspos style. This could potentially change the behavior, but I feel
its the right thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D106580
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
This will prevent growing them when introducing fit-content(<length>).
This can _almost_ be derived, if it wasn't because of the quirky stuff.
I think the macro is probably good enough for now but let me know if you
disagree.
Differential Revision: https://phabricator.services.mozilla.com/D106713
Non-SHIP bfcache seems to be rather complicated here, since it needs to explicitly store inner windows and what not.
SHIP should be able to handle this in a simpler way.
It is possible that some ordering needs still tweaking.
Differential Revision: https://phabricator.services.mozilla.com/D105360
Timothy Nikkel
Sean Feng
Florian Quèze
Olli Pettay
Daniel Holbert
Emilio Cobos Álvarez
Simon Giesecke
Botond Ballo
Bas Schouten
Steven MacLeod
Hiroyuki Ikezoe
Andrew Halberstadt
Steve Fink
Kagami Sascha Rosylight
Dorel Luca
Ting-Yu Lin
Butkovits Atila
Micah Tigley
Mats Palmgren
Brindusan Cristian
Mihai Alexandru Michis