| Age | Commit message (Collapse) | Author |
|---|
|
For some reason, it's not sending the tab reload after the re-attach.
Maybe a thing with the wait group?
|
|
Doesn't appear to be working, unfortunately. The idea was to force the
execution of the re-attach instead of checking for a targetCrashed
message (which I would get only very rarely). In this way, we ensure
that we re-attach to the service worker before running the tab reload.
But that doesn't seem to be enough.
|
|
I got this to work once, but not again after that for reloading the
current tab.
|
|
I observed during a manual test with Websocat that Manifest V3
extensions trigger an `Inspector.targetCrashed` message after reloading
the extension:
{"id":1,"sessionId":"21A6A75608971AEAD68DB36701F9985C","method":"Runtime.evaluate","params":{"expression":"chrome.runtime.reload()"}}
{"id":1,"result":{"result":{"type":"undefined"}},"sessionId":"21A6A75608971AEAD68DB36701F9985C"}
{"method":"Inspector.targetCrashed","params":{},"sessionId":"21A6A75608971AEAD68DB36701F9985C"}
Here, I tried to listen for that `Inspector.targetCrashed` message and
use that to trigger a tab reload.
Unfortunately, that doesn't seem to work, as in my Extreload test of
this code, I don't see the `Inspector.targetCrashed` message. Looks like
I'll have to find a different means of reloading Manifest V3 extension
tabs.
|
|
I want to keep track of Manifest V3 extensions, because these must be
re-attached to in order to reload the tab. We will later look at this
list to find out if we need to skip reloading the extension (it's
already been done), and instead proceed directly to reloading the tab.
|
|
I thought this might fix the reload problem for Manifest V3 extensions,
but it did nothing.
|
|
I looked into fixing the tab reload in Manifest V3, but haven't figured
out a way to get it working yet. Apparently according to the file stat,
I did this on 2023-02-13.
|
|
Begin Web Extension Manifest V3 support by recognising `service_worker`
targets in addition to `background_page`s.
|
|
|
|
Otherwise we get a runtime error when running the binary on a different
machine than the one that built it:
$ extreload -V
error: Failed to find the WRITE-DATE of
/private/tmp/extreload-20220825-3720-17mi6k3/extreload_0.0.2/bundle/local-projects/:
No such file or directory
|
|
Use the `with-user-abort` library to catch an interrupt signal from
`<C-c>` and exit immediately. Otherwise, the Lisp debugger is invoked,
which is not the expected behaviour for a command line program.
Tried putting the `user-abort` condition in the `handler-case` in
`main`, but it didn't appear to be caught in my tests. Decided to catch
it with `handler-case` immediately instead, confirming this works.
Unfortunately, if `<C-c>` is received before entering `main` (by running
the program and immediately pressing it), our handler won't get called,
and instead the Lisp debugger will be invoked. Not sure how to deal with
that, so I've decided not to bother.
|
|
|
|
This is the final project. Now that we got rid of the web extension and
native host code, we can move the Lisp code to the root.
|
