The key here is to test the type of the variable declaration for being a
smartptr type, instead of testing the type of the variable _use_.
Differential Revision: https://phabricator.services.mozilla.com/D65581
--HG--
extra : moz-landing-system : lando
This should be less confusing. This is not supported outside of chrome:// or
user-agent stylesheets so we can name this however we want.
Differential Revision: https://phabricator.services.mozilla.com/D65605
--HG--
extra : moz-landing-system : lando
This also removes nsPrintJob::mFallbackDocTitle since there really is no point
in blindly calculating it ahead of time when we will virtually never use it,
and even if there was there's no reason to store in on the nsPrintJob given
that we create a new nsPrintJob every time we print!
Differential Revision: https://phabricator.services.mozilla.com/D65014
--HG--
extra : moz-landing-system : lando
Instead of just special-casing the eContextMenu and eMouseLongTap events in
PositionedEventTargeting, this adds a mechanism to suppress retargeting for
any events dispatched from a particular code block. This allows us to also
suppress retargeting the mousemove that precedes the eContextMenu, while still
retargeting any other mousemove events (e.g. the one that precedes a click).
Doing this is important because if the mousemove is retargeted, it can trigger
the hover pseudoclass CSS on an element when that element is not actually
going to be activated at all, and can be confusing to the user.
Depends on D65211
Differential Revision: https://phabricator.services.mozilla.com/D65212
--HG--
extra : moz-landing-system : lando
...and properly pixel-snap while at it, as otherwise my test would fail fuzzily.
Stroke() paints a stroke from the middle of the path, so it'll paint
one-half-of-the-width outside of the rect.
We need to deflate it by half the border width so that the stroke covers exactly
the area we want.
Differential Revision: https://phabricator.services.mozilla.com/D65422
--HG--
extra : moz-landing-system : lando
Checking ColumnSet's available block-size [1] makes no sense nowadays
because ColumnSet is an inner frame under ColumnSetWrapper. We should
check ColumnSetWrapper's available block-size instead.
Also, bump assertions count for 1015844.html on Android, which is a
crashtest having multicols.
[1] The comment was also misleading, which said it was checking
ColumnSet's "block-size", but it actually was checking available
block-size.
Differential Revision: https://phabricator.services.mozilla.com/D63385
--HG--
extra : moz-landing-system : lando
Checking ColumnSet's available block-size [1] makes no sense nowadays
because ColumnSet is an inner frame under ColumnSetWrapper. We should
check ColumnSetWrapper's available block-size instead.
[1] The comment was also misleading, which said it was checking
ColumnSet's "block-size", but it actually was checking available
block-size.
Differential Revision: https://phabricator.services.mozilla.com/D63385
--HG--
extra : moz-landing-system : lando
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
--HG--
extra : moz-landing-system : lando
Safe area insets can be changed dynamically (i.e. window is fullscreen and etc), so if it is updated, we have to re-parse CSS.
Differential Revision: https://phabricator.services.mozilla.com/D52512
--HG--
extra : moz-landing-system : lando
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
--HG--
extra : moz-landing-system : lando
Safe area insets can be changed dynamically (i.e. window is fullscreen and etc), so if it is updated, we have to re-parse CSS.
Differential Revision: https://phabricator.services.mozilla.com/D52512
--HG--
extra : moz-landing-system : lando
There were some callers in nsRangeFrame that were already not-null-checking.
All platforms have a native theme and should we add new ones they could use
nsBasicNativeTheme.
Differential Revision: https://phabricator.services.mozilla.com/D65169
--HG--
extra : moz-landing-system : lando
This allows testing much more easily.
There are some edge cases with native theme changes and such (ThemeChanged and
co assume there's only one theme per process). But I don't think they matter
much for our use cases.
Differential Revision: https://phabricator.services.mozilla.com/D65162
--HG--
extra : moz-landing-system : lando
The boxes can just poke at the prescontext theme like literally everything else.
Differential Revision: https://phabricator.services.mozilla.com/D65161
--HG--
extra : moz-landing-system : lando
Window space is not a sensible space for CSS points, as returned by
getBoxQuads, since the CSS points are relative to window origin and not the
layout origin. This new method is useful in paired calling patterns, where
the returned quads are further translated by the position of the document
node relative to the window origin. Later parts of this patch demonstrate
this calling pattern in a test.
Differential Revision: https://phabricator.services.mozilla.com/D52788
--HG--
extra : moz-landing-system : lando
This corresponds to the approach outlined in https://github.com/w3c/csswg-drafts/issues/4822
Specifically:
* Calling play() / pause() always triggers the "animation play state is being
overridden by the API" behavior (unless the method throws an exception).
* Setting the startTime or calling reverse() only triggers this override
behavior if it results in a change between a playState that is paused and a
playState that is not paused.
Differential Revision: https://phabricator.services.mozilla.com/D65100
--HG--
extra : moz-landing-system : lando
Previously, text input controls weren't font inflation containers simply by
virtue of being "display:inline" by default, which automatically makes them in-
eligible for becoming an inflation container.
As of bug 1539469 this has changed however - those <input> elements are now
"display:inline-block" by default, which with the current font inflation logic
turns them into font inflation containers.
This leads to a few problems:
1. The logic from bug 708175 (stop inflation if there is a size-constrained non-
inline frame in the chain from the current frame to their font inflation
container) is built on the assumption that the (possibly size-constrained)
form control itself isn't a font inflation container.
2. When form controls end up as font inflation containers themselves, they no
longer size themselves properly to match the size of their inflated
contents, because they are now subject to the AutoMaybeDisableFontInflation/
mInflationDisabledForShrinkWrap logic which ends up disabling font inflation
during the size calculation of the form control.
1.) means that we now inflate some text inputs that we didn't use to inflate
previously and 2.) means that every time we attempt to inflate a text input, we
end up with the text content being inflated, but the containig box being not and
therefore too small.
Because of this, as well as because
1. The introductory comment in nsFrame::IsFontSizeInflationContainer itself
mentions that form controls aren't expected to be inflation containers.
2. There is the precedent from bug 786946, where <select> elements were
specifically excluded from becoming font inflation containers when their
default display style was changed from "inline" to "inline-block".
all of this points towards having to specifically preclude <input> elements
from becoming font inflation containers as well.
Differential Revision: https://phabricator.services.mozilla.com/D64908
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
Philipp Zech
Boris Zbarsky
Mirko Brodesser
Emilio Cobos Álvarez
Sebastian Zartner
Mike Shal
Jonathan Watt
Kartikaya Gupta
Erik Nordin
Brian Birtles
Cameron McCormack
Ting-Yu Lin
Csoregi Natalia
Simon Giesecke
Tim Huang
Makoto Kato
Morgan Reschenberg
Brad Werth
Jan Henning
Hiroyuki Ikezoe
Razvan Maries
shindli