This is modeled after a similar implementation for the JS console.
This client takes over an inspector WebView (created by the chrome) to
create the inspector application. Currently, this application includes
the DOM tree and accessibility tree as a first pass. It can later be
extended to included the style tables, the JS console itself, etc.
This is an internal object that must be explicitly enabled by the chrome
before it is added to the Window. The Inspector object will be used by a
special WebView that will replace all chrome-specific inspector windows.
The IDL defines methods that this WebView will need to inform the chrome
of various events, such as the user clicking a DOM node.
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
We were calling write syscall twice for every sample, which effectively
hurt the writer's performance.
With this change exporting a melody in the Piano app now takes less than
a second, which previously took about 20 seconds on my machine.
Additionally, I've removed an unused `WavWriter::file()` getter.
This will make window.open a lot easier to implement. As written, the
implementation of Navigable::choose_a_navigable now looks a lot closer
to the old BrowsingContext::choose_a_browsing_context. With the notable
exception that we still crash in many cases, and don't properly handle
multiple top-level traversables in the same WebContent process.
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.
SMasks are greyscale images that get used as alpha channel for a
different image.
JPEGs in PDFs are stored as streams with /DCTDecode filters, and
we have a separate code path for loading those in the PDF renderer.
That code path just calls our JPEG decoder, which creates bitmaps
with format BGRx8888.
So when we process an SMask for such a bitmap, we have to change
the bitmap's format to BGRA8888 in addition to setting alpha values
on all pixels.
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
Before this change, there was some confusion possible where an IO would
try to find its way back to the document where we registered it.
This led to an assertion failure in the test I'm adding in the next
commit, so let's fix this first.
IOs now (weakly) remember the document where they are registered, and
only unregister from there.
Per 1.7 spec 3.8.1, there are multiple logical text string types:
* text strings
* ASCII strings
* byte strings
Text strings can be in UTF-16BE, PDFDocEncoding, or (since PDF 2.0)
UTF-8.
But byte strings shouldn't be converted but treated as binary
data.
This makes us no longer convert strings used for drawing page text.
TABLE 5.6 "Text-showing operators" lists the operands for text-showing
operators as just "string", not "text string" (even though these strings
confusingly are called "text strings" in the body text), so not doing
this there is correct (and matches other viewers).
We also no longer incorrectly convert strings used for cypto data
(such as passwords), if they start with an UTF-16BE or UTF-8 marker.
No behavior change for outlines and info dict entries.
https://pdfa.org/understanding-utf-8-in-pdf-2-0/ has a good overview of
this.
(ASCII strings only contain ASCII characters and behave the same
anyways.)
Implemented by adding the extra 3-value syntax as its own case and only
running it when parsing background-position. I'm sure it could be
implemented in a smarter way but this is still a bunch less code than
before. :^)
This means `object-position` will no longer incorrectly accept the
3-value background-position syntax.
Remove the now-ambiguous and unused `position` enum while we're at it.
(This enum only existed as a hack.)
And dealing with the fallout of doing so. I am not 100% sure that it is
safe for us to be treating Strings in the value sanitization algorithm
in all cases as if they are ASCII, but this commit does not change any
existing behaviour there.
