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
Passing these around as strings is an anti-pattern, IMO.
Source-Repo: https://github.com/servo/servo
Source-Revision: cb336a18317195512a276971856081cb8ef86b0e
This changeset gets rid of the `FooView` phantom type in favor of a more brute force approach that just whitelists methods that layout is allowed to call. The set is surprisingly small now that layout isn't going to the DOM for much.
If this approach turns out not to scale, we can do something fancier, but I'd rather just have it be safe and secure first and then refactor later for programmer happiness.
r? @kmcallister
Source-Repo: https://github.com/servo/servo
Source-Revision: 824c7ac613ebb80bb432ff6425c5e25c642b6afb
This will allow us to stop going to the DOM in order to handle iframe
sizing. Instead we can just store the pipeline and frame IDs of iframes
inside the flow tree itself.
r? @kmcallister
Source-Repo: https://github.com/servo/servo
Source-Revision: aa1ebbbdb0243f098921103f02bb9b7dbcc40441
This fixes the computation of restyle damage on `color-change-text.html`, which can be seen with `RUST_LOG=servo::layout::layout_task`.
However we can't prune the layout traversals yet, because we don't reuse `Flow` objects between reflows, so we have no old values to fall back to.
I think this used to work because `FlowContexts` (as they were called then) were stored in a DOM node's `LayoutData` and reused. But it's possible that it never really worked, and my testing when I landed the restyle damage code was insufficient (I didn't understand the layout code nearly as well back then).
r? @pcwalton
Source-Repo: https://github.com/servo/servo
Source-Revision: 144737ce1b582952a894f29e30e16134c73b2464
To test this, execute the followings:
test_local_bookmark.html#text1
test_local_bookmark.html#text2
test_local_bookmark.html#text3
test_local_bookmark.html#top
test_local_bookmark.html#h3
test_local_bookmark.html#num
acid2.html#top
- The link from acid2.html works now. ( `<a href="#top">`)
Thanks to @metajack!
Source-Repo: https://github.com/servo/servo
Source-Revision: 0c4b10cc2cccd2263ad9e9b1c7e84d5093d26195
This replaces flow construction with a strict bottom-up tree traversal,
allowing for parallelism. Each step of the traversal creates a flow or
a `ConstructionItem`, similar to how Gecko works. {ib} splits are
handled by not creating `InlineFlow`s until the containing block is
reached.
This should be able to be incrementalized by storing the `Flow` from
layout to layout, and performing fixups during flow construction
and/or wiping containing blocks in a previous pass.
r? @larsbergstrom
Source-Repo: https://github.com/servo/servo
Source-Revision: 736a258c26b6118c617e6dccb65d75988bcf5ee9
This will fix#1201.
This maybe the work in progress.
@jdm:
* Should we pass `DOMString` directly to `dom::utils::null_str_as_...`?
* Do you have any good idea to update the comment in `CodegenRust.py`?
Source-Repo: https://github.com/servo/servo
Source-Revision: 7f13566d57b90468b0ab2a58fd2e4ba387510e4b
It's good enough for now, since we don't track document resources at all. Should be good enough for #841.
Source-Repo: https://github.com/servo/servo
Source-Revision: da4ca510496c5596ddc3593909ebd1db2f5bf957
Most work courtesy of @kmcallister.
I already reviewed Keegan's work, so just the last two commits need attention.
Source-Repo: https://github.com/servo/servo
Source-Revision: 352acbb8335fcf78f2d62dc781fa9d86b9368f9c
The bit I don't like about these changes is that I ended up hiding the document node from the CSS selecting/matching code, so it continues thinking of the document's first child as the root. When I tried to send the full tree including the document node to layout, the layout code refused to create any child flows. When I sent the document's first child without hiding the document, it saw inherited values for properties like font-family, and later tried to treat the document node as an Element when searching for named nodes.
Source-Repo: https://github.com/servo/servo
Source-Revision: 13644ccab1942c053c3fd5e4a19bb75d9ebe8739
This upgrades to this morning's master. We have unfortunately broken the Android build, but I will update that in a second pull request as I think it's more than a single upgrade behind.
Source-Repo: https://github.com/servo/servo
Source-Revision: 797143a1d3e09b4ddd35a1ce5948be424ec3f9ef
This doesn't resolve the big questions of how Servo will represent strings; it's just about doing the conversion correctly for our existing types.
Source-Repo: https://github.com/servo/servo
Source-Revision: ebe1c1353ca0ffe1f0e195f4ed66abb982f303ee
I believe this is all the preparatory work discussed in #1006 and #1057: The new 'style' crate implements the whole style system (including parsing, matching and cascading) and only depends on cssparser and util, so that gfx, script and main can all depend on it.
Next: porting the layout code to this. (Really, this time! I think.)
Source-Repo: https://github.com/servo/servo
Source-Revision: 6db57e6f72c85cd5233f431817f9344aed8eab87
--HG--
rename : servo/src/components/gfx/geometry.rs => servo/src/components/util/geometry.rs
Turns out that documents without a window `fail!` a lot, because we need the `cx` all over.
Source-Repo: https://github.com/servo/servo
Source-Revision: 509934cf65acb1061cf4b012556ff6782e3203c9
In preparation for removing it as part of making Document a Node.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8d3c7a2ded69f035f8fc98a38dd337237cb7db2a
I'm not happy about `is_in_doc`, but that should improve once @jdm lands his document-as-node changes.
Source-Repo: https://github.com/servo/servo
Source-Revision: b0ac5911ec8e818ff88e8177aa97415e7729141c
There are still a few instances of "wrapper"-ish names scattered throughout the code, but this is a good start.
Source-Repo: https://github.com/servo/servo
Source-Revision: 89dd9dd8eb2e473dffd5ad2d5d75012b15f75570
Fixes#1004. I haven't seen the other ones be reported, but I saw often saw `task <unnamed> failed at 'RenderChan.send: render port closed', /home/jdm/sdb/servo/src/components/gfx/render_task.rs:76`, `task <unnamed> failed at 'receiving on closed channel', /home/jdm/sdb/servo/src/compiler/rust/src/libstd/rt/comm.rs:487`, and failed assertions due to layout running after we had begun tearing down the window.
Source-Repo: https://github.com/servo/servo
Source-Revision: 096af85834e25d86487e82851331d93374782eac
This appears to fix the problem with the Rust logo stopping during the demo.
Though this is the right way to spawn a SpiderMonkey thread, I'm not entirely sure why this fixes the problem in all scenarios. With enough threads (i.e. `RUST_THREADS=32`), and running with some Rust patches that are available on master (which I applied during testing), I would expect work stealing to not allow starvation here. In my tests though I see the problem even with lots of threads, so this may yet indicate a scheduler bug. Still, SpiderMonkey should get its own thread.
Source-Repo: https://github.com/servo/servo
Source-Revision: be5deb2a680524b7f802d20bb058175b3853489b
Fixes#967 and #965
This has been wrong for a long time. Previously, only the pipeline associated with the root frame evicted would be shut down. 1) It shouldn't necessarily be closed, because there could be references to it still in the navigation context, and 2) Presumably none of the children pipelines of the root frame were ever exiting.
It's hard to test this right now because #965 covers up other pipeline exiting issues, but when that's fixed, a pathological case in which things would have broken down would be:
1) Load a page with an iframe that contains a link
2) Click the link
3) Press backspace to navigate back
4) Navigate to any new page, at which point the forward page would be evicted from the navigation context, and the outer frame's pipeline would be shut down improperly.
5) Press backspace, at which point there is no longer a pipeline for the old page, because it was shut down prematurely. Presumably this would cause a crash.
I also changed the FrameTree function ```find_mut``` to ```find``` because find_mut implies it's doing something to cause mutability, but the mutability is caused by the type of object being iterated over, nothing else.
Additionally, script was exiting completely when receiving an exit message. Instead, it needs to handle exit messages according to who sent it. It should only close the subframes of the frame whose pipeline sent the exit message. This is now fixed.
Inexplicably, script was also closing the compositor upon receiving an exit message. This doesn't seem like it'd ever be the right thing to do. *Edit: this is _only_ the right thing to do when received from the window.* I've fixed that. I don't think anyone shuts down the compositor now. *Edit: the script shuts down the compositor only when receiving an exit from the window.*
Source-Repo: https://github.com/servo/servo
Source-Revision: 401176b72d9ac9e4493ca27fca5aa5450500a333
* Profiler is now close to a no-op when ```-p``` is not passed in
* The profiler's printing ```Timer``` now stops looping when the profiler is closed
* Most task ```Chans``` are now newtype ```structs```
* Some more ```Cell``` removals in places where ```spawn_with``` is appropriate
Source-Repo: https://github.com/servo/servo
Source-Revision: e576a1cf7eb3191e6a740b8537517b28fbb4950c
Cells are generally less readable, and spawn_with makes many of them unnecessary.
Source-Repo: https://github.com/servo/servo
Source-Revision: b85497b76a7e002f816333fa2aa5fd2096ffce41
Haven't figured out what to do about page_from_context yet, but this is a big improvement.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8994dc3a1e2b62fe0fee65f84f46ac3fe17dbb9c
The rust-mozjs change is just updating it to tip; do not be alarmed.
Source-Repo: https://github.com/servo/servo
Source-Revision: 39252b25f792ae1b9c7e7d269083b18d29d9101a
