We are often trying to click the image before it has finished loading.
This results in us trying to click a 0x0 rect. Instead, wait until the
image load event.
This fixes a flake with form-image-submission.html often seen on CI.
Two bugs:
1. Correctly set bits in VP8X header.
Turns out these were set in the wrong order.
2. Correctly set the `has_alpha` flag.
Also add a test for writing webp files with icc data. With the
additional checks in other commits in this PR, this test catches
the bug in WebPWriter.
Rearrange some existing functions to make it easier to write this test:
* Extract encode_bitmap() from get_roundtrip_bitmap().
encode_bitmap() allows passing extra_args that the test uses to pass
in ICC data.
* Extract expect_bitmaps_equal() from test_roundtrip()
If this turns out to be too strict in practice, we can replace it with
a `dbgln("VP8X and VP8L headers disagree about alpha; ignoring VP8X");`
instead.
ALso update catdog-alert-13-alpha-used-false.webp to not trigger this.
I had manually changed the VP8L alpha flag at offset 0x2a in
da48238fbd to clear it, but I hadn't changed the VP8X flag.
This changes the byte at offset 0x14 from 0x10 (has_alpha) to 0x00
(no alpha) as well, to match.
Explicit template arguments must be wrapped in parens,
else they confuse the preprocessor.
Add the parens instead of avoiding the use of explicit template
arguments.
No behavior change.
Bilevel images are not required to have a BitsPerSample or a
SamplesPerPixel tag, while this is unusual these images are still valid.
The test case has been generated by first making a copy of
ccitt3_1d_fill.tiff and then, using `tiffset` to remove both tags:
tiffset -u 258 ccitt3_no_tags.tiff
tiffset -u 277 ccitt3_no_tags.tiff
The spec isn't _super_ clear on how this is meant to be done, but the
way I understand this is that we should simply clamp the returned
'current value' between 'min' and 'max'.
Firefox does not appear to do this clamping, but Chrome does.
This is a simple getter and setter of the OscillatorType enum, with
error checking to not allow 'custom', as that should only be changed
through 'setPeriodicWave()'.
This is still missing a bunch of spec steps to construct the
audio node based on the parameters of the OscillatorNode, but it is at
least enough to construct an object to be able to add a basic test which
can get built upon as more is implemented.
Previously, we would apply any adopted style sheet to the document if
its alternate flag was not set. This meant that all adopted style
sheets would be applied, since constructed style sheets never have this
flag set.
...and add a test case that shows why it's incorrect.
If one dimension is 2^n + 1 and the other side is just 1, then the
topmost node will have 2^n x 1 and 1 x 1 children. The first child will
have n levels of children. The 1 x 1 child could end immediately, or it
could require that it also has n levels of (all 1 x 1) children. The
spec isn't clear on which of the two alternatives should happen. We
currently have n levels of 1 x 1 blocks.
This test case shows that a VERIFY we had was incorrect, so remove it.
The alternative implementation is to keep the VERIFY and to add a
if (x_count == 1 && y_count == 1)
level = 0;
to the top of TagTreeNode::create(). Then we don't have multiple levels
of 1 x 1 nodes, and we need to read fewer bits.
The images in the spec suggest that all nodes should have the same
number of levels, so go with that interpretation for now. Once we can
actually decode images, we'll hopefully see which of the two
interpretations is correct.
(The removed VERIFY() is hit when decoding
Tests/LibGfx/test-inputs/jpeg2000/buggie-gray.jpf in a local branch that
has some image decoding implemented. That file contains a packet with
1x3 code-blocks, which hits this case.)
The main difference was that our implementation was writing
the final line of a series of repeated lines, whereas the
spec says "The second and succeeding copies of repeated adjacent
input lines shall not be written."
Additionally, there was a mistake in the -f flag implementation
causing the number of fields skipped to be one greater than
required.
Flags that rely on counting lines (-c and -d) were
producing results that were off by one. This is fixed
by initializing the `count` variable to 1, which is
consistent with behavior in the main loop, where it
is reset to 1 when lines don't match.
Calls to `read_line` are replaced with `read_line_with_resize`
and `swap`s of StringViews, which assume a consistent location
of the underlying ByteBuffers, are replaced. A test file has
been added for uniq, which includes a test case for long lines.
`ceil_div(-1, 2)` used to return -1.
Now it returns 0, which is the correct ceil(-0.5).
(C++'s division semantics have floor semantics for numbers > 0,
but ceil semantics for numbers < 0.)
This will be important for the JPEG2000 decoder eventually.
