In order to separate the SVG content from the rest of the engine, it
gets its very own Page, PageClient, top-level browsing context, etc.
Unfortunately, we do have to get the palette and CSS/device pixel ratios
from the host Page for now, maybe that's something we could refactor in
the future.
Note that this doesn't work visually yet, since we don't calculate the
intrinsic sizes & ratio for SVG images. That comes next. :^)
This allows the painting subsystem to request a bitmap with the exact
size needed for painting, instead of being limited to "just give me a
bitmap" (which was perfectly enough for raster images, but not for
vector graphics).
The existing implementation moves down into a new subclass called
AnimatedBitmapDecodedImageData.
The purpose of this change is to create an extension point where we can
plug in an SVG renderer. :^)
If linking fails, we throw a JS exception, and if there's no execution
context on the VM stack at that time, we assert in VM::current_realm().
This is a hack to prevent crashing on failed module loads. Long term we
need to rewrite module loading since it has been refactored to share
code differently between HTML and ECMA262.
Instead of recomputing the state whenever someone asks for it, we now
cache it when the attribute is added/changed/removed.
Before this change, HTMLElement::is_editable() was 6.5% of CPU time
when furiously resizing Hacker News. After, it's less than 0.5%. :^)
The spec seems to neglect the potential nullity of an image's pending
request in various cases.
Let's protect against crashing and mark these cases with a FIXME about
figuring out whether they are really spec bugs or not.
Rather than setting the src attribute on the HTMLMediaElement, websites
may append a list of HTMLSourceElement nodes to the media element. There
is a series of "try the next source" steps to attempt to fetch/load each
source until we find one that works.
We achieve this by adding a new Layout::ImageProvider class and having
both HTMLImageElement and HTMLObjectElement inherit from it.
The HTML spec is vague on how object image loading should work, which
is why this first pass is focusing on image elements.
This patch adds HTML::ImageRequest and HTML::DecodedImageData.
The latter had to use a different name than "ImageData", as there is
already an IDL-exposed ImageData class in HTML.
The completion callback currently only accepts a JavaScriptModuleScript.
The same callback will need to be used for ClassicScript scripts as well
so allow the callback to accept any Script type. The single existing
outside caller already stores the result as a Script.
This lets elements figure out if they're visible within the viewport or
not, so they take appropriate action.
Fixes the issues with animations not starting until the viewport was
resized or scrolled.
This is an oversized hammer for sure, but we have to make sure the
layout tree gets rebuilt in case the object representation changes.
Since "throw out the entire layout tree" is the finest tool we have
right now, it'll have to do.
This fixes an issue where the eyes on Acid2 would sometimes not show up
until the next layout invalidation occurred.
"The official project language is American English […]."
5d2e915623/CONTRIBUTING.md (L30)
Here's a short statistic of the occurrences of the word "behavio(u)r":
$ git grep -IPioh 'behaviou?r' | sort | uniq -c | sort -n
2 BEHAVIOR
24 Behaviour
32 behaviour
407 Behavior
992 behavior
Therefore, it is clear that "behaviour" (56 occurrences) should be
regarded a typo, and "behavior" (1401 occurrences) should be preferred.
Note that The occurrences in LibJS are intentionally NOT changed,
because there are taken verbatim from the specification. Hence:
$ git grep -IPioh 'behaviou?r' | sort | uniq -c | sort -n
2 BEHAVIOR
10 behaviour
24 Behaviour
407 Behavior
1014 behavior
Implements:
https://html.spec.whatwg.org/multipage/browsing-the-web.html#attempt-to-populate-the-history-entry's-document
This is going to be a replacement for `FrameLoader::load()` after
switching to navigables.
Brief description of `populate_session_history_entry_document`:
- If navigation params have url with fetch scheme then DOM document
will be populated by fetching url and parsing response. This
is going to be a replacement for `FrameLoader::load(AK::URL&)`.
- If url in navigation params is abort:srcdoc then DOM document
will be populated by parsing HTML text passed in document resource.
This is going to be a replacement for `FrameLoader::load_html()`
