Instead of passing a function it is also possible to pass a string,
which is then evaluated as a classic script.
This means we now support the following example from the "timer
initialization steps", step 16 - except that it runs the timers in
reverse order, so the `log` result is `"TWO ONE "`.
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-initialisation-steps
var log = '';
function logger(s) { log += s + ' '; }
setTimeout({ toString: function () {
setTimeout("logger('ONE')", 100);
return "logger('TWO')";
} }, 100);
Since we expose these strings to web content via LengthStyleValue,
let's not have non-standard brackets in there to confuse anyone trying
to parse these values. :^)
This patch adds the "has a rendering opportunity" concept from the spec
to BrowsingContext and uses it to filter out contexts that are unable
to render right now when doing the event loop's rendering updates.
Note that we actually consider all contexts to have a rendering
opportunity at all times right now. Coming up with reasons to avoid
rendering is left as a FIXME. :^)
DOM::Document has some special lifetime rules to support the DOM
lifetime semantics expected on the web. Any DOM node will keep its
document alive as well, even after the document's ref-count has reached
zero. This is achieved by the Document::m_referencing_node_count
counter.
Because of this mechanism, we can't VERIFY(m_ref_count) in TreeNode
where T may be a DOM::Document.
We now invoke DOM timer callbacks via HTML tasks. This brings callback
sequencing closer to the spec, although there are still many
imperfections in this area.
This introduces 3 classes: NodeList, StaticNodeList and LiveNodeList.
NodeList is the base of the static and live versions. Static is a
snapshot whereas live acts on the underlying data and thus inhibits
the same issues we have currently with HTMLCollection.
They were split into separate classes to not have them weirdly
mis-mashed together.
The create functions for static and live both return a NNRP to the base
class. This is to prevent having to do awkward casting at creation
and/or return, as the bindings expect to see the base NodeList only.
There are a handful of FIXME's here, but this seems generally good.
Note that CSS *values* don't get serialized in a spec-compliant way
since we currently rely on StyleValue::to_string() which is ad-hoc.
A flex-basis of zero doesn't actually mean that the preferred size of
the particular Box is 0. It means that the Box should take the least
amount of space possible while still accomodating the content inside.
We catch and circumvent this now right when the flex-basis property gets
read for the FlexFormattingContext.
This isn't mentioned anywhere in the seemingly relevant portions of the
spec, however thanks to this answer https://stackoverflow.com/a/47579078
(which is not entirely correct about width either) lead to the behavior
that is wanted and used by other Browsers.
