Age | Commit message (Collapse) | Author |
|
The big global refactor left some stragglers behind for atomicity.
Clean up the rest, and remove a ton of includes of LibWeb/HTML/Window.h
|
|
These classes only needed Window to get at its realm. Pass a realm
directly to construct Crypto, Encoding, HRT, IntersectionObserver,
NavigationTiming, Page, RequestIdleCallback, Selection, Streams, URL,
and XML classes.
|
|
Ideally we'd use a different one for each, but this is fine.
|
|
This allows us to print messages in inline scripts. Also add an example
of this in the welcome page to test this.
|
|
This is used by window.close() programmatically, but of course the user
can also decide to close a top-level browsing context at any time by
closing the tab.
|
|
|
|
Otherwise we'd repaint the next time our "caret blink" timer would fire
(or something else caused a repaint). This made selection feel sluggish.
|
|
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.
|
|
|
|
|
|
This patch implements the "create a new browsing context" function from
the HTML spec and replaces our existing logic with it.
The big difference is that browsing contexts now initially navigate to
"about:blank" instead of starting out in a strange "empty" state.
This makes it possible for websites to create a new iframe and start
scripting inside it right away, without having to load an URL into it.
|
|
This PageClient callback was never used for anything.
|
|
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
|
|
We can assign a raw pointer directly to a WeakPtr without null-checking
it first.
|
|
To achieve this goal:
- The Browser unveils "/tmp/portal/filesystemaccess"
- Pass the page through LoadRequest => ResourceLoader
- ResourceLoader requests a file to the FileSystemAccessServer via IPC
- OutOfProcessWebView handles it and sends a file descriptor back to
the Page.
|
|
|
|
|
|
|
|
|
|
This improves our spec compliance by allowing the user to click
non-element nodes (like text) and having the click be registered with
the parent element (like a div or button). This makes Fandom's cookie
accept button work if you click the text. Additionally, the events test
page contains a test to check the target element, which would previously
not exist when we fired the event at a non-element.
|
|
|
|
|
|
|
|
The WebView url wouldn't update so reload in Tab would still use the
previous URL before any left click navigation.
I am unsure if there was any good reason not to dispatch the event when
there are no modifiers.
|
|
|
|
This is now the source of truth for 'user enabled/disabled scripting',
but it has to ask the window's page, which actually stores the setting.
Also use this new functionality in two places where it was previously
marked as a FIXME.
|
|
This commit moves a couple more special cases in mouse event handling to
handle_mouseup. Additionally, it gets rid of the special casing with
should_dispatch_event and only fires a click event to the EventTarget
when the left mouse button is clicked. Finally it restores the link
context menu callback that was lost during 0fc8c65.
|
|
This commit moves the regular handling of links to the anchor elements'
activation behavior, and implements a few auxiliary algorithms as
defined by the HTML specification.
Note that certain things such as javascript links, fragments and opening
a new tab are still handled directly in EventHandler, but they have been
moved to handle_mouseup so that it behaves closer to how it would if it
was entirely up-to-spec.
|
|
|
|
This is a convenience accessor to avoid having to say this everywhere:
result.paintable->layout_node().dom_node()
Instead, you can now do:
result.dom_node()
|
|
Using "HitTestResult with null paintable" as a way to signal misses was
unnecessarily confusing. Let's use Optional instead. :^)
|
|
This now also takes a FloatPoint instead of an IntPoint to avoid
excessive rounding when multiple transforms apply on top of each other.
|
|
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules
"The compiler is more likely to get the default semantics right and
you cannot implement these functions better than the compiler."
|
|
We want to make sure the layout and paint trees are up-to-date before
handling any mouse events.
|
|
This commit is messy due to the Paintable and Layout classes being
tangled together.
The RadioButton, CheckBox and ButtonBox classes are now subclasses of
FormAssociatedLabelableNode. This subclass separates these layout nodes
from LabelableNode, which is also the superclass of non-form associated
labelable nodes (Progress).
ButtonPaintable, CheckBoxPaintable and RadioButtonPaintable no longer
call events on DOM nodes directly from their mouse event handlers;
instead, all the functionality is now directly in EventHandler, which
dispatches the related events. handle_mousedown and related methods
return a bool indicating whether the event handling should proceed.
Paintable classes can now return an alternative DOM::Node which should
be the target of the mouse event. Labels use this to indicate that the
labeled control should be the target of the mouse events.
HTMLInputElement put its activation behavior on run_activation_behavior,
which wasn't actually called anywhere and had to be manually called by
other places. We now use activation_behavior which is used by
EventDispatcher.
This commit also brings HTMLInputElement closer to spec by removing the
did_foo functions that did ad-hoc event dispatching and unifies the
behavior under run_input_activation_behavior.
|
|
|
|
|
|
Everything related to hit testing is better off using the painting tree.
The thing being mousemoved over is a paintable, so let's hand that out
directly instead of the corresponding layout node.
|
|
Input events have nothing to do with layout, so let's not send them to
layout nodes.
The job of Paintable starts to become clear. It represents a paintable
item that can be rendered into the viewport, which means it can also
be targeted by the mouse cursor.
|
|
|
|
The Window object is part of the HTML spec. :^)
https://html.spec.whatwg.org/multipage/window-object.html
|
|
This filters out the key code 'Esc' so it won't be printed to editable
text nodes, e.g. text <input> elements.
|
|
|
|
|
|
Make sure to refresh the contents of text-<input> when pressing
backspace or delete key.
The methods 'handle_insert()' and 'handle_delete()' already had the call
to 'm_browsing_context.active_document()->force_layout()' so let us also
add it to 'handle_delete_character_after()'.
|
|
|
|
|
|
This implements EventHandler::focus_previous_element() so we can cycle
backwards through focusable elements on a web page with Shift+Tab.
|
|
This is basically the same as `auto` in the spec, so let's just treat
them as identical for now. Gets rid of some Discord CSS parser
spam. :^)
|
|
|