Remove tidy blacklist for 'script/dom/bindings/*'
Recently, I found myself reading through the Python codegen scripts that
live in 'components/script/dom/bindings/*' and noticed that there were
many tidy violations: unnecessary semicolons, weird spacing, unused
variables, lack of license headers, etc. Considering these files are now
living in our tree and mostly maintained directly by contributors of
Servo (as opposed to being from upstream), I feel these files should not
be excluded from our normal tidy process. This commit removes the
blacklist on these files and fixes all tidy violations.
I added these subdirectories to the blacklist because they appear to be
maintained upstream somewhere else:
* "components/script/dom/bindings/codegen/parser/*",
* "components/script/dom/bindings/codegen/ply/*",
Also, I added a few '# noqa' comments which tells us to ignore the
flake8 errors for that line; they are mostly for unused/undefined
variables. I chose to ignore these (instead of fixing them) to make the
work for this commit simpler for me.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6580)
<!-- Reviewable:end -->
Recently, I found myself reading through the Python codegen scripts that
live in 'components/script/dom/bindings/*' and noticed that there were
many tidy violations: unnecessary semicolons, weird spacing, unused
variables, lack of license headers, etc. Considering these files are now
living in our tree and mostly maintained directly by contributors of
Servo (as opposed to being from upstream), I feel these files should not
be excluded from our normal tidy process. This commit removes the
blacklist on these files and fixes all tidy violations.
I added these subdirectories to the blacklist because they appear to be
maintained upstream somewhere else:
* "components/script/dom/bindings/codegen/parser/*",
* "components/script/dom/bindings/codegen/ply/*",
Also, I added a '# noqa' comment which tells us to ignore the
flake8 errors for that line. I chose to ignore this (instead of fixing
it) to make the work for this commit simpler for me.
Reduce the scope of the allowed unsafe code in context.rs.
Since I made unsafe code opt-in in layout, the unsafe code in this module has
been reduced to a single unsafe impl, so there is no reason to allow it in
the entire module.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6576)
<!-- Reviewable:end -->
Since I made unsafe code opt-in in layout, the unsafe code in this module has
been reduced to a single unsafe impl, so there is no reason to allow it in
the entire module.
Move LayerBuffer cache to the compositor
Now that NativeDisplay can be shared between the compositor and the
paint task, we can move the LayerBuffer cache to the compositor. This
allows surfaces to be potentially reused between different paint tasks
and will eventually allow OpenGL contexts to be preserved between
instances of GL rasterization.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6530)
<!-- Reviewable:end -->
Now that NativeDisplay can be shared between the compositor and the
paint task, we can move the LayerBuffer cache to the compositor. This
allows surfaces to be potentially reused between different paint tasks
and will eventually allow OpenGL contexts to be preserved between
instances of GL rasterization.
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.
