There were a few things that were bothering me with `SetBody`:
* The 'Step 3' comment is in the wrong place
* The logic of 'Step 4' comes before 'Step 3'
* 'Step 5' was not documented
There were a few things that were bothering me with `SetBody`:
* The 'Step 3' comment is in the wrong place
* The logic of 'Step 4' comes before 'Step 3'
* 'Step 5' was not documented
Fixes#1871
I thought I'd take a look at this for a first contribution to servo. A couple of things I'm not 100% sure on are:
1) `get_proto_or_iface_array` returns a `*mut *mut JSObj`, which I'm assuming is really an array of pointers to `JSObj`s. So dropping its return value will drop the memory for the array of pointers. Do we also need to drop each element, or is that handled by GC?
2) Are there any tests I need to add for this? I don't know if there are existing leak tests, or if leaks are mostly discovered by profiling.
Based on [ebalint](https://github.com/ebalint)'s original patch, this commit implements the linear and radial gradients for the canvas. The PR also includes test cases.
Depends on #4623 and servo/rust-azure#136.
This addresses #849. This PR cannot land until the corresponding PR (https://github.com/servo/html5ever/pull/91) in html5ever lands. I've done some simple testing of this code, but I don't consider it thorougly tested yet. I wanted to start getting feedback about the overall design before I spend more time polishing the details, and testing.
Implements view-source protocol by having a view-source handler, and modifying the content type to be text/plain if that is used.
Implements text/plain handling. This allows view-source content to display as plain text.
Example usage:
./mach run http://cd.pn/x.txt
./mach run view-source:http://tinyvid.tv/
This fixes issue #4181. Issue #3649 includes "support text/plain" so this possibly fixes some of that issue as well.
This changeset implements the beginnings of fine-grained measurement of
Servo's data structures.
- It adds a new `SizeOf` trait, which is used to measure the memory used
by heap data structures, and implements it for some std types: Box,
String, Option, Arc, Vec, and DList.
- It adds a new `MemoryReporter` trait which is used to report memory
measurements from other threads to the memory profiler. Reporters are
registered and unregistered with the memory profiler, and the memory
profiler makes measurement requests of reporters when necessary.
- It plumbs a MemoryProfilerChan through to the layout task so it can
register a memory reporter.
- It implements the `SizeOf` trait for `DisplayList` and associated
types, and adds a memory reporter that uses it.
The display list hits 14.77 MiB when viewing
tests/html/perf-rainbow.html, and 2.51 MiB when viewing the Guardians of
the Galaxy Wikipedia page from servo-static-suite. Example output:
0.29: display-list::http://www.reddit.com/
0.00: display-list::http://static.adzerk.net/reddit/ads.html?sr=-reddit.com,loggedout&bust2#http://www.reddit.com
0.00: display-list::http://www.reddit.com/static/createadframe.html
There are a number of FIXME comments indicating sub-optimal things. This
is a big enough change for now that doing them as follow-ups seems best.
The history is now recorded per frame, but needs to be exposed in a followup PR.
Also fixes a race condition that occurs loading iframes under heavy CPU load.
This ensures that iframes never do a reflow / layout until they have a valid
window size set from their parent frame.
This follows the recommendation from issue #4181. A handler
for 'view-source' delegates to the HTTP loader. In that
loader I check for view-source, adjust the URL to be the
URL to be viewed and modify the Content-Type header to be
text/plain.
This doesn't actually result in the source being
viewed as rendering text/plain is not yet implemented.
@jdm This initial version has a few outstanding issues that I wanted to invite input on. Specifically:
1. I had some difficulty finding a home for the `StorageType` enum. Structs defined outside of the `script` module don't seem to be able to use the `#[jstraceable]` annotation and the `net` module (where `StorageTask` lives) doesn't have access to `script`. Per Simon Sapin's suggestion, I worked around this temporarily by creating a `TraceableStorageType` stand-in struct that was traceable and which could be translated into a regular `StorageType` when being sent to the `StorageTask`. Unsure of the best way to resolve this hack. Thoughts?
2. Apart from the `Storage` constructor used in `Window::SessionStorage` and the new `Window::LocalStorage`, there's also a method called `Storage::Constructor`. I'm unclear on what (if anything) will actually invoke this, so I'm not sure which variant of `StorageType` to use here. I've temporarily created an `Unknown` variant of `StorageType` as a placeholder.
3. I discovered that the web platform tests directory's localStorage tests. Many of them now pass despite the configured expectation that they fail. However, several do not pass. Is there a good way for me to add debug logging or otherwise get a sense of which assertion failed / what went wrong?
Thanks for your continued help!
