Adds a pretty simplistic Notification WebAPI. Also adds a dummy drawImage to
CanvasRenderingContext2D.
Trying to improve how we're seen by https://bot.sannysoft.com/
I noticed that `fetch www.openmymind.net` worked but, `fetch www.example.com`
didn't. www.openmymind.net redirects to `https://www.openmymind.net/` so
in `frameHeaderDoneCallback` we get the updated response.url(). www.example.com
doesn't redirect, so self.url remains `www.example.com` which just doesn't work
at various parts of the code (Location.init, RobotsLayer...).
Added a quick check in Navigate, if the URL isn't a "complete" URL, stick
"http://" infront. There are probably cases where this is wrong, e.g.
'javascript:...' but these don't work anyways.
(Curl works with www.example.com of course).
I'm not sure how this is happening, but we occasionally see an attempt to
execute a null v8::Function (from crash reports). It seems pretty clear that
this is a Global that is being reset, but I can't figure out a path where
a global is reset while a callback is still active. So, in != .Debug mode, we
null check functions before executing and return an error.
This potentially will work without causing any new/different issues. If this is
a global being reset, than we must be in some teardown state, and it probably
doesn't matter if a JS callback is or isn't executed.
In case anyone ends up here and wonders about the guard, here's a stack from
a crash dump:
```
Fatal V8 Error
---
location: v8::Function::Call
message: Function to be called is a null pointer
???:?:?: 0x2ac0b59 in ??? (???)
???:?:?: 0x2ace19b in ??? (???)
/src/browser/js/Function.zig:160:41: 0x268db23 in callWithThis__anon_236231 (lightpanda)
/src/browser/EventManagerBase.zig:259:30: 0x2614b53 in dispatchDirect__anon_179346 (lightpanda)
/src/browser/EventManager.zig:137:33: 0x261737e in stateChanged (lightpanda)
/src/browser/webapi/net/XMLHttpRequest.zig:580:30: 0x2621b21 in handleError (lightpanda)
/src/browser/webapi/net/XMLHttpRequest.zig:542:21: 0x2628bbd in httpErrorCallback (lightpanda)
/src/network/layer/Forward.zig:70:13: 0x29193de in errorCallback (lightpanda)
/src/browser/HttpClient.zig:1447:36: 0x2784aa6 in processMessage (lightpanda)
/src/cdp/CDP.zig:314:24: 0x26a3244 in dispatchParsed (lightpanda)
/src/cdp/CDP.zig:187:31: 0x252df34 in drainInbox (lightpanda)
/src/browser/HttpClient.zig:416:24: 0x27f01ab in handleConnection (lightpanda)
/home/runner/work/_temp/91356985-8cc1-40de-b1b8-395a29b4bd91/zig-x86_64-linux-0.15.2/lib/std/Thread.zig:509:13: 0x26877f3 in entryFn (lightpanda)
???:?:?: 0x7df4279d11f4 in ??? (libc.so.6)
Unwind information for `libc.so.6:0x7df4279d11f4` was not available, trace may be incomplete
```
Three changes:
- js.Execution now has a page (instead of calling exec.context.page)
- js.Execution now has a session (instead of calling exec.context.page.session)
- js.Execution.context renamed to .js to be consistent with Frame and WGS
Navigator properties moved from data properties to real accessors. This impact
how they're seen (and potentially treated) by JS code.
These change result in https://www.browserscan.net/bot-detection correctly
rendering. When paired with https://github.com/lightpanda-io/browser/pull/2561
we now render that page correctly (still detected as a bot, but we no longer
fail to render)
window.console (and many others) should be settable. This is the [Replaceable]
WebIDL attribute.
This improves loading of https://www.browserscan.net/bot-detection which would
immediately break/fail because we would throw on window.console setting.
This appears to come from obfuscator.io's disableConsoleOutput flag, so the
issue might be relatively common.
We currently skip capturing 401 and 407 bodies. This appears to be an
optimization with the intent that it won't be needed. While that might be true
in some cases (though, not sure when), it isn't always true. A page.navigate
to a 401 should display the content.
(Also, tried to silence meaningless BrokenPipe noise in tests).
Normally, a shadow dom is attached to an element via `el.attachShadow(mode)`.
With DSD, the shadow dom is attached during parsing. Essentially, when we see:
<template shadowrootmode="open">...</template>
it has the end result of calling attachShadow on the parent element. This is
used increasingly by a number of frameworks, though normally with backwards
compatibility that fallbacks to doing it in JavaScript.
DSD happens during parsing and document.write, but not via innerHTML = ''.
However, both Element and DocumentFragment gain a `setHTMLUnsafe` which is like
innerHTML WITH DSD.
I initially thought this feature could be implement exactly like I describe:
when the parser adds a template, check for a `shadowrootmode` attribute and
call attachShadow...except..you need to call attachShadow on the parent, which
the parser hasn't popped yet, and it alters where the children are added.
Thankfully, html5ever has a boolean to enable/disable dsd..hence the html5ever
binding changes to (a) enable / disable this featuer and (b) the new callback.
https://github.com/lightpanda-io/browser/pull/2548 removed the _need_ to call
v8::Isolate::MemoryPressureNotification on Session.deinit and actually removed
the call.
But [my theory] is that this causes our peak memory to be higher. So, I'm
adding it back.
The point of #2548 was to open the door for improving the memory signals to v8
by removing the _need_ for this specific signal. That PR made it so that, for
correctness (UAF) we no longer _had_ to call it. The point of the PR wasn't
to necessarily improve the signals, so I don't feel too bad about putting this
back in.
When nodeIsReady is called from a dynamic (JS) insertion, execute any code
on the node's frame, not the frame that did the insertion.
The code is a bit uglier than it has to be, because getting the node's frame
isn't free, and we only execute code for a few types (scripts, links, ...) so
we only get the owning frame when we're sure it's needed (thus the duplication)
The markdown renderer currently ignores shadow-dom. It doesn't "pierce" it, so
it'll render the light-dom (which is the template / fallback), which won't be
right.
This largely mimics the existing logic in dump.
This doesn't solve anything, but I was looking at /input-events/ WPT tests and
many are stuck with due to this type not existing. I don't expect this to fix
any of those tests, but it does move them along a bit further (the /input-events
test are all based on editing capabilities that we don't have).
We already had a // todo StaticRange in AbstractRange, and since it's very
simple, why not.
AFAIK, these aren't being used and I've personally not have reason to reference
/ look at them for months.
I have no issues though if we want to keep them in.
