...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
