<!-- 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 do not require tests because removing unused imports
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 4e277d74e83bf9c3e1d237d1f779753c4c6a3a6e
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because refactoring
Source-Repo: https://github.com/servo/servo
Source-Revision: e8cf789fc56dfbc4bfd6145d3bd1a30aa9459c95
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy --faster` does not report any errors
- [x] These changes fix#10851, related to #11131
- [x] These changes do not require tests because the implementation is partial and can't work alone
1. Add new backend to `Blob` and a `BlobImpl` struct to abstract multiple backends
2. Rewrite most interfaces of `Blob` to accommodate the change
3. Change the `read` behaviour of `FileReader`, considering the case when blob is file-backed and not cached
The design is still immature, welcome comments!
- [x] I used `DOMRefCell` to cache the bytes in `BlobImpl`, is it sound?
- [x] The interfaces (like `BlobImpl::get_bytes`) handle requests in a default-to-empty way when the inner `DataSlice` is not cached. It might be possible to handle this condition better.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3d7b17681dc9c20358fda9efc72575feb968cc81
First part of #11292, this just includes support of `[Func]`.
Source-Repo: https://github.com/servo/servo
Source-Revision: 073c5e3b6b8950c01c9e5691925d24787fd06d53
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because it is refactoring
Source-Repo: https://github.com/servo/servo
Source-Revision: bcea0ada27de694cd0c465d04fd35eba70503d62
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 --faster` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
Either:
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because _____
Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process.
It's a pointless abstraction that propagates the obsolete chan terminology,
swaps the order in which the sender and receiver are returned, and hides a
source of panics.
Source-Repo: https://github.com/servo/servo
Source-Revision: 27c25e859a45c3d79c85e96b85ec5226a3231e10
Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data:
- [ ] `./mach build -d` does not report any errors (didn't try to compile past a rustc upgrade on airplane wifi)
- [X] `./mach test-tidy --faster` does not report any errors
- [X] These changes fix#11218 (github issue number if applicable).
Either:
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because we don't have testing infrastructure for profiling.
Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process.
Source-Repo: https://github.com/servo/servo
Source-Revision: 96a86bd952c4c0e41d6164fbd16244ea4420106a
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 --faster` does not report any errors
- [ ] These changes fix#11234 (github issue number if applicable).
Either:
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process.
Source-Repo: https://github.com/servo/servo
Source-Revision: bed6d45b35df9f0d3ef734633e40f9be2e0d749d
This adds an `api_base_url` function to global objects, which fixes `open-url-base.htm` under XMLHttpRequest.
Source-Repo: https://github.com/servo/servo
Source-Revision: 07304235cc88c3bb823e072e31da2dadcf0ed1be
Adds support for terminating DOM workers. A closing flag was added to
WorkerGlobalScope per the spec.
Rebased #6652, with some comments addressed.
Fixes#4427.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0aa049b0aaf39df979234dff1ed01ff5d9aa5c5
This is a large-ish PR that contains the following:
* A new directory is created under `components/script/` called `task_source`, which houses all the stuff for different task sources. Note that the ones that I have now aren't exhaustive - there are more task sources than just the generic ones.
* A `DOMManipulationTaskMsg` which eliminates some usage of `Runnable`s to fire events. Instead, they send event information to the `DOMManipulationTaskSource` and lets the `ScriptTask` handle all the event firing.
* Re-added `fn script_chan`, since I can't think of any other way to give `Trusted` values an appropriate sender.
* Rewrote step 7 of [the end](https://html.spec.whatwg.org/multipage/syntax.html#the-end) to make use of the `DOMManipulationTaskSource`
Partial #7959
Source-Repo: https://github.com/servo/servo
Source-Revision: 740965e39f4d62e5807d21734ed9a7a881eca392
This PR splits the `ActiveTimers` abstraction into
- `OneshotTimers` for scheduling "arbitrary" oneshot timers, such as XHR timeouts, and
- `JsTimers`, based on `OneshotTimers`, for scheduling JS timers (`setTimeout`/`setInterval`).
The result is mich cleaner and the timer initialization steps now closely resemble the specification.
**Notes**
- The second and third commit are strictly renames and code rearrangements.
- I'm not particularily happy with the `OneshotTimerCallback` enum and its circular dependency with `XHRTimeoutCallback`, but I couldn't come up with anything better.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8f278109ce84aa482ccc0d25938970435fb6e536
components/script/dom/bindings/global.rs modified -> all *_thread_source occurrences renamed to *_task_source to comply with spec
Source-Repo: https://github.com/servo/servo
Source-Revision: 63dc161b773775c6755a604ec04b81c0bc479bf3
Review of documentation that was missing needed.
Fixes#8833.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7438bc0425749989b8aab084a34ff3fff2ea6679
Alright, this is it. Finally the fix for #3396. :D
I'll add two comments via reviewable in a second.
Source-Repo: https://github.com/servo/servo
Source-Revision: df81cd7ce9de4823ad966f873639ed06ca368e4c
This is an rough solution to the issue described in #3396. XHRs still do their own thing and an overall clean up is in order. Before I do that, though, I'd really like someone to sign off on the overall idea.
There's one major difference to what jdm layed out #3396: The timers remain with the window/worker and only the earliest expiring one is coordinated with the dedicated timer thread.
That means both the timer thread and the window/worker have to keep track of which timer expires next, which feels a bit wonky. However, the upshot is that there's no need for communication with the timer thread when a pipeline is frozen, thawed or dropped.
Most relvant parts are
- the [`TimerScheduler`](6f5f661958 (diff-74137a6f50ab38e7a1e4d16920a66ce7R73)), which is the new per-constellation timer task and
- the [`ActiveTimers`](6f5f661958 (diff-86707d952414a2860b78bcf6c1db8e2eR34)) which is what's left on the window/worker side.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2de5407cdabef67ed03b2ad4edf4a22541d77875
This is a direct extract from my abandoned PR for a lint (#7546), along with some rather clumsy modifications (only on `components/script/dom/mod.rs` and `components/style/lib.rs`), because I had to sort some of the files again to make peace with tidy, which hasn't been educated about sorting yet!
Source-Repo: https://github.com/servo/servo
Source-Revision: a7208869f2903e36f9b2f540b55b50283d7df466
Elided almost all the lifetimes and removed needless returns. Mostly done by sed + manual fixes.
r? @nox
Source-Repo: https://github.com/servo/servo
Source-Revision: c2c2646d37614ece5869af861993c3d619f6e003
Now that `JSRef<T>` is gone, there is no need to have helper traits.
Source-Repo: https://github.com/servo/servo
Source-Revision: 909429702972d53bf02dfe9a4aa93ea0cb588cf4
Expands on the work by @wilmoz and cleans up the existing errors. Closes#7180. Closes#7111.
Source-Repo: https://github.com/servo/servo
Source-Revision: e74825f9fde8e222f4ba9bb24b2c2a3864c73e5f
... for #3734, which is also one of the oldest issues. (/cc @jdm)
Source-Repo: https://github.com/servo/servo
Source-Revision: 6a52ec94840fbaf43a29d76879e2b59542a9963d
Also adds HeapSizeOf implementations/derive for some types. I've used "Cannot calculate Heap size" as a reason everywhere, because my imagination is rather limited. If you'd like me to change this message for specific types, please write something like this: "Trusted - Cannot calculate Heap size for Trusted" so that it would be easier for me to replace them through a script :)
Source-Repo: https://github.com/servo/servo
Source-Revision: a03616f379c255cc6c9b6e1d04dd7d98bd9926ce
For now, this just gives some purpose to the abandoned receiver and later selects over the two receivers (for #6767). (oh wait, forgot to check the local build - there are still a few errors)...
Source-Repo: https://github.com/servo/servo
Source-Revision: effb17b3368769baaf5247908b26b7f0dd370ea3
This change makes Servo use serialized messages over IPC channels for resource loading. The goal is to make it easier to make Servo multiprocess in the future. This patch does not make Servo multiprocess now; there are many other channels that need to be changed to IPC before that can happen. It does introduce a dependency on https://github.com/serde-rs/serde and https://github.com/pcwalton/ipc-channel for the first time.
At the moment, `ipc-channel` uses JSON for serialization. This is because serde does not yet have official support for bincode. When serde gains support for bincode, I'll switch to that. For now, however, the JSON encoding and decoding will constitute a significant performance regression in resource loading.
To avoid having to send boxed `AsyncResponseTarget` trait objects across process boundaries, this series of commits changes `AsyncResponseTarget` to wrap a sender only. It is then the client's responsibility to spawn a thread to proxy calls from that sender to the consumer of the resource data. This only had to be done in a few places. In the future, we may want to collapse those threads into one per process to reduce overhead. (It is impossible to continue to use `AsyncResponseTarget` as a boxed trait object across processes, regardless of how much work is done on `ipc-channel`. Vtables are fundamentally incompatible with IPC across mutually untrusting processes.)
In general, I was pretty pleased with how this turned out. The main changes are adding serialization functionality to various objects that `serde` does not know how to serialize natively—the most complicated being Hyper objects—and reworking `AsyncResponseTarget`. The overall structure of the code is unchanged, and other than `AsyncResponseTarget` no functionality was lost in moving to serialization and IPC.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 2eb122f394651232abd683fc576a5c4288bf277f
To actually make the multiprocess communication work, we'll need to
reroute the task creation to the pipeline or the compositor. But this
works as a first step.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: 1764267379a00b96a1df89f3917299a0c6fd325c
