(Note that only `getAllResponseHeaders()` is supported at the moment, I'll be adding the other header methods later.)
Source-Repo: https://github.com/servo/servo
Source-Revision: 28e3c1734048217cd2194ea37c887911ad03e894
Right now, the load is kicked off inside the parser glue. This is unfortunate
for several reasons:
1) we'd like to replace the current parser (libhubbub) by our own parser,
written in Rust, so code intertwined with the parser will have to be
rewritten;
2) it is impossible to support dynamically (i.e. from script) created iframes
in this way;
3) the code flow around loading subdocuments is complicated needlessly.
This commit adds the constellation channel (on which the message to actually
load the document is sent) as a field on the Page, to allow HTMLIFrameElement
to access it.
In rewriting the code, support for dynamically created iframes is added, and
a task failure is avoided when the value of the src attribute can not be
parsed.
Source-Repo: https://github.com/servo/servo
Source-Revision: 1e361e8b6f04d7848d40fd19090511c0c3f16a97
There is no particular leason to initilaize js_info lazily.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9a71af38b98560376d3db2c210f91c1cf0770acd
Fix#2383
These changes introduce `FooEvent::new_uninitialized()` constructor. This constructor use to create `FooEvent` without calling `FooEvent::InitFooEvent`.
#2383 says integrating `FooEvent::new()` and `InitFooEvent`, but we need to preserve simple `FooEvent::new_uninitialized()` for `document.createEvent()`.
@jdm r?
Source-Repo: https://github.com/servo/servo
Source-Revision: 5334d8bb255c64f6d33250972a7ccf22de2afe34
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
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
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
The ~"string" expression is being removed in upstream rust.
Source-Repo: https://github.com/servo/servo
Source-Revision: 09374f07e2cd152b2126c49c623f00997c36cfb2
I'd rather do this before it turns out that a rust upgrade removed `~[T]` behind our back.
Source-Repo: https://github.com/servo/servo
Source-Revision: 77d9f7294799459b126e61b2dc0b0b27b74a6ba7
r? @metajack
Note that all pending submodule PRs must be landed before this should be given r+.
Source-Repo: https://github.com/servo/servo
Source-Revision: 493aa2cdf30fb2ff5886c714030a20d714764b67
- see #356
- To decrease the conversion code, `JS<Node>` -> `Node`, I added API methods to `NodeHelpers`.
- I added APIs to `Page` not `Document` because I had thought that their APIs returns the hitted nodes address in the "page".
Source-Repo: https://github.com/servo/servo
Source-Revision: 6d89e67194acef35c40d03e5889dfa3c6af1502a
...k-related reasons.
Under the hood, this requires treating the I Tried pipeline as a new load instead of a replacement, since the failure-handling code interacts poorly with the rest of the replacement code when we get a series of staggered failures over time from the various pipeline components.
Source-Repo: https://github.com/servo/servo
Source-Revision: cc33a721ab3cf777becf51cddbfd8fe2c1eba568
This fixes two `RefCell<T> is already borrowed` failures when reloading an
existing pipeline, both caused by functions trying to modify `Pipeline::url`
or `ScriptTask::url` while a reference to a previous borrow is still in scope.
Note: After applying this patch, there are some painting issues after navigating back.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7326df044c8f1badf8c37a16cdf31caf446b66df
A js::rust::Compartment is little more than a glorified pointer to the
reflector of a window, so there's no good reason to use it. Instead, this
commit passes a JS<Window> directly when it's necessary.
This also means that we now have to use JS_DefineFunctions rather than
Compartment::define_functions; I believe the former is clearer to the reader
than the extra indirection involved in the latter calling through three
reopsitories.
This commit also simplifies ScriptTask::load to reuse the 'cx' local that is
in scope already, rather than refetching it through js_info.
Source-Repo: https://github.com/servo/servo
Source-Revision: 77b5c1f4f63c59ee88ad26363420fef6e2468ce1
see #2116
I add an `is_interval` field, so that when the `TimerData` is passed by `SetInterval`, we will not delete it from `active_timers`.
Also I think maybe we can extract the code in `ClearTimeout` and `ClearInterval` into another method to avoid duplicate.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7441dae1aff4966e40ef3cf4129f307d23e2eeba
This was part of @jdm's vtable branch, but I think it makes sense regardless of how we deal with that branch.
Source-Repo: https://github.com/servo/servo
Source-Revision: 69fbbbdf339c370b2eeb87983b550b9055ee6f83
A HashMap allows easily looking up a timer and canceling it in
Window.ClearTimeout.
Fixes#1477.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3eac31394cb509ce7e4fa61a3543f6ec22c8bde4
For review only - don't approve yet (need to squash and land submodule updates first).
critic? @metajack
Source-Repo: https://github.com/servo/servo
Source-Revision: f7aa6e3d9b8bfcc0565624f1094241b3b8658bd8
