PerformanceTiming::monotonic_timestamp_to_wall_time_milliseconds
assumes all DocumentLoadTimingInfo values are monotonic timestamps
and converts them via wall_time = timestamp - epoch. This is correct
for navigation_start_time (a true monotonic timestamp), but wrong
for all other timing fields like load_event_end_time, dom_complete_time
etc., which are stored as relative timestamps via
current_high_resolution_time() (relative to time origin).
The computed wall clock value ends up off by navigation_start_time,
causing convert_name_to_timestamp() to return wrapped-around u64
values. This broke performance.measure() when using navigation timing
attribute names as start/end marks.
Add relative_timestamp_to_wall_time_milliseconds which adds back
navigation_start_time before the epoch subtraction, producing correct
UTC epoch ms for these fields.
Previously, the LibWeb bindings generator would output multiple per
interface files like Prototype/Constructor/Namespace/GlobalMixin
depending on the contents of that IDL file.
This complicates the build system as it means that it does not know
what files will be generated without knowledge of the contents of that
IDL file.
Instead, for each IDL file only generate a single Bindings/<IDLFile>.h
and Bindings/<IDLFile>.cpp.
Before this change, we were going through the chain of base classes for
each IDL interface object and having them set the prototype to their
prototype.
Instead of doing that, reorder things so that we set the right prototype
immediately in Foo::initialize(), and then don't bother in all the base
class overrides.
This knocks off a ~1% profile item on Speedometer 3.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
