This gets a basic synchronous GET request working. I've also tried to implement a portion of the procedures mentioned in the spec.
Blocks #2282
Source-Repo: https://github.com/servo/servo
Source-Revision: 14776522952df9990685e20151e74f4fed8742c9
This is a cleaner way to expose those functions, and makes it possible to
remove a significant amount code in rust-mozjs.
The assert() function is no longer exposed, as it was unused and not very
useful.
Source-Repo: https://github.com/servo/servo
Source-Revision: 78917f4e0f15c7e0dad3c9a1fc07c005bd090487
… and deal with properties whose initial value can be affected at computed-value time.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 9bca8a706e3187c6f7c154c59921f80c18249a52
Fix for android rendering.
Need to consider about getting accurate size framebuffer & window parameter respectively from android stack and follow up the stuffs on another platform.
Source-Repo: https://github.com/servo/servo
Source-Revision: 052d3cb0835470da281669b8dce1c9c51e8e7b9e
The performance of using == should now equal that of match, so many
identity methods can be simplified to a single line.
Fixes#1596.
Source-Repo: https://github.com/servo/servo
Source-Revision: 78a768ae5c39e1a2f2a666fc574a0332bf1ca28e
The defaultVisibility field was cloned from the C++ implementation,
where it tracks the difference between struct and class visibility.
Since no similar concept exists in Rust, it should be removed.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6d381959db18acc5c2f0c1891df8afe5df8372cb
There might be a "cleaner" rust way to separate the scope and invoke the drop() call?
Source-Repo: https://github.com/servo/servo
Source-Revision: bfffbe94eacb63fe7fe3fc2cfed433cb20cd4c41
Adds the ProgressEvent webidl and implementation according to the XHR spec.
Blocks #2282
Source-Repo: https://github.com/servo/servo
Source-Revision: a0922f9d7274e0781f30cdacf978104c224010f7
Use false for the glfw::Visible window hint to open a background window
on OS X. This requires an upgrade to glfw 3.0.4 in order for this to
also not steal focus.
This requires adding a new parameter to WindowMethods<A>::new.
Fixes https://github.com/mozilla/servo/issues/2363. r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 2a7889c061852b7d63782176cb35bfbc55c98f3f
The code was added as a debugging method [here](5663ca1eef), it's no longer used
Source-Repo: https://github.com/servo/servo
Source-Revision: 22c60609210e625cab4aa5b533e7b32d902df18f
Having to match the numbered results in /tmp with the failing tests was bothering me, and I figured it would be better to print the path with the failure.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0bb838a58b80dfbf63d09342e15d0af45277d073
Sometimes it's useful to bubble out the error from the URL parsing so the caller can deal with the result as per its needs.
[The XHR `open()`](http://xhr.spec.whatwg.org/#the-open()-method), for example, is one place where the bubbling out of an error is required.
Blocks #2282
Source-Repo: https://github.com/servo/servo
Source-Revision: 1879bf95ee40c74bf78164f10817d726a7c4c6b9
The long-term plan for SpiderMonkey is to eliminate JSContexts by merging
(most of) it into JSRuntime, so to future-proof our code, we should avoid
creating multiple JSContexts for the same JSRuntime.
However, this implies we'll have to use the same JSContext for objects in
different compartments, so we need to enter compartments. This is done by
using the with_compartment function.
Source-Repo: https://github.com/servo/servo
Source-Revision: d66197ae406e252c51bda48611ddfce78ecedb02
According to @pcwalton these used to be important for memory safety but are no longer needed now.
Source-Repo: https://github.com/servo/servo
Source-Revision: dedaa6a98e6455f13af8afee70be40654dcd008e
We can't replace the ones in the `style` crate because some functions expect generic `SmallVec`s.
I also did some reorganisation of the `smallvec` macros.
cc @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: b6c785692645b22c8b6119cb28109e85e703e430
The `.encode()`s from where the unused_result warnings come from seem to wrap an `encode()` and return `Ok(())`.
They should probably bubble the result out.
Source-Repo: https://github.com/servo/servo
Source-Revision: edb1547502012c2145ce1411dc923720134bb8f1
Is it reasonable to always expect success here for now?
Fixes#2246.
Source-Repo: https://github.com/servo/servo
Source-Revision: 310d2a19bbc1b8933f05cbd77c79df155ac00d94
As described in #1764, this strategy uses the following properties:
* DOM members are `JS<T>` types. These cannot be used with being explicitly rooted, but they are required for compiler-derived trace hooks.
* Methods that take DOM type arguments receive `&[mut] JSRef<T>`. These are rooted value references that are cloneable but cannot escape.
* Methods that return DOM values use `Unrooted<T>`. These are values that may or may not be rooted elsewhere, but callers must root them in order to interact with them in any way. One unsoundness hole exists - `Unrooted` values must be rooted ASAP, or there exists the danger that JSAPI calls could be made that could cause the underlying JS value to be GCed.
* All methods are implemented on `JSRef<T>`, enforcing the requirement that all DOM values are rooted for the duration of a method call (with a few exceptions for layout-related code, which cannot root values and therefore interacts with `JS<T>` and `&T` values - this is safe under the assumption that layout code interacts with DOM nodes that are in the tree, therefore rooted, and does not run concurrently with content code)
Source-Repo: https://github.com/servo/servo
Source-Revision: 731e66ff132e41cdc49bc5324c0e15be19c46ec2