The previous code would return success from the JSNative with a pending
exception, potentially leading to assertion failures inside the JS engine
later.
Fixes#2121
I thought this would be better than passing an `Option<ResourceTask>` to `parse_css` because it avoids having to handle the potential failure at runtime when unwrapping.
No test included, but the error was reproducible by running content/test_getBoundingClientRect.html, and this fixes it. Glad to find a way to add an explicit test if need be.
On Android, our feeble GPU graphics stack is even less reliable than it is on Linux. To make it easier to bring Android devices online, this patch defaults to CPU rendering, which is much more stable and, frankly, faster.
r? @metajack
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.
This reverts [some changes made during the 2014-03-04 Rust upgrade](bbac8aa5c3 (diff-d084c1d37003c83f26aa4dac0e8d9e6bL221)). @larsberg, what was the reason for preferring the unsafe `.to_ascii_nocheck()`?
r? @larsberg
By forgetting the Some(), we caused type inference to convert to Option<T>
for optional non-nullable primitive arguments, and to Option<Option<T>> for
optional nullable primitive arguments (essentially the same thing). This
change brings the primitive codegen in line with the DOMString codegen.
Using distinct types for optionality and nullability would have prevented
this issue.
By forgetting the Some(), we caused type inference to convert to Option<T>
for optional non-nullable primitive arguments, and to Option<Option<T>> for
optional nullable primitive arguments (essentially the same thing). This
change brings the primitive codegen in line with the DOMString codegen.
Using distinct types for optionality and nullability would have prevented
this issue.
This fixes an issue where a ChildFrameTree is inserted into a clone of its parent, rather than its "real" parent, as noted in #2124.
This moves `FrameTree::iter` and the methods that depend on it into a new trait that is implemented on `Rc<FrameTree>`, since it's safe to clone an `Rc<FrameTree>`.
r? @larsbergstrom
We are calling `get` when we should call `borrow` or `borrow_mut`. This is causing bugs with iframes because we append the child frame to a copy of the parent's `children` vector rather than the original.
r? @larsbergstrom
We are calling `get` when we should call `borrow` or `borrow_mut`. This is
causing bugs with iframes because we append to a copy of the `children` vector
rather than the original.
There is no good reason to have both unwrap_object and unwrap_jsmanaged.
Removing unwrap_object simplifies the codegen and makes further
simplifications easier.
There is no good reason to have both unwrap_object and unwrap_jsmanaged.
Removing unwrap_object simplifies the codegen and makes further
simplifications easier.
