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

60 lines
1.7 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: 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: 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 HTMLElement
, 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: 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
FORM_ASSOCIATED_ELEMENT(HTMLElement, HTMLObjectElement)
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:
LibWeb: Add a whole bunch of HTML DOM bindings Note that these aren't full implementations of the bindings. This mostly implements the low hanging fruit (namely, basic reflections) There are some attributes that should be USVString instead of DOMString. However, USVString is a slightly different definition of DOMString, so it should suffice for now.
2020-07-27 05:04:26 +01:00
using WrapperType = Bindings::HTMLObjectElementWrapper;
LibWeb: Move QualifiedName into the Web::DOM namespace
2022-02-18 21:00:52 +01:00
HTMLObjectElement(DOM::Document&, DOM::QualifiedName);
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
virtual ~HTMLObjectElement() override;
virtual void parse_attribute(const FlyString& name, const String& value) override;
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: 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 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();
void run_object_representation_handler_steps(StringView resource_type);
void run_object_representation_completed_steps();
void run_object_representation_fallback_steps();
void convert_resource_to_image();
LibWeb: Update HTMLObjectElement's children on fallback state changes This is another event upon which the task to determine an object's respresentation must be queued: * one of the element's ancestor object elements changes to or from showing its fallback content For example, on Acid2, the image for the eyes is nested below an object that is designed to fail to load. This ensures the eyes will render as the fallback of the failed parent object.
2022-03-23 14:28:54 -04:00
void update_layout_and_child_objects();
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;
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
bool m_should_show_fallback_content { false };
};
}
Reference in a new issue Copy permalink