Currently, there are a few linting functions that only run on certain
filetypes (determined by the file extension). Prior to this commit, the
special cases were handled in a parent function with a conditional. This
commit changes the system so each linting function gets passed a
filename so the function can determine whether it should run or not
based on the file extension.
I also refactored flake8 linting slightly. From what I've read so far of
the code, flake8 itself will only print the results directly to stdout
(though the linter would report the quantity of errors detected).
Prior to this commit, we would let flake8 print directly to stdout and
just determine if there were >0 errors reported. This commit (sort of
hackily) temporarily captures stdout when we call flake8 so we can do
what we want with the output, allowing us to `yield` the line number
and message like we do with the other linting functions.
In my opinion, both of these changes isolate specific behaviors/checks
into their respective linting functions instead of having them handled
at a more global level.
In addition to the changes above:
* The whitespace linter now runs on WebIDL and TOML files
* The license header linter now runs on WebIDL files
Source-Repo: https://github.com/servo/servo
Source-Revision: 7c8922c0c39616559b580b4a363ebe2a8c6b3ba8
Gecko doesn't really follow the spec but it seems to throw a HierarchyRequest error when parent is null.
Any ideas who I should talk to about fixing the spec to account for the null checks?
Source-Repo: https://github.com/servo/servo
Source-Revision: acf47a02cf38b5c82e7c78cc1f6660a7daa9969a
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.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0f8095b950dd144497919cfea65a1f154ed3ae9a
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
This commit was generated using the following commands:
```
find . -iname "*.webidl" -type f -print0 | xargs -0 sed -i '' 's/http:\(.*\)github.io/https:\1github.io/g'
```
```
find . -iname "*.rs" -type f -print0 | xargs -0 sed -i '' 's/http:\(.*\)github.io/https:\1github.io/g'
```
Source-Repo: https://github.com/servo/servo
Source-Revision: 342ea7a44b26f9cc701b2a10757c4ac0aec93aeb
I'm not sure if I like how I mostly just duplicated the code in CodegenRust.py, so that might need to be refactored.
Instead of just calling it Image, we might want to call it ConstructorImage, to make it clear that it's a constructor. Anyone have an opinion on that?
There seems to be a bug in the HTMLImageElement getter/setter as the value is 0 regardless of what I do. This seems to be unrelated to my commits, so I'll investigate that separately.
Source-Repo: https://github.com/servo/servo
Source-Revision: 57cc84b2935c429c92774649275625a7fd63973c
Fixes#6322.
Still no mutation whatsoever in URLUtils.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8c784ceeea39014cdc79bb4c7f614948cc8beda1
The first step of the implementation for shadows in canvas.
r? @nox @jdm
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: f163f2bf0d32861ea20470d405bb517ed5b09e84
This commit implements:
* WebGLFramebuffer
* WebGLRenderbuffer
* WebGLTexture
And adds the following methods to `WebGLRenderingContext`:
* create{Texture,Framebuffer,Renderbuffer}
* bind{Texture,Framebuffer,Renderbuffer}
* destroy{Buffer,Texture,Framebuffer,Renderbuffer}
Fixes:
* WebGLUniform location shouldn't inherit from WebGLObject.
Known Issues:
* WebGL objects have to be destroyed on drop, we may want to keep a reference to the context, or maybe a clone of the renderer to achieve this
Also refactors a huge part of the current implementation, to allow
failing on creation of different WebGL objects.
Blocked on https://github.com/servo/gleam/pull/22
A reftest for most of the added functionality is not doable right now,
we need a few more functions in order to upload a texture, for example.
Source-Repo: https://github.com/servo/servo
Source-Revision: e09c555a41b0803388e54013ac8885fb789a0fa6
This implements the `canvas`, `drawingBufferHeight` and `drawingBufferWidth` getters to `WebGLRenderingContext`, and an initial version of `getParameter`.
r? @jdm or @nox?
Source-Repo: https://github.com/servo/servo
Source-Revision: 042737793b1995ad93dc093ea12ec986b99e64b8
r? @jdm
I couldn't add the `getContextAttributes` method since `CodegenRust`
doesn't know how to return a dictionary value, I'll take a look at it ASAP.
I think the helper functions can return directly the renderer, since they're used just for that, but I wanted to hear your opinions about this.
By the way I'm interested in adding more serious tests for WebGL, and I think the [khronos conformance suit](https://github.com/KhronosGroup/WebGL/tree/master/conformance-suites/1.0.3) should be the best option.
Should I try to integrate it in wpt, or making a `tests/webgl` directory (or similar) inside the servo tree? (Maybe this question should be for @Ms2ger)
Source-Repo: https://github.com/servo/servo
Source-Revision: 0de09b936e5e37c15b7865157a98ad78b1077659
Implement NodeIterator's basic functionality. (Fixes#1235) But the cases for node removals are not implemented yet.
r? @jdm
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: 2b52006b1c503a24d5e832934d3265d45e425f40
Fix#6063Fix#6062
Fixed definition of Close and Send in WebSocket.webidl and updated implementation in websocket.rs.
Source-Repo: https://github.com/servo/servo
Source-Revision: fe8760cce206ede76b71ccf3cc94fa37addddfc9
This property determines the background positioning area, that is the position of
the origin of an image specified using the 'background-image' CSS property.
'background-origin' is ignored when background-attachment is fixed.
Spec: http://dev.w3.org/csswg/css-backgrounds-3/#background-originFixes#6045.
r? @pcwalton
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: 8c402728247c73268df9389948ee9a9d9e4063b2
Implemented getter and setter of the attributes.
r? @jdm
cc @yichoi
Source-Repo: https://github.com/servo/servo
Source-Revision: 10d8200a54c833a52a757c3c591f69ad0e824f86
The actual boundary points are behind a Rc<_> value to let nodes be able to store weak references to them in the future.
Source-Repo: https://github.com/servo/servo
Source-Revision: 15c4372a8be9c2b73d9e09bd7684484e48d220e8
The proxy stringifiers called through {}.toString.call() (obj_toString) shouldn't use the stringifier.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2c177794408bfbb5f8d6042f38639a5cba5eb2e5
This add some properties to the style system and a new flow type, but the larger issues of dealing with fragmentation in the flow tree is still an open question.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1e150140bd12624ad357e3168fb496079fb8ec7c
