Currently, the feel of scrolling containers in the Inspector is a bit
awkward. We make the entire split-view container scrollable, then we
absolutely position the tab control buttons to force them to not scroll.
The result is that the scroll bar is painted over the tab controls, and
the tab content that we actually want to scroll has to scroll under the
tab controls. This never looked quite right.
It was basically:
<div tab-container> <!-- Scrollable -->
<div tab-controls /> <!-- Pinned to not be scrollable -->
<div tab-content /> <!-- The part we actually want to scroll -->
</div>
This patch moves the "scrollability" to just the tab content. We then
don't need to go out of our way to ensure only the content is actually
scrollable.
So we now have:
<div tab-container> <!-- Not scrollable -->
<div tab-controls /> <!-- Not pinned, uses normal layout -->
<div tab-content /> <!-- Scrollable -->
</div>
Previously, the legacy `-webkit-foo` properties would all be top of the
list, when they are generally not useful to inspect. Instead, put them
at the bottom, so that users can still see them if they want to, but
they're not in the way.
We currently display scroll bars for the JS console and its parent tab
container. We want the console output to be separately scrollable from
the tab content, but since both containers are scrollable, we end up
with nested scroll bars. This also makes actually scrolling feel pretty
awkward.
Prevent this by making the tab container non-scrollable when the JS
console is shown.
The previous character used, @, conflicted with CSS. % is used by other
templating engines, and doesn't conflict with language features (e.g.
media queries).
about:blank in most other browsers has a white background regardless of
dark mode. So rather than messing with that, remove the contents of the
NTP for now, and set a dark background-color in dark mode.
🤽 - U+1F93D PERSON PLAYING WATER POLO
🤽♂️ - U+1F93D U+200D U+2642 MAN PLAYING WATER POLO
🤽♀️ - U+1F93D U+200D U+2640 WOMAN PLAYING WATER POLO
🦨 - U+1F9A8 SKUNK
This partially supports the WebView::ChromeProcess mechanics. New
windows aren't totally supported and will just open a new tab for now.
When launched via the Browser's AppFile (either through quick launch or
the desktop shortcut), a new window will be requested.
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!
Currently the `<select>` dropdown IPC uses the option value attr to
find which option is selected. This won't work when options don't
have values or when multiple options have the same value. Also the
`SelectItem` contained so weird recursive structures that are
impossible to create with HTML. So I refactored `SelectItem` as a
variant, and gave the options a unique id. The id is send back to
`HTMLSelectElement` so it can find out exactly which option element
is selected.
JPEG2000 is the last image format used in PDF filters that we
don't have a loader for. Let's change that.
This adds all the scaffolding, but no actual implementation yet.
