The original code doesn't work for "writing-mode:vertical-rl" because
its block flow direction is the opposite of "writing-mode:vertical-lr."
Differential Revision: https://phabricator.services.mozilla.com/D96786
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
Instead of the scrollframe manually calling ScrollGeneration::New this has the
ScrollPositionUpdate do it automatically. Just makes things a little more
encapsulated.
Note that this patch does contain a small functional change, which is that if
ScrollFrameHelper::ScrollToImpl is called with ScrollOrigin::apz, it will not
increment mScrollGeneration whereas it used to before. As far as I can tell
this should be a harmless change.
Depends on D97036
Differential Revision: https://phabricator.services.mozilla.com/D97037
Note in particular the struct keeps its own static (per-process) counter value,
and uses a uint64_t.
Depends on D97034
Differential Revision: https://phabricator.services.mozilla.com/D97035
In the case where there are two scrollframes that get scrolled in an
interleaved manner, the scroll generation counter continually advances
and blocks APZ from updating the main-thread scroll position. This
fixes that by removing the scroll generation counter check from the
relevant condition. The clause is entirely redundant when there is only
a single scrollframe and only causes problems when there are multiple
scrollframes.
Differential Revision: https://phabricator.services.mozilla.com/D97034
Otherwise fixed-pos elements still escape the container chain, which is
what the null-abspos container hack (currently used by mathml) is
supposed to prevent.
Differential Revision: https://phabricator.services.mozilla.com/D96779
We might clear this flag in PostRebuildAllStyleData before actually
flushing style, so if the timing is wrong you can hit this assertion.
This doesn't impact correctness in any way that I can see.
Differential Revision: https://phabricator.services.mozilla.com/D96685
Otherwise fixed-pos elements still escape the container chain, which is
what the null-abspos container hack (currently used by mathml) is
supposed to prevent.
Differential Revision: https://phabricator.services.mozilla.com/D96779
Changing the size or number of layers of textures unfortunately usually leads to small sampling differences which requires fixing in the refetest references.
Differential Revision: https://phabricator.services.mozilla.com/D95680
First, copy the "vertical-lr" reftests added in Part 3, then running the
following command to convert to `writing-mode: vertical-rl` for all the
reftests.
```
rg -l "vertical-lr" flexbox-*vertical-rl* | xargs sed -i "s/vertical-lr/vertical-rl/g"
```
reftest.list are modified manually.
Differential Revision: https://phabricator.services.mozilla.com/D96742
First, copy the original reftests, then running the following command to
add `writing-mode: vertical-lr` to all the reftests, and modify `<link>`
tag.
```
function rename () {
rg -l "$1" flexbox-*vertical-lr* | xargs sed -i "s/$1/$2/g"
}
rename "<style>" "<style>\n html \{\n writing-mode: vertical-lr;\n \}"
rename "single-column" "single-column-vertical-lr"
rename "multi-column" "multi-column-vertical-lr"
rename "single-row" "single-row-vertical-lr"
rename "multi-row" "multi-row-vertical-lr"
```
reftest.list are modified manually.
Differential Revision: https://phabricator.services.mozilla.com/D96741
Changing the size or number of layers of textures unfortunately usually leads to small sampling differences which requires fixing in the refetest references.
Differential Revision: https://phabricator.services.mozilla.com/D95680
As there's no incremental reflow for non-print documents, we can't rely
on FinishReflow getting called.
Not ultra-pretty, better ideas welcome.
Differential Revision: https://phabricator.services.mozilla.com/D96790
Aside from automating boilerplate, this will allow reusing some of these
structs for full LookAndFeel remoting in bug 1470983.
Differential Revision: https://phabricator.services.mozilla.com/D94531
There appears to be a substantial overhead for trying to wake cold threads
from a thread pool (especially with rayon), so for now let's leave the existing
thread spawning in place, but reduce the stack size for individual threads.
Since these threads only call into SWGL's composite routines and do little else,
there isn't much harm in having a small stack size.
Differential Revision: https://phabricator.services.mozilla.com/D96748
Whether scrollbar buttons are shown is currently determined by
LookAndFeel values, and these are exposed through system metric media
features. LookAndFeel values are process-wide, but which theme is in
use is document-specific. (It can be the platform's native theme or the
native basic theme, depending on Document::ShouldAvoidNativeTheme.) So
if nsNativeBasicTheme on Linux needs to not support scrollbar buttons,
we can't do this by forcing the LookAndFeel values to be false.
So instead, we skip creating the native anonymous content for the
scrollbar buttons when the non-native theme is in use on Linux. There's
no need to support dynamic changes, since whether the non-native theme
is in use for a given document never changes.
Differential Revision: https://phabricator.services.mozilla.com/D96345
This change removes docshell's `mTouchEventsOverride` and replaces it
with a new `BrowsingContext` field `TouchEventsOverrideInternal`.
All uses of the old field have been replaced and an override should
now work under fission when there are cross-origin descendent frames.
Differential Revision: https://phabricator.services.mozilla.com/D96414
Per spec https://drafts.csswg.org/css-sizing-3/#intrinsic-contribution,
for the replaced elements with no intrinsic size and no preferred aspect
ratio, the fallback size is '300px' for the width and '150px' for the
height, regardless of the writing-mode value.
Without this patch, Firefox fails the last two subtests when the svg
image has the vertical writing-mode with no intrinsic size and no aspect
ratio. Both Chrome and Safari render all the subtests as 300x150.
This patch fixed the last two subtests.
Differential Revision: https://phabricator.services.mozilla.com/D96259
CSSPixel::ToAppUnits() requires computation at runtime. Since most of
the layout computations require `nscoord`, this patch defines extra
intrinsic sizes in app units.
Differential Revision: https://phabricator.services.mozilla.com/D96258