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
The specs currently have only Document; this may well change, but the split won't be along the lines we've implemented right now. In the meantime, this simplifies our code quite a bit.
Source-Repo: https://github.com/servo/servo
Source-Revision: 22760b6665c75f6908bcfd7cad4de111187ac6f7
We probably leak some threads and resources, e.g. when the script task crashes and doesn't get a chance to send layout data back to layout to be deallocated.
Not tested with iframes yet.
Source-Repo: https://github.com/servo/servo
Source-Revision: f1de0b738134f153a398866f76d1b5d0213d3c02
Fix#790 partially.
I am sure I need to merge with @jdm's event handler for dom.
As son as the event handler is implemented, I will fix.
And this is implement Hover Event. If over element, Currently Full reflow.
After PR, will make partial reflow.
Thank you!
Source-Repo: https://github.com/servo/servo
Source-Revision: ccfd595d6ebd0dcd7a81d1ef9fa05801cd955f8a
Add a LoadComplete message so that script informs the constellation, which can then inform the compositor (and anyone else, later) about the completion of loading a page. This is important for ref tests, which should not emit a PNG until load has completed, even if we perform a composite before then.
Note that we must *also* wait for the `ready_state` to indicate that additionally layout has completed any associated reflow with the page, otherwise we could get the `LoadComplete` while the final reflow is still in progress and thus would write out the `n-1`'th reflow result.
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: e9a0c8184f1af460583fe5ab2615e01d08ffc22f
This builds on top of #1560 (… which I realize now may confuse Critic)
This refactors Namespace to reduce the overall amount of copying and conversion. In particular, it makes parsed selectors contain Namespace enums rather than strings.
Source-Repo: https://github.com/servo/servo
Source-Revision: edda06115ac61c691e7762bcdb3e70b48b1c65bc
The old code was used by both layout and script, but was erroneously
borrowing for the layout case (which causes parallelism
problems). script now uses only `value_ref()` or `get_attribute()`, and
layout now has its own unsafe version that dances around the borrows of
`@mut Attr`.
Source-Repo: https://github.com/servo/servo
Source-Revision: d11e4318871e8ed237292985f30063f719bbfb0d
Pointers to DOM nodes from layout could go stale if incremental reflow
does not correctly destroy dead nodes. Therefore, we ask the JavaScript
garbage collector to verify that each DOM node is indeed a valid pointer
before calling event handlers on it, and fail otherwise.
Depends on the `get-addressable-gc-thing` branches of `mozjs` and `rust-mozjs`.
r? @jdm
Source-Repo: https://github.com/servo/servo
Source-Revision: c876335d227d4f826b5ece66fb388134cf29fce4
