dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/HTML/HTMLObjectElement.h

109 lines
3.8 KiB
C
Raw Normal View History

LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2020, Andreas Kling <andreas@ladybird.org>
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
*/
#pragma once
#include <LibCore/Forward.h>
#include <LibGfx/Forward.h>
LibWeb: Rename BrowsingContextContainer => NavigableContainer The "browsing context container" concept in the HTML spec has been replaced with "navigable container". Renaming this is the first step of many towards implementing the new world. Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
2022-12-12 08:20:02 -03:00
#include <LibWeb/HTML/NavigableContainer.h>
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader 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.
2023-05-12 02:17:01 -03:00
#include <LibWeb/Layout/ImageProvider.h>
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
LibWeb: Move HTML classes into the Web::HTML namespace
2020-07-28 13:20:36 -03:00
namespace Web::HTML {
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 09:24:11 -03:00
class HTMLObjectElement final
LibWeb: Rename BrowsingContextContainer => NavigableContainer The "browsing context container" concept in the HTML spec has been replaced with "navigable container". Renaming this is the first step of many towards implementing the new world. Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
2022-12-12 08:20:02 -03:00
: public NavigableContainer
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader 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.
2023-05-12 02:17:01 -03:00
, public Layout::ImageProvider {
LibWeb: Rename BrowsingContextContainer => NavigableContainer The "browsing context container" concept in the HTML spec has been replaced with "navigable container". Renaming this is the first step of many towards implementing the new world. Co-authored-by: Aliaksandr Kalenik <kalenik.aliaksandr@gmail.com>
2022-12-12 08:20:02 -03:00
WEB_PLATFORM_OBJECT(HTMLObjectElement, NavigableContainer)
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
GC_DECLARE_ALLOCATOR(HTMLObjectElement);
LibWeb: Begin supporting non-image HTMLObjectElement data representation We currently only supported loading image data from an HTMLObjectElement node. This adds (some) support for non-image data. A big FIXME is to actually paint that data. We will need to make FrameBox and NestedBrowsingContextPaintable work with HTMLObjectElement for this (they currently only work with HTMLIFrameElement).
2022-03-23 21:15:56 -03:00
enum class Representation {
Unknown,
Image,
LibWeb: Use Fetch to retrieve HTMLObjectElement data URLs This eliminates the use of ResourceLoader in HTMLObjectElement. The spec steps around fetching have been slightly updated since we've last looked at this, so those are updated here. Regarding the text test change: we cannot rely on the data: URL being fetched synchronously. It will occur on a deferred task now. This does match the behavior of other browsers, as they also will not have run the fallback representation steps as of DOMContentLoaded.
2024-12-07 10:49:29 -03:00
ContentNavigable,
LibWeb: Begin supporting non-image HTMLObjectElement data representation We currently only supported loading image data from an HTMLObjectElement node. This adds (some) support for non-image data. A big FIXME is to actually paint that data. We will need to make FrameBox and NestedBrowsingContextPaintable work with HTMLObjectElement for this (they currently only work with HTMLIFrameElement).
2022-03-23 21:15:56 -03:00
Children,
};
LibWeb: Remove inheritance of FormAssociatedElement from HTMLElement HTMLObjectElement will need to be both a FormAssociatedElement and a BrowsingContextContainer. Currently, both of these classes inherit from HTMLElement. This can work in C++, but is generally frowned upon, and doesn't play particularly well with the rest of LibWeb. Instead, we can essentially revert commit 3bb5c62 to remove HTMLElement from FormAssociatedElement's hierarchy. This means that objects such as HTMLObjectElement individually inherit from FormAssociatedElement and HTMLElement now. Some caveats are: * FormAssociatedElement still needs to know when the HTMLElement is inserted into and removed from the DOM. This hook is automatically injected via a macro now, while still allowing classes like HTMLInputElement to also know when the element is inserted. * Casting from a DOM::Element to a FormAssociatedElement is now a sideways cast, rather than directly following an inheritance chain. This means static_cast cannot be used here; but we can safely use dynamic_cast since the only 2 instances of this already use RTTI to verify the cast.
2022-03-23 19:55:54 -03:00
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
public:
virtual ~HTMLObjectElement() override;
LibWeb/HTML: Sanitize email input with multiple attribute This implements the missing part of the value sanitization algorithm for email inputs with the multiple attribute.
2025-07-21 19:58:28 -03:00
virtual void form_associated_element_attribute_changed(FlyString const& name, Optional<String> const& old_value, Optional<String> const& value, Optional<FlyString> const& namespace_) override;
LibWeb: Destroy associated navigable when <object> is removed from DOM
2024-04-17 08:56:55 -03:00
virtual void form_associated_element_was_removed(DOM::Node*) override;
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
LibWeb: Port HTMLObjectElement interface from DeprecatedString to String
2023-09-03 00:39:01 -03:00
String data() const;
LibWeb: Avoid invoking Trusted Types where avoidable Prevents observably calling Trusted Types, which can run arbitrary JS, cause crashes due to use of MUST and allow arbitrary JS to modify internal elements.
2025-10-31 09:30:47 -03:00
void set_data(String const& data);
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 09:24:11 -03:00
LibWeb: Remove DOM element deprecated_get_attribute()
2024-01-16 15:04:45 -03:00
String type() const { return get_attribute_value(HTML::AttributeNames::type); }
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
LibWeb: Make every HTMLElement potentially form-associated This can be the case for form-associated custom elements, where any HTML element can be form-associated.
2026-02-15 00:14:09 -03:00
// ^FormAssociatedElement
virtual bool is_form_associated_element() const override { return true; }
LibWeb: Add form associated element categories
2022-03-01 18:03:30 -03:00
// ^FormAssociatedElement
// https://html.spec.whatwg.org/multipage/forms.html#category-listed
virtual bool is_listed() const override { return true; }
LibWeb: Make HTML::SharedImageRequest GC allocated This allows to partially solve the problem of cyclic dependency between HTMLImageElement and SharedImageRequest that prevents all image elements from being deallocated.
2023-08-18 09:11:55 -03:00
virtual void visit_edges(Cell::Visitor&) override;
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
private:
LibWeb+LibJS: Make the EventTarget hierarchy (incl. DOM) GC-allocated This is a monster patch that turns all EventTargets into GC-allocated PlatformObjects. Their C++ wrapper classes are removed, and the LibJS garbage collector is now responsible for their lifetimes. There's a fair amount of hacks and band-aids in this patch, and we'll have a lot of cleanup to do after this.
2022-08-28 08:42:07 -03:00
HTMLObjectElement(DOM::Document&, DOM::QualifiedName);
LibWeb: Add fast_is<T> for form, embed, image, and object elements These are used by Window::supported_property_names(), which can get very hot.
2023-12-24 10:41:33 -03:00
virtual bool is_html_object_element() const override { return true; }
LibJS: Make Cell::initialize() return void Stop worrying about tiny OOMs. Work towards #20405
2023-08-07 03:41:28 -03:00
virtual void initialize(JS::Realm&) override;
LibWeb: Move setting of Web object prototypes to initialize() This needs to happen before prototype/constructor intitialization can be made lazy. Otherwise, GC could run during the C++ constructor and try to collect the object currently being created.
2023-01-10 08:28:20 -03:00
LibWeb: Avoid many style invalidations on DOM attribute mutation Many times, attribute mutation doesn't necessitate a full style invalidation on the element. However, the conditions are pretty elaborate, so this first version has a lot of false positives. We only need to invalidate style when any of these things apply: 1. The change may affect the match state of a selector somewhere. 2. The change may affect presentational hints applied to the element. For (1) in this first version, we have a fixed list of attribute names that may affect selectors. We also collect all names referenced by attribute selectors anywhere in the document. For (2), we add a new Element::is_presentational_hint() virtual that tells us whether a given attribute name is a presentational hint. This drastically reduces style work on many websites. As an example, https://cnn.com/ is once again browseable.
2024-12-23 13:51:10 -03:00
virtual bool is_presentational_hint(FlyString const&) const override;
LibWeb: Route presentational hints through the CSS cascade Previously, presentational hints bypassed the regular cascade pipeline and wrote directly into `CascadedProperties` under `CascadeOrigin::Author`. That meant `var()` substitution and the invalid-at-computed-value-time fallback had to be duplicated in a separate per-element pass, which in practice missed the IACVT step and could leave a `GuaranteedInvalidStyleValue` in the cascaded properties. This caused a crash in downstream code that assumed the value had been resolved. This introduces an `AuthorPresentationalHint` cascade origin and feeds them through the cascade as normal declarations. This means that `var()` resolution now happens in only one place.
2026-04-30 06:44:26 -03:00
virtual void apply_presentational_hints(Vector<CSS::StyleProperty>&) const override;
LibWeb: Map embedded content element attributes to dimension properties
2024-10-01 13:26:01 -03:00
LibWeb: Make CSS::ComputedProperties GC-allocated
2024-12-20 12:35:12 -03:00
virtual GC::Ptr<Layout::Node> create_layout_node(GC::Ref<CSS::ComputedProperties>) override;
LibWeb: Rename CSS::StyleProperties => CSS::ComputedProperties Now that StyleProperties is only used to hold computed properties, let's name it ComputedProperties.
2024-12-20 07:32:17 -03:00
virtual void adjust_computed_style(CSS::ComputedProperties&) override;
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
LibWeb: Implement falling back early to an object's child representation
2022-03-24 12:14:19 -03:00
bool has_ancestor_media_element_or_object_element_not_showing_fallback_content() const;
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 09:24:11 -03:00
void queue_element_task_to_run_object_representation_steps();
LibWeb: Use Fetch to retrieve HTMLObjectElement data URLs This eliminates the use of ResourceLoader in HTMLObjectElement. The spec steps around fetching have been slightly updated since we've last looked at this, so those are updated here. Regarding the text test change: we cannot rely on the data: URL being fetched synchronously. It will occur on a deferred task now. This does match the behavior of other browsers, as they also will not have run the fallback representation steps as of DOMContentLoaded.
2024-12-07 10:49:29 -03:00
void run_object_representation_handler_steps(Fetch::Infrastructure::Response const&, MimeSniff::MimeType const&, ReadonlyBytes);
LibWeb: Conditionally update an object's children when its state changes We should only update the object children of an object when the parent's representation changes to/from falling back to its children.
2022-03-24 12:09:45 -03:00
void run_object_representation_completed_steps(Representation);
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 09:24:11 -03:00
void run_object_representation_fallback_steps();
LibWeb: Piggyback on HTML::ImageRequest in HTMLObjectElement Like the piggybacking in CSS, this is also totally ad-hoc, since there's no spec to follow. The code here is weird and definitely sub-optimal as we do a second load if it turns out the loaded resource is an image, but given that object elements are rarely used nowadays, I doubt we'll even notice. That said, we should of course improve this code as we move forward.
2023-06-11 11:02:37 -03:00
void load_image();
LibWeb: Conditionally update an object's children when its state changes We should only update the object children of an object when the parent's representation changes to/from falling back to its children.
2022-03-24 12:09:45 -03:00
void update_layout_and_child_objects(Representation);
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 09:24:11 -03:00
LibWeb: Use Fetch to retrieve HTMLObjectElement data URLs This eliminates the use of ResourceLoader in HTMLObjectElement. The spec steps around fetching have been slightly updated since we've last looked at this, so those are updated here. Regarding the text test change: we cannot rely on the data: URL being fetched synchronously. It will occur on a deferred task now. This does match the behavior of other browsers, as they also will not have run the fallback representation steps as of DOMContentLoaded.
2024-12-07 10:49:29 -03:00
void resource_did_load(Fetch::Infrastructure::Response const&, ReadonlyBytes);
void resource_did_fail();
LibWeb: Implement HTMLObjectElement's data URL according to the spec There are a long list of conditions under which the HTMLObjectElement is to queue an element task to load / determine an object's representation. This handles the case where the data attribute has changed. Much of the spec for determining the object's representation is not implemented here. Namely, anything to do with XML documents or browser plugins are left as FIXMEs.
2022-03-23 09:24:11 -03:00
LibWeb: Implement HTMLOrSVGElement.tabIndex
2022-11-05 00:58:14 -03:00
// ^DOM::Element
virtual i32 default_tab_index_value() const override;
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader 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.
2023-05-12 02:17:01 -03:00
// ^Layout::ImageProvider
LibWeb: Generalize ImageBox and ImagePaintable for any ImageProvider They currently assume the DOM node is an HTMLImageElement with respect to handling the alt attribute. The HTMLInputElement will require the same behavior.
2024-02-18 22:10:37 -03:00
virtual bool is_image_available() const override;
LibWeb: Make ImageBox ask ImageProvider for intrinsic size and ratio This paves the way for ImageProvider to have something vector-based underneath. :^)
2023-05-20 11:27:31 -03:00
virtual Optional<CSSPixels> intrinsic_width() const override;
virtual Optional<CSSPixels> intrinsic_height() const override;
LibWeb: Use `CSSPixelFraction` to represent aspect ratios This allows us to retain perfect precision for aspect ratios derived from either the intrinsic sizes of replaced elements, or the `aspect-ratio` CSS property.
2023-09-03 19:33:58 -03:00
virtual Optional<CSSPixelFraction> intrinsic_aspect_ratio() const override;
LibGfx+LibWeb: Make DecodedImageFrame a value type DecodedImageFrame only wraps a ref-counted Bitmap and color-space metadata. The frame object itself does not provide shared mutable state or lifetime ownership beyond those members, so ref-counting it adds an unnecessary layer of indirection.
2026-05-07 09:39:50 -03:00
virtual Optional<Gfx::DecodedImageFrame> current_image_frame_sized(Gfx::IntSize) const override;
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader 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.
2023-05-12 02:17:01 -03:00
virtual void set_visible_in_viewport(bool) override;
LibWeb: Allow ImageProvider to not have a corresponding DOM node This is prep work for CSS content:image.
2025-07-26 09:46:23 -03:00
virtual GC::Ptr<DOM::Element const> to_html_element() const override { return *this; }
LibWeb: Add ImageProvider virtual to access the DecodedImageData ...and also the current frame index, in case of animations.
2025-11-04 16:51:46 -03:00
virtual size_t current_frame_index() const override { return 0; }
virtual GC::Ptr<DecodedImageData> decoded_image_data() const override { return image_data(); }
LibWeb: Don't force HTMLImageElement to have a legacy ImageLoader 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.
2023-05-12 02:17:01 -03:00
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
GC::Ptr<DecodedImageData> image_data() const;
LibWeb: Piggyback on HTML::ImageRequest in HTMLObjectElement Like the piggybacking in CSS, this is also totally ad-hoc, since there's no spec to follow. The code here is weird and definitely sub-optimal as we do a second load if it turns out the loaded resource is an image, but given that object elements are rarely used nowadays, I doubt we'll even notice. That said, we should of course improve this code as we move forward.
2023-06-11 11:02:37 -03:00
LibWeb: Use Fetch to retrieve HTMLObjectElement data URLs This eliminates the use of ResourceLoader in HTMLObjectElement. The spec steps around fetching have been slightly updated since we've last looked at this, so those are updated here. Regarding the text test change: we cannot rely on the data: URL being fetched synchronously. It will occur on a deferred task now. This does match the behavior of other browsers, as they also will not have run the fallback representation steps as of DOMContentLoaded.
2024-12-07 10:49:29 -03:00
Representation m_representation { Representation::Unknown };
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
GC::Ptr<SharedResourceRequest> m_resource_request;
LibWeb: Delay load event in more HTMLObjectElement situation
2024-11-26 11:29:07 -03:00
LibWeb: Run the object representation task when the active state changes Currently, the following JS snippet will hang indefinitely: new DOMParser().parseFromString("<object>", "text/html"); Because the document into which the object is inserted is not active. So the task queued to run the representation steps will never run. This patch implements the spec steps to rerun the representation steps when the active state changes, and avoid the hang when the object is created in an inactive document.
2024-12-11 15:18:21 -03:00
GC::Ptr<DOM::DocumentObserver> m_document_observer;
LibWeb: Keep delaying the load event on concurrent <object> tasks If we queue the <object> representation task multiple times in a row, we would end up clearing the delayer after the first task completed. We must continue delaying the load event until the last task completes. This becomes an issue in an upcoming commit to import the acid2 test.
2025-05-22 13:16:11 -03:00
Vector<DOM::DocumentLoadEventDelayer> m_document_load_event_delayer_for_object_representation_task;
Vector<DOM::DocumentLoadEventDelayer> m_document_load_event_delayer_for_resource_load;
LibWeb: Add basic <object> element support This patch implements a simple <object> element with fallback content. If the URL from the data attribute fails to load (including 404), we render the DOM tree inside the <object> as fallback content. This works by generating a different layout tree for the <object> depending on the state and success of the data load. Since we cannot currently do incremental layout tree updates, we have to force a complete layout tree rebuild when the resource load finishes/fails.
2020-06-13 17:24:49 -03:00
};
}
LibWeb: Add fast_is<T> for form, embed, image, and object elements These are used by Window::supported_property_names(), which can get very hot.
2023-12-24 10:41:33 -03:00
namespace Web::DOM {
Meta: Enforce newlines around namespaces This has come up several times during code review, so let's just enforce it using a new clang-format 20 option.
2025-05-13 08:06:33 -03:00
LibWeb: Add fast_is<T> for form, embed, image, and object elements These are used by Window::supported_property_names(), which can get very hot.
2023-12-24 10:41:33 -03:00
template<>
inline bool Node::fast_is<HTML::HTMLObjectElement>() const { return is_html_object_element(); }
Meta: Enforce newlines around namespaces This has come up several times during code review, so let's just enforce it using a new clang-format 20 option.
2025-05-13 08:06:33 -03:00
LibWeb: Add fast_is<T> for form, embed, image, and object elements These are used by Window::supported_property_names(), which can get very hot.
2023-12-24 10:41:33 -03:00
}
Reference in a new issue Copy permalink