Open zieren opened 3 years ago
There are two design options:
a) Provide tabs to AHK client. Pro: Browser extension remains simple. Maybe AHK could open a socket for the extension to talk to (https://www.autohotkey.com/boards/viewtopic.php?t=35120). Con: Introduces complexity to the AHK client (a library and an asynchronous component). AHK has no direct way of closing browser tabs and would have to either close the whole browser or communicate back to the extension, which is again async and yet more complexity.
b) Extension talks to the server itself. This is possible because the server allows parallel operations (same timestamp is OK) and does not need activity to be reported in chronological order. Pro: Extension can close tabs directly. Con: Need to duplicate logic already in AHK, like request protocol, showing messages etc.
The downsides for a) are significant, while those for b) seem manageable, so b) seems better.
Note: IIRC FF browser tabs are visible to AHK when hidden window detection is enabled.
That last comment is not true, but tabs can still be queried: https://stackoverflow.com/questions/23028005/autohotkey-able-to-capture-firefox-tab
This would address the case where there is audio playback from a background tab. It should be feasible, but the question is whether tracking audio playback is an important enough use case to outweigh the effort and added client complexity.