Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LibWeb: Navigables #18219

Merged
merged 68 commits into from Sep 16, 2023
Merged

LibWeb: Navigables #18219

merged 68 commits into from Sep 16, 2023

Conversation

kalenikaliaksandr
Copy link
Contributor

@kalenikaliaksandr kalenikaliaksandr commented Apr 7, 2023

This PR replaces all instances of FrameLoader with navigables navigation, which uses Fetch under the hood, in the following places:

  • HTMLIFrameElement
  • HTMLObjectElement
  • HTMLAnchorElement
  • HTMLFormElement
  • Location
  • Window
  • WebDriver APIs

I also attempted to remove code that is no longer used after this transition, but there may still be something left.

In addition to using Fetch in navigation, another notable outcome of implementing navigables is that now all traversal history is centralized and managed by traversables. Although, with this PR, history still lives on the Chrome side, it will be possible to modify that by introducing new IPC calls for page reloading and history traversal.

Correctness progression I am aware of:

Collateral damage I am aware of:

  • RemoteBrowsingContext is gone because BrowsingContext does not have navigate method anymore so it does not make sense. This breaks (?) navigation from WebDriver APIs. We will have to fix that in the future by introducing RemoveNavigable or inventing better abstraction for that.

@github-actions github-actions bot added the 👀 pr-needs-review PR needs review from a maintainer or community member label Apr 7, 2023
@kalenikaliaksandr kalenikaliaksandr marked this pull request as draft April 7, 2023 15:24
@github-actions github-actions bot removed the 👀 pr-needs-review PR needs review from a maintainer or community member label Apr 7, 2023
@kalenikaliaksandr kalenikaliaksandr force-pushed the navigable branch 14 times, most recently from c4f5db1 to 4e287cd Compare April 14, 2023 17:59
Was replaced by close_top_level_traversable()
Those are not used anymore after moving to navigables.
During the destruction of a navigable, we need to use the pointer to
the navigable that was saved at the beginning of the function. This
is because `Node::navigable()` will return a nullptr in subsequent
steps after the navigable's document becomes inactive.
This is not in the spec, but we need to make sure that "apply the
history step" for initial navigation to about:blank in iframe is
applied before subsequent navigations. Otherwise, "set ongoing
navigation" call during "about:blank" traversal might abort subsequent
ongoing navigation which is not expected to happen.
This fixes issue reproducing with following steps:
1. Node::insert_before() adopts a node into another document.
2. Node::insert_before() runs insertion steps for adopted node (adopted
   node style is not invalidated yet).
3. Insertion steps execute spin_until() on event loop.
4. The next task on event loop does Document::update_style() which
   requires layout tree rebuild.
5. Layout tree rebuild fails because there is a node with invalidated
   style.
Those are superseded by methods to navigate `javascript:` url in
navigables.
Adding this check was a mistake because although the navigation id
changes to null in step 2, it still has to proceed and apply the
history step.
If `load_document()` is called with a response that has a mime type we
can't use to build a document, we should return nullptr as the spec
says, instead of crashing. Also we should not crash if error happened
during parsing.
@awesomekling
Copy link
Member

Okay, I've tested this quite a bit and it seems stable enough that we can continue iterating in tree. Nice work! :^)

@awesomekling awesomekling merged commit 4446858 into SerenityOS:master Sep 16, 2023
9 of 11 checks passed
@github-actions github-actions bot removed the 👀 pr-needs-review PR needs review from a maintainer or community member label Sep 16, 2023
@nico nico mentioned this pull request Nov 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants