Age | Commit message (Collapse) | Author |
|
While I was implementing IDL special operations, I noticed that for
global platform objects (e.g. WindowObject), the IDL spec makes their
prototype immutable.
https://heycam.github.io/webidl/#platform-object-setprototypeof
|
|
|
|
|
|
A legacy platform object is a non-global platform object that
implements a special operation. A special operation is a getter, setter
and/or deleter. This is particularly used for old collection types,
such as HTMLCollection, NodeList, etc.
This will be used to make these spec-compliant and remove their custom
wrappers. Additionally, it will be used to implement collections that
we don't have yet, such as DOMStringMap.
|
|
This needs to be accessible for implementing IDL legacy platform
objects.
|
|
|
|
This is a curious thing that occurs more often than you'd think in
minified JavaScript:
a: b: c: for (...) { ... break b; ... }
|
|
When we encounter a default clause in a switch statement, we should not
execute it immediately, instead we need to wait until all case clauses
have been executed as a matching case clause can break from the
switch/case.
The code is nowhere close to the spec, so instead of fixing it properly
I just made it slightly worse, but correct. Needs a complete refactor at
some point.
|
|
This API allows authors to schedule a serialized JS callback that will
get invoked at the next spec-allowed opportunity.
|
|
We now fire "pageshow" events at the appropriate time during document
loading (done by the parser.)
Note that there are no corresponding "pagehide" events yet.
|
|
This will be used to determine whether "pageshow" and "pagehide" events
are appropriate. We won't actually make use of it until we implement
more of history traversal and document unloading.
|
|
The only difference from what we were already doing is that setting the
same ready state twice no longer fires a "readystatechange" event.
I don't think that could happen in practice though.
|
|
|
|
Let's log "unhandled exception" messages in red text so that they stand
out better among lots of other debug logging.
|
|
For flags that are not mapped to a string this message prints DT_??,
which isn't really useful.
|
|
These are found in some libraries, and LibELF doesn't know how to handle
them, not even their name. Adding these definitions should at least help
readelf display information correctly, but more work is needed to
actually implement them.
|
|
A copy of the same mapping was found both in LibELF and in the readelf
utility, which uses LibELF; keeping them both is redundant and removing
the duplicate saves (a bit of) space.
|
|
You can open files since #9979, so let's show the path there
to distinguish open theme files more easily!
|
|
We have to mark the EventListener objects so that we can tell them apart
from listeners added via the addEventListener() API.
This makes element.onfoo getters actually return the handler function.
|
|
|
|
We don't need to set m_script_ready in the callback that gets invoked
precisely because m_script_ready has been set. :^)
|
|
|
|
|
|
We will now spin in "the end" until there are no more "things delaying
the load event". Of course, nothing actually uses this yet, and there
are a lot of things that need to.
|
|
|
|
|
|
Style is needed to lay out and paint a document, but we can't do either
those when the document isn't attached to a browsing context.
|
|
Also add a spec link and some comments.
|
|
|
|
All EventTarget subclasses except Window do the same exact thing in
their overrides, so let's just share an implementation in the base.
|
|
|
|
13e526de43847ac86d74e3cb0be2d6b930f1d46f added the feature to new Layer
dialog. This patch adds it to Image dialog to stay consistent across
the app. :^)
|
|
The ideal solution here is to implement a more spec-compliant event
loop, but while we get all the pieces in place for that, this at least
makes the HTML event loop a bit more responsive since it never has to
wait for a 16ms timer to fire.
|
|
This function spins the event loop until a goal condition is met.
|
|
The less we do in WindowObject, the easier it will be to eventually
auto-generate the entire thing.
|
|
At a later point this will indicate whether some FunctionObject "has a
[[Construct]] internal method" (separate from the current FunctionObject
call() / construct()), to help with a more spec-compliant implementation
of [[Call]] and [[Construct]].
This means that it is no longer relevant to just NativeFunction.
|
|
|
|
ECMAScriptFunctionObject::environment() can just be non-virtual.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also add the internal slot names as comments, and separate them into
groups of spec and non-spec members.
This will make it easier to compare the implementation code with the
spec, as well as identify internal slots currently missing or only
present on FunctionObject.
|
|
The old name is the result of the perhaps somewhat confusingly named
abstract operation OrdinaryFunctionCreate(), which creates an "ordinary
object" (https://tc39.es/ecma262/#ordinary-object) in contrast to an
"exotic object" (https://tc39.es/ecma262/#exotic-object).
However, the term "Ordinary Function" is not used anywhere in the spec,
instead the created object is referred to as an "ECMAScript Function
Object" (https://tc39.es/ecma262/#sec-ecmascript-function-objects), so
let's call it that.
The "ordinary" vs. "exotic" distinction is important because there are
also "Built-in Function Objects", which can be either implemented as
ordinary ECMAScript function objects, or as exotic objects (our
NativeFunction).
More work needs to be done to move a lot of infrastructure to
ECMAScriptFunctionObject in order to make FunctionObject nothing more
than an interface for objects that implement [[Call]] and optionally
[[Construct]].
|
|
Some sites don't have favicon.ico, so we may get 404 response.
In such cases, ResourceLoader still calls success_callback.
For favicon loading, we are not checking response headers or payload
size.
This will ultimately fail in Gfx::ImageDecoder::try_create().
So avoid unnecessary work by returning early, if data is empty.
|
|
|