Update WebSocket blocked ports to match the Fetch spec
Adresses #9949.
This adds a function that tests whether a request should be blocked or not based on it's url's scheme and port. It also adds testing for port restriction to the `main_fetch` method. More info in eb07418c83.
@Ms2ger In https://github.com/whatwg/html/issues/841, @annevk proposes to remove port restrictions from websockets. Should we go ahead do that, given that the spec hasn't been changed yet?
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10014)
<!-- Reviewable:end -->
style: Compute damage for text nodes.
They have styles just like elements do.
Allows a dynamic change of `display: none` to `display: inline` to work.
Closes#9868.
r? @mbrubeck
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/9997)
<!-- Reviewable:end -->
Use lazy_static for HOST_TABLE.
This might change behaviour if the file is changed between Servo startup and
the moment HOST_TABLE is first accessed. I don't think we care.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9988)
<!-- Reviewable:end -->
test websocket origin set in worker
Fixes#9535
This crashes and I'm not sure how to debug it (and whether it's a problem with the browser or more likely a problem with the test):
```
./mach test-wpt /websockets/opening-handshake/003-sets-origin.worker --log-raw wpt.log Running 1 tests in web-platform-tests
▶ CRASH [expected OK] /websockets/opening-handshake/003-sets-origin.worker
Ran 1 tests finished in 2.0 seconds.
• 0 ran as expected. 0 tests skipped.
• 1 tests crashed unexpectedly
```
Also, should the test file be in `/websockets/` or `/websockets/opening-handshake/`?
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9737)
<!-- Reviewable:end -->
Add test for get action URL planned navigation
Mutate action URL doesn't need to be tested, since the existing urlencoded.html already tests it.
This new test currently fails, because of the weirdness in calling `testframe.contentWindow`. It returns null for this test, but not for urlencoded.html. Can't figure out why.
Fixes#9690
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9735)
<!-- Reviewable:end -->
Don't re-resolve already-resolved generated content
This fixes#7846, a failure in the "quotes-036.htm" test. Servo lays out this test correctly in its initial layout, but then messes it up in any relayout (whether it's an incremental or full layout).
The problem is that the ResolveGeneratedContent traversal is not safe to run more than once on the same flow. It mutates some GeneratedContent fragments into ScannedText fragments, but leaves others unmodified (in particular, those that generate empty content). The next time layout runs, these remaining GeneratedContent fragments are processed *again* but with an incorrect correct quote nesting level (because some of the surrounding GeneratedContent fragments are gone).
This patch ensures that each GeneratedContent fragment is resolved only once.
r? @pcwalton
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9969)
<!-- Reviewable:end -->
Add the scrollWidth and scrollHeight extensions to the element interface
Add the `scrollWidth` and `scrollHeight` extensions to the element interface. My goal was to create a method that encompassed getting `scrollWidth`, `scrollHeight`, `scrollTop`, and `scrollLeft`.
I also noted that `clientHeight` and `clientWidth` to not handle the root element and the body element correctly.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9824)
<!-- Reviewable:end -->
Fix work list order after split_line_at_last_known_good_position
This fixes a bug in line splitting caused by the following actions when `LineBreaker::split_line_at_last_known_good_position` is called:
1. Push some number of previous fragments onto the front of the work list.
2. Push the current fragment back onto the front work list.
This resulted in the work list being out of order. The correct order is action 2 followed by action 1. Fixes#9830. r? @pcwalton
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9961)
<!-- Reviewable:end -->
This fixes a bug in line splitting caused by the following actions when
`LineBreaker::split_line_at_last_known_good_position` is called:
1. Push some number of previous fragments onto the front of the work list.
2. Push the current fragment back onto the front work list.
This resulted in the work list being out of order. The correct order is
action 2 followed by action 1. Fixes#9830.
This fixes#7846, a failure in the "quotes-036.htm" test. Servo lays out this
test correctly in its initial layout, but then messes it up in any relayout
(whether it's an incremental or full layout).
The problem is that the ResolveGeneratedContent traversal is not safe to run
more than once on the same flow. It mutates some GeneratedContent fragments
into ScannedText fragments, but leaves others unmodified (in particular,
those that generate empty content). The next time layout runs, these remaining
GeneratedContent fragments are processed *again* but with an incorrect correct
quote nesting level (because some of the surrounding GeneratedContent
fragments are gone).
This patch ensures that each GeneratedContent fragment is resolved only once.
Moved synthetic_click_actiavtion out of Activatable trait so it can be
called by all elements (not just activatable). Calls appropriately
from click. Also updates the isdisabled check in click to check for all
types of elements
Update heartbeats and energymon profiler dependencies
Heartbeats now on crates.io.
Updates to energymon interface for energy profiling.
Profiling script for Android.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9926)
<!-- Reviewable:end -->
Add Tests For Asynchronous Fetch Calls With Filtered Responses
I've added two tests using async_fetch intended to create filtered responses. I caught and fixed a bug where waiting for response.body to be completed would never pass for Opaque or OpaqueRedirect, since their response.body is always `Empty`.
As always, I'd appreciate review and feedback! I don't plan to write new tests, but I will gladly patch up any gaps in the current tests.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9907)
<!-- Reviewable:end -->
correctly send secure cookies after hsts url match
Fixes#8100, where sites in the hsts list were not recieving secure
cookies if the site was originally loading using a plain http url.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9780)
<!-- Reviewable:end -->
Set response.body Asynchronously In Fetch
Following having finished making Fetch asynchronous, response.body should be set asynchronously, since it's the major goal of calling Fetch. So far, I've made the body wrapped in Arc<Mutex<>>, and I've wrapped a new thread around the part where it's set. I've also discovered that the fetch_async function makes step 8 of Main Fetch obsolete, and I've commented it appropriately.
I'm currently having a hard time with the thread for setting response.body, though. @jdm suggested I have the body set continually, block by block, but my implementation for that runs so slow that I can't finish running my fetch test suite in reasonable time. @KiChjang pointed out that a lot of the lag is due to how response.body currently stores everything inside a Vec. Changing the storage container seems to be both necessary and beyond the scope of the time I have to work on this.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.svg" height="40" alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/9850)
<!-- Reviewable:end -->
