This is a rebase of #7842 that also adds a test.
Fixes#4183.
@Yoric, how's this look to you?
Source-Repo: https://github.com/servo/servo
Source-Revision: af1690f3036bc329101bbd6f4e877672d58ca5e0
Review of documentation that was missing needed.
Fixes#8833.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7438bc0425749989b8aab084a34ff3fff2ea6679
This patch makes DOMString an opaque wrapper round String (currently it's a transparent wrapper).
The changes are:
* Replacing DOMString(foo) by DOMString::from(foo).
* Replacing foo.0 by String::from(foo).
* Adding functions clear, push_str and extend for in-place mutation of DOMStrings.
* Replacing DOMString by String in other threads (devtools, storage and filereader).
* Making DOMString implement !Send.
* Removing the pub attribute from the contents of DOMString.
This enables experimenting with other string representations in the DOM.
Source-Repo: https://github.com/servo/servo
Source-Revision: 62acdd303b78951885c2c90747b31f318907d6c9
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
Removes all those messy FooCast structures in InheritTypes.rs.
Source-Repo: https://github.com/servo/servo
Source-Revision: 674589c370d978f543e71f995d58c5b28e6e9842
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
Now that `JSRef<T>` is gone, there is no need to have helper traits.
Source-Repo: https://github.com/servo/servo
Source-Revision: 909429702972d53bf02dfe9a4aa93ea0cb588cf4
(for #6924) - I took this because the confusion was actually caused by me while working on #6829
Source-Repo: https://github.com/servo/servo
Source-Revision: 0466766b2c946a781d917b3dac8f87714719369c
The integration is off by default for now. You can try it out with `./mach build --features "script/plugins/clippy"`.
We're using a branch of clippy with some of the lints changed to Allow, either because they don't apply to us, or because they're noisy and dwarf other warnings (but still should be fixed)
After going through the rest of Servo's warnings I'll figure out which lints we should be keeping.
There's a cargo bug with optional deps that makes it hard for this to work with Cargo.lock -- so this PR contains no changes to lockfiles (and running the build with clippy on may dirty the lockfile, though it gets fixed later)
Source-Repo: https://github.com/servo/servo
Source-Revision: 50e1c967e4299c1515575f73d407f5f6b977d818
and `for foo in bar.iter_mut(), and for foo in bar.into_iter()
(continuation of #7197)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0d6d6a05009606dfbbfc9765d7dc2c745c18f6a5
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
…s for frame treese in script tasks.
This underreports by a significant amount, since only Document, Window and CharacterData (ie. text) nodes are fully represented. That being said, every HTML element in the tree is measured, but only counted as a Node. It's easy to improve this, it just requires adding the appropriate HeapSizeOf derives and increasing the granularity of `measure_memory_for_eventtarget`. google.com shows a dom-tree value of 0.24 MB for me at the moment.
r? @nnethercote
Source-Repo: https://github.com/servo/servo
Source-Revision: 84e25befdd97cf74fb00707dbe150d59d980e977
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
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
SpiderMonkey provides an extremely fine-grained breakdown of memory
usage, but for Servo we aggregate the measurements into a small number
of coarse buckets, which seems appropriate for the current level of
detail provided by Servo's memory profiler. Sample output:
```
| 17.41 MiB -- url(file:///home/njn/moz/servo/../servo-static-suite/wikipedia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyclopedia.html)
| 7.32 MiB -- js
| 3.07 MiB -- malloc-heap
| 3.00 MiB -- gc-heap
| 2.48 MiB -- used
| 0.34 MiB -- decommitted
| 0.09 MiB -- unused
| 0.09 MiB -- admin
| 1.25 MiB -- non-heap
```
Most of the changes are plumbing to get the script task communicating
with the memory profiler task.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2b0bdbe1c195f2f6dd7671981999d622c505fbc5
Didn't touch mozjs or rust-mozjs because implementing that in the code generator didn't seem too easy. I'm using the same workaround that the TextDecoder does.
Using the OsRng should be the right choice here? As the OS keeps state for us we wouldn't need to have a global rng instance to keep around.
Fixes#4666.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0222628264423a67bf98775be83dcf2f85211ab
fixes#6524. I had to make an additional change not mentioned in the ticket - adding the `#[feature]` to enable deriving custom traits but I assume that's expected at this time.
Source-Repo: https://github.com/servo/servo
Source-Revision: bbb39082e0f640400546d2084a450a8675820a82
> Here it is.
>
> ~~There's two major things that are unfinished here:~~
> - ~~Dealing with the unroot_must_root lint. I'm not sure about the value of this lint with the new rooting API.~~ Done.
> - ~~Updating the Cargo.locks to point to the new SM and SM binding.~~ Done.
>
> I also included my fixes for the rust update, but these will disappear in a rebase. A rust update is necessary to support calling `Drop` on `Heap<T>` correctly when `Heap<T>` is inside a `Rc<T>`. Otherwise `&self` points to the wrong location.
>
> Incremental GC is disabled here. I'm not sure how to deal with the incremental barriers so that's left for later.
>
> Generational GC works. SM doesn't work without it.
>
> The biggest change here is to the rooting API. `Root` was made movable, and `Temporary` and `JSRef` was removed. Movable `Root`s means there's no need for `Temporary`, and `JSRef`s aren't needed generally since it can be assumed that being able to obtain a reference to a dom object means it's already rooted. References have their lifetime bound to the Roots that provided them. DOM objects that haven't passed through `reflect_dom_object` don't need to be rooted, and DOM objects that have passed through `reflect_dom_object` can't be obtained without being rooted through `native_from_reflector_jsmanaged` or `JS::<T>::root()`.
>
> Support for `Heap<T>` ended up messier than I expected. It's split into two commits, but only because it's a bit difficult to fold them together. Supporting `Heap<T>` properly requires that that `Heap::<T>::set()` be called on something that won't move. I removed the Copy and Clone trait from `Heap<T>` so `Cell` can't hold `Heap<T>` - only `UnsafeCell` can hold it.
>
> `CallbackObject` is a bit tricky - I moved all callbacks into `Rc<T>` in order to make sure that the pointer inside to a `*mut JSObject` doesn't move. This is necessary for supporting `Heap<T>`.
>
> `RootedCollectionSet` is very general purpose now. Anything with `JSTraceable` can be rooted by `RootedCollectionSet`/`RootedTraceable`. Right now, `RootedTraceable` is only used to hold down dom objects before they're fully attached to their reflector. I had to make a custom mechanism to dispatch the trace call - couldn't figure out how to get trait objects working for this case.
>
> This has been tested with the following zeal settings:
>
> GC after every allocation
> JS_GC_ZEAL=2,1
>
> GC after every 100 allocations (important for catching use-after-free bugs)
> JS_GC_ZEAL=2,100
>
> Verify pre barriers
> JS_GC_ZEAL=4,1
>
> Verify post barriers
> JS_GC_ZEAL=11,1
Source-Repo: https://github.com/servo/servo
Source-Revision: e7808c526c348fea5e3b48af70b7f1a066652097
This is useful for union types, in cases where we need MutNullableHeap<NodeOrString>.
Source-Repo: https://github.com/servo/servo
Source-Revision: b0ddd8149b04db6bceba0c0b8de852acc1086838
"Links to the multipage version of the specification are unfortunately
likely to break over time."
-- https://html.spec.whatwg.org/multipage/asefij.html
This commit removes all references to the specific pages when viewing
WHATWG using multipage mode. I went through all these links and they
redirect fine.
Regex used to generate this commit:
`s_whatwg.org/multipage/.*#_whatwg.org/multipage/#_g`
Source-Repo: https://github.com/servo/servo
Source-Revision: d90fe2b0889dee4eb27693aca7670969d5253424
This implements a framework for opting in to receiving network events asynchronously. It also converts XMLHttpRequest to use them, and paves the way for better support for synchronous XHR using on-demand, targeted event loops instead of spinning the global event loop. This gives us complete feature parity with the existing XHR implementation, using fewer threads than before in the async case.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3151497d498b001b4a783dce0595615c6fc40936
The notification for new globals now works for nested workers too (refs #5309)
Source-Repo: https://github.com/servo/servo
Source-Revision: a277036dd9b461c434261b4ba5e88bc228c8a0dd
