The idea of these are not to penalize legit uses of scroll anchoring, and
catching pathological cases fast.
The current algorithm I thought of is just whether the average of all the
consecutive scroll anchoring adjustments is less than a given threshold.
If the average adjustment is close to zero and the user is not scrolling, it
means that we're not making much progress.
It is important that zero adjustments don't get counted, since those are common
during window resizes and don't have side-effects anyway.
Exact number may need tuning, let me know if you want it
nightly-and-early-beta-only for now or something.
Depends on D51038
Differential Revision: https://phabricator.services.mozilla.com/D51024
--HG--
extra : moz-landing-system : lando
Split off of Bug 1590894
Rename these to support unprefixed version
Also add alias to keep compatibility
Differential Revision: https://phabricator.services.mozilla.com/D50989
--HG--
extra : moz-landing-system : lando
font-inflation-1e.html is adapted from font-inflation-1a.html with the
writing-mode set on <html> instead of <body>. It can trigger the
assertion "current writing mode should match that of our flow root" in
nsFontInflationData::FindFontInflationDataFor().
The root cause is: nsCanvasFrame can generate the position:absolute
custom content container to contain elements like AccessibleCaret. When
the container is constructed, the container's writing-mode is always
horizontal-rl, which is getting from nsCanvasFrame that uses
ViewportFrame's style.
If <html> has a vertical writing-mode, custom content container's used
mWritingMode becomes orthogonal to ViewportFrame, because <html>'s used
mWritingMode is propagated all the way up to ViewportFrame.
This patch solves the above issue by making the custom content container
a font inflation root, so FindFontInflationDataFor() stops at it instead
of finding all the way up to the ViewportFrame.
Differential Revision: https://phabricator.services.mozilla.com/D48942
--HG--
extra : moz-landing-system : lando
Currently, `nsFrameSelection::CommonPageMove()` is called before every caller
calls `nsFrameSelection::ScrollSelectionIntoView()`. However, when an editing
host has focus, the scroll target may be outside of it. In such case, without
moving caret, user may want only to scroll the scrollable element.
Chrome behaves like so. Chrome also can scroll outside scrollable element
of focused editing host. However, it scrolls caret into view only when
caret is moved actually. Therefore, it makes sense to follow this behavior.
This patch makes `nsFrameSelection::CommonPageMove()` also call
`nsFrameSelection::ScrollSelectionIntoView()`. However, it newly takes
`SelectionIntoView` flag for making callers can choose the condition. I.e.,
`ScrollSelectionIntoView()` should be called always, or only when selection
is actually changed, or shouldn't be called.
Differential Revision: https://phabricator.services.mozilla.com/D50178
--HG--
extra : moz-landing-system : lando
`nsFrameSelection::CommonPageMove()` emulates click in selection limiter
when scrollable frame is outside of focused editing host. However, the
clicked position should be considered with scrollable element's page
scroll amount rather than height of editing host since the height may be
much taller than the scrollable frame.
Differential Revision: https://phabricator.services.mozilla.com/D50177
--HG--
extra : moz-landing-system : lando
Currently, `nsFrameSelection::CommonPageMove()` is called before every caller
calls `nsFrameSelection::ScrollSelectionIntoView()`. However, when an editing
host has focus, the scroll target may be outside of it. In such case, without
moving caret, user may want only to scroll the scrollable element.
Chrome behaves like so. Chrome also can scroll outside scrollable element
of focused editing host. However, it scrolls caret into view only when
caret is moved actually. Therefore, it makes sense to follow this behavior.
This patch makes `nsFrameSelection::CommonPageMove()` also call
`nsFrameSelection::ScrollSelectionIntoView()`. However, it newly takes
`SelectionIntoView` flag for making callers can choose the condition. I.e.,
`ScrollSelectionIntoView()` should be called always, or only when selection
is actually changed, or shouldn't be called.
Differential Revision: https://phabricator.services.mozilla.com/D50178
--HG--
extra : moz-landing-system : lando
`nsFrameSelection::CommonPageMove()` emulates click in selection limiter
when scrollable frame is outside of focused editing host. However, the
clicked position should be considered with scrollable element's page
scroll amount rather than height of editing host since the height may be
much taller than the scrollable frame.
Differential Revision: https://phabricator.services.mozilla.com/D50177
--HG--
extra : moz-landing-system : lando
I discovered this while improving `ScrollFrameHelper::IsPhysicalLTR()`
in Part 1. Our code base needs a notion of physical direction. Let's add
it to WritingMode.
Differential Revision: https://phabricator.services.mozilla.com/D49818
--HG--
extra : moz-landing-system : lando
After bug 1102175, the root scroll frame always obtains its used
WritingMode from either body element or root element. The `if (mIsRoot) {}`
block in `GetFrameForDir()` becomes redundant, so does
`GetFrameForDir()` itself.
Differential Revision: https://phabricator.services.mozilla.com/D49817
--HG--
extra : moz-landing-system : lando
This patch:
- Gives layout/generic/AnonymousContentKey.h an include for `<stdint.h>` to
provide the uint8_t type, and TypedEnumBits.h to provide the
MOZ_MAKE_ENUM_CLASS_BITWISE_OPERATORS macro. (This is a change in another
directory, but it's needed in order for layout/style/ServoStyleSet.cpp to
build successfully.)
- Adds a missing "nsINode" forward-decl to dom/base/IdentifierMapEntry.h,
because it uses that type in function declarations. (This change is needed
in order for layout/style/CachedInheritingStyles.cpp to build successfully.)
- Gives CSSStyleRule.cpp an include for PseudoStyleType.h,
nsCSSPseudoElements.h, and CSSEnabledState.h because it uses those types.
- Gives GeckoBindings.cpp an include for gfxTextRun.h, to provide the definition
of type gfxFontGroup (so GeckoBindings can call GetFirstValidFont() on an
object of that type).
- Gives Loader.h an include for nsIContentInlines.h, to provide the inline
function IsInUAWidget().
- Gives Rule.cpp an include for HoldDropJSObjects.h, to provide DropJSObjects().
- Gives nsImageLoader.cpp an include for DocumentInlines.h (and Document.h for
good measure), to provide the inline function GetPresContext().
- Gives nsStyleStruct.cpp an include for DocumentInlines.h, to provide inline
function Document::GetPresContext().
- Gives nsStyleTransformMatrix.h an include for Units.h (instead of gfxPoint.h,
which isn't useful) to provide the CSSPoint type.
- Gives nsStyleTransformMatrix.h an include for ServoStyleConsts.h, to provide
LengthPercentage and the various StyleRotate/StyleScale/StyleTransform/etc
types. (These can't be easily forward-declared, because some of them are
legitimate types whereas others are type aliases. We could theoretically
forward-declare all of the underlying types and then repeat the type aliases,
but that'd be verbose and unmaintainable.)
Depends on D50165
Differential Revision: https://phabricator.services.mozilla.com/D50166
--HG--
extra : moz-landing-system : lando
The issues fall into these categories:
- Files that used StaticPrefs::layout_XYZ() API or gfxVars::XYZ that needed an
include. (Addressed by adding the missing include.)
- Files that use mozilla::dom::XYZ or mozilla::gfx::XYZ without qualifying the
namespace & without a 'using' decl. (Addressed by adding "using".)
- A few other includes for types/inlines that were used without their header.
Depends on D50162
Differential Revision: https://phabricator.services.mozilla.com/D50163
--HG--
extra : moz-landing-system : lando
In particular, remove useless virtual keywords per our style guide, and remove
redundant argument names (argument names where the name is contained in the type
of the argument), since they're somewhat useless.
I think the result looks neater.
Differential Revision: https://phabricator.services.mozilla.com/D50074
--HG--
extra : moz-landing-system : lando
This seems to fix it for me, and it's pretty straight-forward, but I _think_
we'd still paint the old image if the image is huge and it's loading, which
may be counter-productive. Maybe we should guard the whole "paint mOldImage"
with and if (!oldImageIsDifferent), wdyt?
Differential Revision: https://phabricator.services.mozilla.com/D50062
--HG--
extra : moz-landing-system : lando
There's so much noise.
Every time I read it I feel lost in a sea of virtual keywords :)
This should help.
Differential Revision: https://phabricator.services.mozilla.com/D50022
--HG--
extra : moz-landing-system : lando
Where possible I ported tests to use the shadow DOM. The following could
potentially be ported, but don't think it worth of it:
test_bug414907.xul - uses children nodes in constructor which is very
different in shadow DOM world
test_bug233643.xul - really tests XBL behavior
test_anonymous_content.py - bug on file already to create shadow DOM
test from scratch
Differential Revision: https://phabricator.services.mozilla.com/D49341
--HG--
rename : devtools/client/inspector/test/browser_inspector_highlighter-xbl.js => devtools/client/inspector/test/browser_inspector_highlighter-custom-element.js
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
The wbr element represents a line break opportunity. Before the change double clicking on a text that contains a wbr element did not select the whole sentence.
After the change, the presence of a wbr element in the selection does not affect the selection functionality.
Differential Revision: https://phabricator.services.mozilla.com/D47558
--HG--
extra : moz-landing-system : lando
ubsan was complaining about the expression
```
const char* str = aFrag->Get1b() + aStartOffset;
```
when `aFrag->Get1b() == nullptr` and `aStartOffset == -1`, because the addition generates an invalid pointer.
Due to other logic in the function, we would never dereference that pointer, so it was reasonably harmless, but this patch silences the complaint.
Differential Revision: https://phabricator.services.mozilla.com/D49345
--HG--
extra : moz-landing-system : lando
Most of these tests have been disabled for a long time; they run well
in the current test environment.
With the additional tests running, task times increase; I have added one
more test chunk for android mochitest-plain.
These tests were identified from a random sampling of mochitest manifests;
I intend to enable more mochitests in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D48912
--HG--
extra : moz-landing-system : lando
The crashtest contains an absolute positioning <dialog> multicol
container. If it is fragmented, we end up having a very wrong frame
tree.
Differential Revision: https://phabricator.services.mozilla.com/D49210
--HG--
extra : moz-landing-system : lando
We could put this change itself behind a pref too, if we considered that worth
it. But probably not so.
Differential Revision: https://phabricator.services.mozilla.com/D48010
--HG--
extra : moz-landing-system : lando