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.
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.
@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!
Table layout code has been refactored to push the spacing down to
rowgroups and rows; this will aid the implementation of
`border-collapse` as well.
r? @SimonSapin
`cellspacing` attribute per HTML5 § 14.3.9.
Table layout code has been refactored to push the spacing down to
rowgroups and rows; this will aid the implementation of
`border-collapse` as well.
This commit also fixes two nasty issues in table layout:
* In fixed layout, extra space would not be divided among columns that
had auto width but had nonzero minimum width.
* In automatic layout, extra space would be distributed to constrained
columns as well even if unconstrained columns with percentage equal to
zero were present.
As noted by @bholley. "unwrap" is confusing because we are
both stripping off wrappers *and* getting a native from a
reflector. Changing the "unwrap" usage to "native_from_reflector"
for clarity.
This renames 'unwrap' to 'native_from_reflector' and
'unwrap_jsmanaged' to 'native_from_reflector_jsmanaged'.
This patch enables the use of `arc()` on the canvas.
I couldn't add reftest this time, as it involves some antialiasing issues, and so the reference doesn't match.
