Event dispatch rewritten to align to spec, activate on clicks better
I went over the changes to the event dispatch spec that had accumulated over the past few years, rewriting dispatch/invoke/inner-invoke almost completely and modifying other code where it was relevant. Most of the remaining obvious deviations from spec are things that will only come up when we start handling events in shadow DOM.
I am pushing now because I want to see CI test results, but please do not approve this PR just if automated test improvements look good. I may have broken some actual UI interactions in the course of fixing synthetic events, and some manual testing is needed, including checking that manual interactions with interactive content continue to fire the events they're supposed to.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#25384 and fix#22783 and fix#25199
<!-- Either: -->
- [ ] There are automated tests for the synthetic-click parts of these changes, BUT the effects on real UI events need some manual testing before merging
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
security: check target and source origin before executing JS url
implement replacement-enabled flag as a HistoryEntryReplacement enum
add source origin string on loaddata
add LoadOrigin
iframe: remove optional load-data
auxiliaries: add load-data into info
constellation: remove url from Pipeline::new
check load origin: link to whatwg issue
switch loadorigin toplevel to constellation
- this conforms to follow-hyperlinks spec step 13
- this conforms to window-open spec step 14.3
- replace uses of `referrer_url` with `referrer`
- in Request class, change "no-referrer" to ""
- set websocket fetch referrer to "no-referrer"
Now they follow the new spec stated at:
https://html.spec.whatwg.org/multipage/links.html#following-hyperlinks-2
It seems like choosing a browsing context is already done in the
follow_hyperlink method, so I have removed the TODO in
activation_behavior for HTMLAreaElement.
The tests in tests/wpt/web-platform-tests/html/semantics/links/following-hyperlinks/
pass in release builds, but still don't pass in dev build,
since the timeout in
tests/wpt/web-platform-tests/html/semantics/links/following-hyperlinks/activation-behavior.window.js
seems to be too short for dev builds.
Navigating to error page on failed URL parsing is still not implemented.
There seem to be potential code duplication in activation_behavior
methods for both htmlanchorelement.rs and htmlareaelement.rs, in:
let referrer_policy = match self.RelList().Contains("noreferrer".into()) {
true => Some(ReferrerPolicy::NoReferrer),
false => None,
};
I didn't pull them out to a separate function since I don't know
where I would put that new function.
Fixes warnings from rust-lang/rust#44229 when `--enable-commonmark` is
passed to rustdoc.
This is mostly a global find-and-replace for bare URIs on lines by
themselves in doc comments.
http://www.robohornet.org gives a score of 101.36 on master,
and 102.68 with this PR. The latter is slightly better,
but probably within noise level.
So it looks like this PR does not affect DOM performance.
This is expected since `Box::new` is defined as:
```rust
impl<T> Box<T> {
#[inline(always)]
pub fn new(x: T) -> Box<T> {
box x
}
}
```
With inlining, it should compile to the same as box syntax.
In a later PR, DomRoot<T> will become a type alias of Root<Dom<T>>,
where Root<T> will be able to handle all the things that need to be
rooted that have a stable traceable address that doesn't move for the
whole lifetime of the root. Stay tuned.
I don't want to do such a gratuitous rename, but with all the other types
now having "Dom" as part of their name, and especially with "DomOnceCell",
I feel like the other cell type that we already have should also follow
the convention. That argument loses weight though when we realise there
is still DOMString and other things.
It could be used to have mutable JSVal fields without GC barriers.
With the removal of that trait, MutHeap and MutNullableHeap can respectively
be replaced by MutJS and MutNullableJS.
