Fix for issue #2108. That issue mentions an `unwrap_object` which doesn't seem to exist so I renamed `unwrap` to `native_from_reflector` and `unwrap_jsmanaged` to `native_from_reflector_jsmanaged`. The latter is a bit unweildy - maybe a shorter name might be better?
As noted by @bholley. "unwrap" is confusing because we are
both stripping off wrappers *and* getting a native from a
reflector. Changing the "unwrap" usage to "native_from_reflector"
for clarity.
This renames 'unwrap' to 'native_from_reflector' and
'unwrap_jsmanaged' to 'native_from_reflector_jsmanaged'.
This will be re-introduced in a follow up PR with a different usage, but I'm trying to create small, independent PRs that are easier to review than one large change.
This patch enables the use of `arc()` on the canvas.
I couldn't add reftest this time, as it involves some antialiasing issues, and so the reference doesn't match.
Opening this PR to invite feedback.
Of the many `match` statement candidates for conversion to `if let`, several included `if` guards. Since `if let` doesn't support this syntax, I used nested if statements. If this is undesirable, say the word and I can revert those cases to `match`.
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
Reconstructed from #5138 via raw diffing.
r? @SimonSapin
§ 12.3-12.5.
Only simple alphabetic and numeric counter styles are supported. (This
is most of them though.)
Although this PR adds a sequential pass to layout, I verified that on
pages that contain a reasonable number of ordered lists (Reddit
`/r/rust`), the time spent in generated content resolution is dwarfed by
the time spent in the parallelizable parts of layout. So I don't expect
this to negatively affect our parallelism expect perhaps in pathological
cases.
...and vice-versa. This is not a complete fix for all mixed-direction layout cases, but it fixes enough problems to make some simple test cases pass, like tha attached reftest.
There are FIXME comments for many of the remaining issues. In particular, this does not yet handle RTL layout of fixed/absolute elements, nor does it completely fix the overconstrained_block reftest.
r? @SimonSapin or @pcwalton
...and vice-versa. This is not a complete fix for all mixed-direction layout
cases, but it fixes enough problems to make some simple test cases pass, like
tha attached reftest.
There are FIXME comments for many of the remaining issues. In particular,
this does not yet handle RTL layout of fixed/absolute elements.
Rebase of #5123. (Fixes #5123.) Thanks @gille-leblanc!
Reftest list check is checked using Python's default string comparison.
Also added a notice in the tidy script when there are no errors.
Fixes#5092
Thread font load errors from platform font loading code to
FontContext::get_layout_font_group_for_style, and cache the failure
result, instead of panicing the thread when a font fails to load.
Before this patch, a failed font load would panic a LayoutTask,
causing a cascade of panics, eventually aborting the whole engine
during a panic within panic.
On my Arch Linux machine almost every page would crash in this manner,
including e.g. reddit.com and cnn.com. Mosf of the requested fonts would
load fine but some single variant of Helvetica would fail always. Not sure
how to create a test for this as it seems pretty system-specific.
Cheers,
cyndis
Thread font load errors from platform font loading code to
FontContext::get_layout_font_group_for_style, and cache the failure
result, instead of panicing the thread when a font fails to load.
Before this patch, a failed font load would panic a LayoutTask,
causing a cascade of panics, eventually aborting the whole engine
during a panic within panic.
