Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibWeb/HTML/HTMLObjectElement.h

72 lines
2.1 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
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
*
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: 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
#include <LibWeb/HTML/BrowsingContextContainer.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: 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
#include <LibWeb/Loader/ImageLoader.h>
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: 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
: public BrowsingContextContainer
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: 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
, public ResourceClient {
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
WEB_PLATFORM_OBJECT(HTMLObjectElement, BrowsingContextContainer)
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
FORM_ASSOCIATED_ELEMENT(BrowsingContextContainer, HTMLObjectElement)
enum class Representation {
Unknown,
Image,
NestedBrowsingContext,
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;
Everywhere: Run clang-format
2022-04-01 20:58:27 +03:00
virtual void parse_attribute(FlyString const& name, String const& value) 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 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
String data() const;
void set_data(String const& data) { set_attribute(HTML::AttributeNames::data, data); }
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
String type() const { return attribute(HTML::AttributeNames::type); }
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: 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: Compute element style in Layout::TreeBuilder Instead of making each Layout::Node compute style for itself, we now compute it in TreeBuilder before even calling create_layout_node(). For non-element DOM nodes, we create the style and layout tree node in TreeBuilder. This allows us to move create_layout_node() from DOM::Node to DOM::Element.
2022-02-05 13:17:01 +01:00
virtual RefPtr<Layout::Node> create_layout_node(NonnullRefPtr<CSS::StyleProperties>) 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: Correctly handle unknown MIME types in HTMLObjectElement We were using the literal string "unknown" as the unknown MIME type, which caused us to treat the object as a nested browsing context (as "unknown" does not start with "image/"). Use an Optional instead to prevent this mishap.
2022-03-24 11:03:07 -04:00
void run_object_representation_handler_steps(Optional<String> resource_type);
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();
void convert_resource_to_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
// ^ResourceClient
virtual void resource_did_load() override;
virtual void resource_did_fail() override;
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
Representation m_representation { Representation::Unknown };
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
Optional<ImageLoader> m_image_loader;
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+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
WRAPPER_HACK(HTMLObjectElement, Web::HTML)
Reference in a new issue Copy permalink