| 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
|
|
|
|
SSL is unnecessary for our purposes, and including it causes a runtime
error when the path to `libcrypto.dylib` is different on the executing
machine than it is on the build machine.
This is the error I got when running `extreload` on an Apple Silicon
machine with Homebrew, using a package bundled by an x86 machine with
Homebrew:
$ extreload
debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {70024E0003}>:
Error opening shared object "/usr/local/opt/openssl/lib/libcrypto.dylib":
dlopen(/usr/local/opt/openssl/lib/libcrypto.dylib, 0x000A): tried: '/usr/local/opt/openssl/lib/libcrypto.dylib' (no such file).
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE ] Skip this shared object and continue.
1: [RETRY ] Retry loading this shared object.
2: [CHANGE-PATHNAME] Specify a different pathname to load the shared object from.
3: [ABORT ] Exit from the current thread.
(SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"/usr/local/opt/openssl/lib/libcrypto.dylib" :NAMESTRING "/usr/local/opt/openssl/lib/libcrypto.dylib" :HANDLE NIL :DONT-SAVE NIL))
0]
|
|
Copy the `pkg` target from Wajir to make a tarball of the bundled
dependencies in `bundle` and the Extreload source code.
This tarball can then be distributed and the program can be built and
installed from it using the Makefile. By distributing the source, an
executable can be built for more architectures and systems.
|
|
|
|
Sysexits is now in Quicklisp so we don't need to load it here.
|
|
Make it easy for package managers to build and install the program.
|
|
Add a target to create a self-contained bundle of the program that isn't
dependent on Quicklisp.
This code is based on what I did in Wajir.
|
|
With-user-abort is now in Quicklisp.
|
|
Sysexits is now in Quicklisp.
|
|
|
|
|
|
|
|
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.
|
|
|
|
For `<C-c>` handling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not using ECL any more. Instead we're continuing to build with SBCL and
enable binary compression.
|
|
|
|
|
|
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.
|
|
|
|
This code is superseded by the Common Lisp project that communicates via
the DevTools Protocol.
The `chrome.management` API's `setEnabled()` function just allowed me to
turn extensions off and on. It didn't reload the extensions.
The DevTools Protocol allows us to execute JavaScript in the context of
an extension's background page. This allows us to run
`chrome.runtime.reload()` in an extension's context, properly reloading
the extension.
|
|
|
|
|
|
I used these for debugging, but they aren't relevant any more.
|
|
Makes more sense to group the option code together.
|
|
|
|
|
|
Give this check a name.
|
|
|
|
|
|
|
|
Make the config containing command line options a global variable. This
makes it easy to find out if the `--debug` flag is on in the
`websocket-send` function.
Not sure about the global variable, but seems fine for now.
|
|
|
