- 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".
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.
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.
This also explicitly disallows dictionary members without a default value, as
the code for those doesn't currently compile.
This is the second step of my planned rewrite of the dictionary initialization
that will remove the default values we currently use to initialize the
dictionary struct in the 'new' function.
This moves the code in callers more in line with conversions for other types
and ensures the default values given to the dictionary fields (as defined by
the defaultValue function in CGDictionary.impl) do not escape the 'new'
method. The new code is also more in line with the code used by the
FromJSValConvertible trait.
This is the first step of my planned rewrite of the dictionary initialization
that will remove the default values entirely and reduce the code
duplication in the 'Init' (now 'new') function.
This change allows us to use the code even in cases where we return a
Result type rather than a JSBool. Interface, primitive and union types
already get this right.
The previous code would return success from the JSNative with a pending
exception, potentially leading to assertion failures inside the JS engine
later.
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.
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.
There is no good reason to have both unwrap_object and unwrap_jsmanaged.
Removing unwrap_object simplifies the codegen and makes further
simplifications easier.
