Fix LNA issues when using local audio - #2448
Conversation
Kuuuube
left a comment
There was a problem hiding this comment.
I'm quite suspicious that theres a large amount of code duplication in this PR. I'll look at it more later. But just from a brief look here's some comments.
There was a problem hiding this comment.
Cleaned up/rearranged some parts that went heavily against Yomitan's architecture and deduplicated some.
Would've liked this to use blob object urls to eliminate the need for the whole WebAudioLocalAudio class but it looks like that isn't possible due to Firefox's content security policy (Chrome does allow it). Could've been a much cleaner solution but oh well...
Thank you for the contribution!
|
Just in case someone notices this PR and thinks it's broken because the CI doesn't pass, there seems to be an unrelated problem with reporting, and all tests seem to pass(?). |
Fixes #2310
Mimics the setup for
TextToSpeechAudiowhen it encounters local target urls for the audio server. It offloads the fetching of the audio data to the background, which causes it to be recognized by the extension and allowed through. Only applies to local URLs, global URLs are still going through the flow as before.By doing this it can circumvent the constant, very annoying LNA prompts. (see example below)
Note: to replicate this issue, go to
about:configand setnetwork.lna.blockingto true.