Fixed replacement of data.

[KOLANICH]

Replacement was not working because of a bug in Firefox staying for more than 9 years. Also noticed a flaw in design - we cannot replace binary files since assumme they are text ones. But it is shouldn't be fixed in this PR.

[KOLANICH]

@kylepaulsen, I know that the extension is in maintaince mode, but this PR urgently needs your attention, since the extension is broken in Firefox.

[kylepaulsen]

I appreciate the dedication but I'm a little confused. I'm testing in firefox right now and am able to redirect using a URL -> FILE rule. Is there a specific situation where this doesn't work? Steps to reproduce the bug would be appreciated.

Also, I only ever intended the extension's file editor to help with replacing text files - not binary files. You should still be able to override binary files with a URL -> URL rule though.

[KOLANICH]

Is there a specific situation where this doesn't work? Steps to reproduce the bug would be appreciated.

1. Sign up to zoom.us.
2. Create a video conference.
3. Don't install the client, use the browser. The link to a client implemented in JS + HTML appears after some delay after you have clicked the big button.
4. Open devtools on network page, find the JS matching the template https://*.zoom.us/web_client/*/js/webclient.min.js, download its source, deminify it, then override it using ResourceOverride.
5. reload the page, with the network tab open. The loading of the URI with the resource overriden will error. It is because of a bug in Firefox, it is disallowed to use data URIs for that. It may be because of its size, since that file is pretty large (for built-in deminifier in debugger tab, it eats all the ram on machine and a swap, and then firefox just crashes).

Also using base64 is a very inefficient and ideologically incorrect way to deal with this stuff. Base64 has large overhead in size and also overhead for serialization and deserialization. The way implemented in this PR is more efficient.

[kylepaulsen]

This must be a memory issue. I was able to inject an unminified webclient.min.js file just fine in zoom's web client. There was a slight gotcha that I had to also remove the "Content-Security-Policy" header from the response using a Header rule because they block inline scripts. Maybe you did this too? I dunno.

I don't disagree that using base64 is inefficient. Did you test your changes in Chrome? I'm assuming not because it looks like chrome doesn't support filterResponseData. Additionally, chrome doesn't define the "browser" global, although this could be patched in the code somewhere very high up.

If you can find a solution that doesn't break chrome, maybe we can at least make Firefox better and merge something.

[KOLANICH]

This must be a memory issue.

I don't think so, the file is not so large. It is some inefficient logic within firefox devtools unminifier amplifies its size a lot. I suspected that it hit some hardcoded limit on URI size, but since it works for you, it is not the case.

I had to also remove the "Content-Security-Policy" header from the response using a Header rule because they block inline scripts. Maybe you did this too?

I didn't. I use some addons that rely kn csp to do content blocking. It is not good at all (and can even be considered a backdoor), but they currently do this way.

Did you test your changes in Chrome?

No. BTW, Chrome gets rid of blocking WebRequest. Got rid of it in 88. Brave though keeps it.

Additionally, chrome doesn't define the "browser" global

I guess I can make per-engine dispatching. For Chromium one function will be called, for Firefox another one.

[KOLANICH]

@kylepaulsen

[kylepaulsen]

This was merged in https://github.com/kylepaulsen/ResourceOverride/pull/44

[KOLANICH]

Thank you.