Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 15:43:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/HTML/HTMLObjectElement.h

108 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 22:24:49 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02: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 22:24:49 +02: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 01:24:48 -07: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 22:24:49 +02:00
*/
#pragma once
#include <LibCore/Forward.h>
#include <LibGfx/Forward.h>
LibWeb: Make FormAssociatedElement inherit from HTMLElement The new event target implementation requires us to downcast an EventTarget to a FormAssociatedElement to check if the current Element EventTarget has a form owner to setup a with scope for the form owner. This also makes all form associated elements inherit from FormAssociatedElement where it was previously missing. https://html.spec.whatwg.org/#form-associated-element
2021-10-14 16:18:49 +01:00
#include <LibWeb/HTML/FormAssociatedElement.h>
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 18:55:54 -04:00
#include <LibWeb/HTML/HTMLElement.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 12:20:02 +01: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 07:17:01 +02: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 22:24:49 +02:00
LibWeb: Move HTML classes into the Web::HTML namespace
2020-07-28 18:20:36 +02: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 22:24:49 +02: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 08:24:11 -04: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 12:20:02 +01:00
: public NavigableContainer
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 18:55:54 -04:00
, public FormAssociatedElement
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 07:17:01 +02: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 12:20:02 +01: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-15 04:01:23 +13:00
GC_DECLARE_ALLOCATOR(HTMLObjectElement);
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 12:20:02 +01:00
FORM_ASSOCIATED_ELEMENT(NavigableContainer, 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 20:15:56 -04: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 08:49:29 -05: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 20:15:56 -04: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 18:55:54 -04: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 22:24:49 +02: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-22 00:58:28 +02: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 13:56:55 +02: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 22:24:49 +02:00
LibWeb: Port HTMLObjectElement interface from DeprecatedString to String
2023-09-03 15:39:01 +12:00
String data() const;
void set_data(String const& data) { MUST(set_attribute(HTML::AttributeNames::data, 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 08:24:11 -04:00
LibWeb: Remove DOM element deprecated_get_attribute()
2024-01-16 19:04:45 +01: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 22:24:49 +02:00
LibWeb: Add form associated element categories
2022-03-01 21:03:30 +00: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 14:11:55 +02: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 22:24:49 +02: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 13:42:07 +02: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 14:41:33 +01: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 08:41:28 +02: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 06:28:20 -05: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 17:51:10 +01:00
virtual bool is_presentational_hint(FlyString const&) const override;
LibWeb: Split StyleComputer work into two phases with separate outputs Before this change, StyleComputer would essentially take a DOM element, find all the CSS rules that apply to it, and resolve the computed value for each CSS property for that element. This worked great, but it meant we had to do all the work of selector matching and cascading every time. To enable new optimizations, this change introduces a break in the middle of this process where we've produced a "CascadedProperties". This object contains the result of the cascade, before we've begun turning cascaded values into computed values. The cascaded properties are now stored with each element, which will later allow us to do partial updates without re-running the full StyleComputer machine. This will be particularly valuable for re-implementing CSS inheritance, which is extremely heavy today. Note that CSS animations and CSS transitions operate entirely on the computed values, even though the cascade order would have you believe they happen earlier. I'm not confident we have the right architecture for this, but that's a separate issue.
2024-12-12 10:06:29 +01:00
virtual void apply_presentational_hints(GC::Ref<CSS::CascadedProperties>) const override;
LibWeb: Map embedded content element attributes to dimension properties
2024-10-01 17:26:01 +01:00
LibWeb: Make CSS::ComputedProperties GC-allocated
2024-12-20 16:35:12 +01: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 11:32:17 +01: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 22:24:49 +02:00
LibWeb: Implement falling back early to an object's child representation
2022-03-24 11:14:19 -04: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 08:24:11 -04: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 08:49:29 -05: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 11:09:45 -04: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 08:24:11 -04: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 16:02:37 +02: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 11:09:45 -04: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 08:24:11 -04: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 08:49:29 -05: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 08:24:11 -04:00
LibWeb: Implement HTMLOrSVGElement.tabIndex
2022-11-05 03:58:14 +00: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 07:17:01 +02: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 20:10:37 -05: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 16:27:31 +02: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 17:33:58 -05:00
virtual Optional<CSSPixelFraction> intrinsic_aspect_ratio() const override;
LibWeb: Use intrinsic size for current_image_bitmap Currently, ImageProvider::current_image_bitmap takes a Gfx::IntSize argument which determines the size of the returned bitmap. The default value of this argument is 0x0 which causes the function to return nullptr. This behavior is evidently unintuitive enough that it has lead to incorrect usage in multiple places. For example, the 2D canvas drawImage method will never actually draw anything because it calls current_image_bitmap with no arguments. And the naturalWidth and naturalHeight of an image will always return 0 (even after the image has loaded) for the same reason. To correct this and hopefully avoid similar issues in the future, ImageProvider::current_image_bitmap will be renamed to current_image_bitmap_sized, and the default value for the size argument will be removed. For consistency, a similar change will be made to SVGImageElement::default_image_bitmap. The existing current_image_bitmap function will no longer take a size argument. Instead it will always return a bitmap of the image's intrinsic size. This seems to be what most existing callers had already assumed was the function's behavior.
2025-08-28 11:21:46 -04:00
virtual RefPtr<Gfx::ImmutableBitmap> current_image_bitmap_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 07:17:01 +02: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 14:46:23 +02:00
virtual GC::Ptr<DOM::Element const> to_html_element() const override { return *this; }
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 07:17:01 +02: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-15 04:01:23 +13: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 16:02:37 +02: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 08:49:29 -05: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-15 04:01:23 +13:00
GC::Ptr<SharedResourceRequest> m_resource_request;
LibWeb: Delay load event in more HTMLObjectElement situation
2024-11-26 15:29:07 +01: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 13:18:21 -05: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 12:16:11 -04: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 22:24:49 +02: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 14:41:33 +01: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 07:06:33 -04: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 14:41:33 +01: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 07:06:33 -04: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 14:41:33 +01:00
}
Reference in a new issue Copy permalink