Previously we would calculate the index of the first parent node as
heap.size() (which is initialized to non_zero_freqs), so in the edge
case in which all symbols had a non-zero frequency, we would use the
Size-index entry in the array for both the first symbol's leaf node,
and the first parent node.
The result would either be a non-optimal huffman code (bad), or an
illegal huffman code that would then go on to crash due to an error
check in CanonicalCode::from_bytes. (worse)
We now store parent nodes starting at heap.size() - 1, which eliminates
the potential overlap, and resolves the issue.
Previously, we determined the positions of glyphs for each text run at
the time of painting, which constituted a significant portion of the
painting process according to profiles. However, since we already go
through each glyph to figure out the width of each fragment during
layout, we can simultaneously gather data about the position of each
glyph in the layout phase and utilize this information in the painting
phase.
I had to update expectations for a couple of reference tests. These
updates are due to the fact that we now measure glyph positions during
layout using a 1x font, and then linearly scale each glyph's position
to device pixels during painting. This approach should be acceptable,
considering we measure a fragment's width and height with an unscaled
font during layout.
This change limits the amount of memory that is initially allocated for
the color table. This prevents an OOM condition if the file contains an
incorrect color table size.
We currently fire the change event on <input> elements when they lose
focus. The spec allows for us to also fire the event when changes are
"committed", so long as such an action makes sense for the input type.
This patch detects when the return key is entered in an <input> element
and uses that as the commit action for text-related types. If no change
has occurred since the last commit, no change event is fired.
Assuming that my changes to make iframes delay the load event are
correct, and that nothing else was causing the flakiness, this test
should be OK now! (Famous last words.)
From test262 documentation, this flag means:
The test file should only be run when the [[CanBlock]] property of
the Agent Record executing the file is `false`.
This patch stubs out the accessor for that internal slot and skips tests
with the CanBlockIsFalse if that internal slot is true.
We currently create a shadow tree once for each DOM element that renders
with a shadow tree (e.g. <input>, <details>). If such an element is
removed from the DOM, we must remove its shadow tree. Otherwise, the
shadow tree will refer to the old document in perpetuity.
If the node is added back to a DOM, then recreate the shadow tree.
Setting the marker's content width here is causing the text that follows
the marker to be indented a bit too much. This is noticeable when a line
with a disclosure marker is followed by a line with any other marker. It
previously would look something like:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
Now the disclosure marker line matches other marker types:
> Text inline with disclosure-closed marker
* Text inline with circle marker
# Text inline with square marker
There were two issues:
1) the C+=R and C-=R operators expected arithmetic types to have .real()
2) the R+C, R-C, R*C and R/C operators applied the operation in wrong
order (did C+R, C-R, C*R and C/R instead). This wouldn't matter for
+ and * which are commutative, but is incorrect for - and /.
We currently do not wait for iframes to finish loading before triggering
the document's load event, which creates a race condition for any ref
tests that include iframes. Until that gets fixed, let's skip the one
affected test.
See issue #22012.
Ideally we would not create a layout node at all for these elements so
that every layout node would always have a paintable associated with it.
But for now, to fix the crash, just leave a FIXME and special case this
element.
Also leave a VERIFY to make it easier to debug this type of crash in the
future.
Fixes a crash seen on codecov.io for my 'patch' project.
It's perfectly possible for JavaScript to call unobserve() on an element
that hasn't been observed. Let's stop asserting if that happens. :^)
Fixes#22020
Manually added an Outlines dict with three items, one each for
every text string encoding in its title.
(Preview.app apparently can't handle UTF-8 in outlines either.)
