The previous name was extremely misleading, because the call is used for
pushing or replacing new session history entry on chrome side instead of
only changing URL.
It is going to be used to communicate whether it is possible to navigate
back or forward after session history stored on browser side will no
longer be used to driver navigation.
Instead of treating reloading as a regular navigation by using
load_url(), now we invoke a navigable reloading algorithm implemented
from the spec.
Now both reloading triggered from UI and location.reload() will use the
same code path.
This change adds the `captureEvents()` and `releaseEvents()` methods to
the window object. These methods are obsolete, but are still included
in the HTML specification, which says they must do nothing.
This change adds the `clear()`, `captureEvents()` and `releaseEvents()`
methods to the document object. These methods are obsolete, but are
still included in the HTML specification, which says they must do
nothing.
parse_index_data() wants to take ReadonlyByte views of the stream
data, so we need FixedMemoryStream::read_in_place(size_t). All
other remaining code indirectly calls parse_index_data(), so that
all operates on FixedMemoryStreams too.
No behavior change.
PaintFrame is not primitive painting command, we inherited from OS, that
is hard to replicate in GPU-painter or alternative CPU-painter API. We
should remove it as a part of refactoring towards simplifying recording
painter commands set.
Fixes: #23796
See spec issue https://github.com/whatwg/html/issues/9869
Previous attempt on fixing reload had to be reverted because it broke
Soundcloud and GitHub, but this change does not seem to introduce new
crashes.
There was no need to set an available height constraint when doing early
height calculation for inline-flex boxes. It created a situation where
the flex containers could wrongly get zero height early, and then
resolve percentages against zero instead of the real intrinsic size.
Fixes#23942
It does fetching and uses parseFromString() DOMParser API in the fetch
callback. Following steps end up hanging before reverting
664611bae4:
1. Do fetching initiated by fetch() js call.
2. Invoke fetch callback on networking task source
3. Fetch callback does parseFromString()
4. parseFromString() invokes HTMLParser
5. HTMLLinkElement inserted into new document initiates fetching
6. Fetching callback cannot run because networking source was blocked on
step 2.
7. HTMLParser::the_end() spins waiting for HTMLLinkElement to unblock
load event, which will never happen because fetching callback cannot
proceed.
This reverts commit 664611bae4.
It seems like the HTML spec has been misinterpreted and this text:
"... Note that in this setup, the processing model still enforces that
the user agent would never process events from any one task source out
of order."
does not mean we can't interrupt execution of task by a task with the
same task source. It just says they should be processed in the order
they were added.
Fixes hanging while navigating from PR list to PR page on GitHub.
When both insets in a given axis are auto, we should use the static
position for absolutely positioned elements.
By doing this correctly, we exposed a bunch of other small bugs which
had to be fixed to compensate for new test failures. Those fixes are
included here as well:
- Don't apply margins twice.
- Compute the static position containing block chain correctly.
This makes https://brave.com/ look much better. :^)
Rather than each element which supports dimension attributes needing to
implement parsing the attributes and setting the appropriate style, we
can generalize this functionality. This will also make each element more
closely resemble the spec text, as we will be effectively declaring, for
example, "The img element supports dimension attributes" in code.
Before this change JS console was initialise from
activate_history_entry() which is too late for about:blank documents
that are ready to run scripts immediately after creation.
"apply the history step" initiated by reloading or back/forward
navigation might require doing fetching while populating a document,
so it is not possible to restrict spin_until() to process only
NavigationAndTraversal task source.
"apply the history step" initiated by synchronous navigation keeps
processing only NavigationAndTraversal task source because it will
never have to populate a document. Another reason to keep synchronous
navigation blocking other task sources is that we crash if active SHE
changes in the middle of "apply the history step" initiated by sync
navigation. The new test is added to makes sure we don't regress that.
Previously, using `wasm-decompile` to decompile the Wasm bytecode on
the `wasm.html` example page gave this output:
```
export function fib(a:int):int {
if (a < 2) { return 1 }
return fib(a - 2) + fib(a - 1);
}
```
With this change the bytecode now decompiles to:
```
export function fib(a:int):int {
if (a <= 0) { return 0 }
if (a == 1) { return 1 }
return fib(a - 2) + fib(a - 1);
}
```
This means that the example page now prints the correct answer of 55 to
the console for `fib(10)`. Previously, `fib(10)` returned 89.
I also used `wasm-opt -Oz`, which removed an unnecessary `return`
instruction, saving 1 byte!
For text, we always ended up with a leading \0 byte (on little-endian),
which prints as nothing. Since that's the only thing we do with this
data, no actual behavior change.
From HTML spec https://html.spec.whatwg.org/#definitions-3
"... Note that in this setup, the processing model still enforces that
the user agent would never process events from any one task source out
of order."
I can't come up with an example that is fixed by this change. However,
debugging a bug caused by violating this assumption from the spec is
likely to be very painful.
...callback, otherwise Networking task source will be blocked until the
end of HTML parsing.
This is a preparation before forbidding to interleave HTML tasks with
the same source.
On macOS, it's not trivial to get a Mach task port for your children.
This implementation registers the chrome process as a well-known
service with launchd based on its pid, and lets each child process
send over a reference to its mach_task_self() back to the chrome.
We'll need this Mach task port right to get process statistics.
