Previous, it would return the original String straight from the
AttrValue, which might contain extraaneous whitespace. The spec
specifies to just join the tokens together with \x20
https://dom.spec.whatwg.org/#stringification-behavior
Fix for #6542 - <img> top-padding adds margin
I wrote this patch that makes the test from #6542 render as expected but I am not confident it is actually the right fix. Should the padding be included in the 'ascent' metric for images, or am I just introducing a bug that happens to offset the one I'm trying to fix?
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6565)
<!-- Reviewable:end -->
Only make a elements activatable when they have an href attribute.
I've tested this manually, by clicking on the "baz" in code like
```js
var a = document.body.appendChild(document.createElement("a"));
a.textContent = "bar ";
a.setAttribute("href", "http://www.yahoo.com");
var b = a.appendChild(document.createElement("a"));
b.textContent = "baz";
```
but I've not found a way to write an automated test.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6543)
<!-- Reviewable:end -->
I've tested this manually, by clicking on the "baz" in code like
```js
var a = document.body.appendChild(document.createElement("a"));
a.textContent = "bar ";
a.setAttribute("href", "http://www.yahoo.com");
var b = a.appendChild(document.createElement("a"));
b.textContent = "baz";
```
Before this change, the click is trapped by `b` and ignored there; after this
change, the click passes through `b` to `a`, where it is handled.
Unfortunately, I haven't found a way to write an automated test.
Refactor WebGL implementation to move logic inside the DOM interfaces
This improves the encapsulation and consistency in our WebGL
implementation.
Also allows to implement new methods such as `getShaderSource()`.
It will also allow us to use `delete()` in the destructors of them (note
that we will probably want to keep track of them from the context before).
Some concerns:
**Trait method repetition**:
I'm aware that the traits `WebGL{Buffer,Renderbuffer,Framebuffer,Texture}Helpers` are basically the same, but `delete()` and `id()` methods are everywhere. I've thought something like:
```rust
pub trait WebGLIdentifiable {
type WebGLId; // id is sometimes i32 (see WebGLUniformLocation)
fn id(&self) -> Self::WebGLId;
}
pub trait WebGLBindable {
fn bind(&self);
}
pub trait WebGLDeletable {
fn delete(&self);
}
```
But I'd want to know your opinion first.
**`renderer` repetition**:
Thought of moving the field: `renderer: Sender<CanvasMsg>` to `WebGLObject`, but I think it makes it way more complicated to read, and also a bit unnecessary, at least IMO (`WebGLObject` will never interact with the field directly). It would also mean that all `WebGLObject`s should have one, which is true at this moment, but maybe not with WebGL 2, for example.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6380)
<!-- Reviewable:end -->
This improves the encapsulation and consistency in our WebGL
implementation.
Also allows to implement new methods such as `getShaderSource()`.
It will also allow us to use `delete()` in the destructors of them (note
that we will want to keep track of them from the context).
Borrow the QueueData for WorkQueue::run.
This allows us to get rid of the raw pointers and unsafe dereferencing in
the parallel layout implementation.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6547)
<!-- Reviewable:end -->
layout: Outline the individual property cascading functions to reduce I-cache footprint.
Reduces the size of `properties::cascade` from over 100K of code to
under 5K. Due to the improved I-cache utilization, improves ARM scaling
on 4 cores by 15%.
r? @SimonSapin (feel free to punt to someone else if you like)
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6364)
<!-- Reviewable:end -->
I-cache footprint.
Reduces the size of `properties::cascade` from over 100K of code to
under 5K. Due to the improved I-cache utilization, improves ARM scaling
on 4 cores by 15%.
layout: Disable parallel display list building by default.
I've never see it result in a speedup. Actually, I don't think I've seen
it result in anything better than a 50% slowdown. The arithmetic
intensity is just too low, at least with the current algorithm.
Parallel DL building can still be enabled with a debug flag if the
algorithm is improved.
r? @metajack
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6365)
<!-- Reviewable:end -->
Implement crypto.getRandomValues()
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.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6505)
<!-- Reviewable:end -->
