Add global option in settings for Filter HTML source #33

Closed
opened 1 year ago by bed · 9 comments
bed commented 1 year ago

This option is turned off because of language encoding issues but can there be an option in the settings to turn this on globally?

I found most of the websites I visit worked well with this feature on. It is tedious to manually enable it for each needed website and a global setting to turn it on with the ability to add whitelist for specific problem websites would be very useful.

Also unrelated but I noticed all my settings were reset by the new update. Is that a bug?

This option is turned off because of language encoding issues but can there be an option in the settings to turn this on globally? I found most of the websites I visit worked well with this feature on. It is tedious to manually enable it for each needed website and a global setting to turn it on with the ability to add whitelist for specific problem websites would be very useful. Also unrelated but I noticed all my settings were reset by the new update. Is that a bug?
Owner

I thought about this for a while at the beginning (it was permanently activated for a while), but after so many people reported problems (the majority via e-mail), I decided to use the current version. Even today I still get e-mails from people who didn't see the second switch, didn't find the link behind or didn't understand the function.

Unfortunately it is very difficult to find a solution that everyone is satisfied with.

The biggest problem, if thit is standard: user input. For the user everything looks normal, but if the web server expects the user input in the background (e.g. database) in a certain charset, but then gets it in UTF-8, some things might break in the background. UTF-8 is standard, but almost exclusively for new developments. There are still so many applications that haven't been converted yet because there is no time and money for that. Reason: It works.

Also unrelated but I noticed all my settings were reset by the new update. Is that a bug?

Oh, yes, that should not happen. LocalCDN now uses the sync storage instead of the local storage. If you use "Firefox Sync" or your own sync server (better than Firefox Sync 😉 ), the settings will be transferred to all your devices. This was also an improvement suggestion from a user. I made a mistake during implementation and forgot to check for existing settings and copy them if necessary. Sorry about that.

I thought about this for a while at the beginning (it was permanently activated for a while), but after so many people reported problems (the majority via e-mail), I decided to use the current version. Even today I still get e-mails from people who didn't see the second switch, didn't find the link behind or didn't understand the function. Unfortunately it is very difficult to find a solution that everyone is satisfied with. The biggest problem, if thit is standard: user input. For the user everything looks normal, but if the web server expects the user input in the background (e.g. database) in a certain charset, but then gets it in UTF-8, some things might break in the background. UTF-8 is standard, but almost exclusively for new developments. There are still so many applications that haven't been converted yet because there is no time and money for that. Reason: It works. > Also unrelated but I noticed all my settings were reset by the new update. Is that a bug? Oh, yes, that should not happen. LocalCDN now uses the [sync storage](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/sync) instead of the [local storage](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage/local). If you use "Firefox Sync" or your own sync server (better than Firefox Sync :wink: ), the settings will be transferred to all your devices. This was also an improvement suggestion from a user. I made a mistake during implementation and forgot to check for existing settings and copy them if necessary. Sorry about that.
nobody added the
enhancement
bug
labels 1 year ago
bed commented 1 year ago
Poster

I think the best way would be to turn the Filter HTML feature off by default but to have an option in settings so users can turn it on globally with the ability to whitelist if they need to turn it off for specific websites.

This seems like the best compromise for advanced users who would like this feature turned on everywhere and can deal with broken websites by whitelisting them from the feature and also will have no complaints of broken websites from casual users.

I think the best way would be to turn the Filter HTML feature off by default but to have an option in settings so users can turn it on globally with the ability to whitelist if they need to turn it off for specific websites. This seems like the best compromise for advanced users who would like this feature turned on everywhere and can deal with broken websites by whitelisting them from the feature and also will have no complaints of broken websites from casual users.
Owner

Let's have a look at the use cases for LocalCDN:

  1. websites without frameworks
  2. websites with frameworks and a strict SOP/CORS
  3. websites with frameworks, without SOP/CORS/attributes*
  4. websites with frameworks, with attributes*

*) crossorigin and/or integrity attributes

What can LocalCDN do:

  1. Nothing
  2. Nothing
  3. Replace
  4. Filter and replace

It makes a difference if LocalCDN only blocks/redirects web requests or if LocalCDN reads the whole HTML source code line by line, edits and writes it back into the browser tab. I can add the option, that's not a problem, but I don't think it makes sense to filter the HTML source code in all cases all the time, while there is only one valid situation. If the feature would exist, I wouldn't use it.

It's not important how many webpages are working with the filter, because it's very different from user to user. For example I'm using only two websites that require this filter.

Let's have a look at the use cases for LocalCDN: 1. websites without frameworks 2. websites with frameworks and a strict SOP/CORS 3. websites with frameworks, without SOP/CORS/attributes* 4. websites with frameworks, with attributes* *) crossorigin and/or integrity attributes What can LocalCDN do: 1. Nothing 2. Nothing 3. Replace 4. Filter and replace It makes a difference if LocalCDN only blocks/redirects web requests or if LocalCDN reads the whole HTML source code line by line, edits and writes it back into the browser tab. I can add the option, that's not a problem, but I don't think it makes sense to filter the HTML source code in all cases all the time, while there is only one valid situation. If the feature would exist, I wouldn't use it. It's not important how many webpages are working with the filter, because it's very different from user to user. For example I'm using only two websites that require this filter.

Current situation is bad too. The option is disabled everywhere by default and the user doesn't know if it would make sense to enable it on this website. You would need to try it out on every website.

Is there any possebility to detect your 4th variant and make it suggest to try to filter it or display some tooltip over the icon if there's something the plugin could block?

Current situation is bad too. The option is disabled everywhere by default and the user doesn't know if it would make sense to enable it on this website. You would need to try it out on every website. Is there any possebility to detect your 4th variant and make it suggest to try to filter it or display some tooltip over the icon if there's something the plugin could block?
Owner

Yes, this is typical for web development 😉

UTF-8 is a good example: The Unicode standard was first defined in 1992 (28 years ago!), but is still not used by everyone. There are new websites that use a different encoding and there are popular websites that use the old crap. I think it will take another 20-30 years before we can say goodbye to all the old crap.

Is there any possebility to detect your 4th variant

Without reading the HTML source code? No, because an addon can modify web requests, but cannot determine whether a redirection will be fail. See Add CORS information to webRequest details objects (Bugzilla)

As I said before, maybe one day I will implement this option to negate the filter list. But I will not activate this option in my Firefox profiles, because it is complete nonsense to push all websites through the filter. It isn't necessary for every website (see cases 1,2 and 3) and normally you have to split the fourth case:

4a) Websites without user input

4b) Websites with user input and UTF-8 charset

4c) Websites with user input and non-UTF-8 charset

Considering these cases, the filter will only work in cases 4a and 4b. The user input could cause errors or the database* would contain corrupted data if a database* behind cannot handle a different charset. This can happen because the frontend uses e.g. ISO-8859-1 and nobody expects this.

*) database or any other service behind

If it's possible to exclude local resources from SOP/CORS it would be solve cases 2 and 4. Everything else is just a workaround.


This is comparable to a light switch: I only press the switch when it is dark in a room and I need the light. I do not press the switch when there is enough daylight in the room or when I just walk past the room.

Yes, this is typical for web development :wink: UTF-8 is a good example: The Unicode standard was first defined in 1992 (28 years ago!), but is still not used by everyone. There are new websites that use a different encoding and there are popular websites that use the old crap. I think it will take another 20-30 years before we can say goodbye to all the old crap. > Is there any possebility to detect your 4th variant Without reading the HTML source code? No, because an addon can modify web requests, but cannot determine whether a redirection will be fail. See [Add CORS information to webRequest details objects (Bugzilla)](https://bugzilla.mozilla.org/show_bug.cgi?id=1419459) As I said before, maybe one day I will implement this option to negate the filter list. But I will not activate this option in my Firefox profiles, because it is complete nonsense to push all websites through the filter. It isn't necessary for every website (see cases 1,2 and 3) and normally you have to split the fourth case: 4a) Websites without user input 4b) Websites with user input and UTF-8 charset 4c) Websites with user input and non-UTF-8 charset Considering these cases, the filter will only work in cases 4a and 4b. The user input could cause errors or the database* would contain corrupted data if a database* behind cannot handle a different charset. This can happen because the frontend uses e.g. ISO-8859-1 and nobody expects this. *) database or any other service behind If it's possible to exclude local resources from SOP/CORS it would be solve cases 2 and 4. Everything else is just a workaround. ----- This is comparable to a light switch: I only press the switch when it is dark in a room and I need the light. I do not press the switch when there is enough daylight in the room or when I just walk past the room.
Owner

Implemented

Maybe I'll do a beta first, so you can test it. Interested?

:white_check_mark: Implemented Maybe I'll do a beta first, so you can test it. Interested?

Sure. Maybe you also have some websites known for testing this festure.

Sure. Maybe you also have some websites known for testing this festure.
Owner

Sorry about the delay.

  • download the develop branch first. You will find a download icon on the right side
  • Unzip the archive somewhere
  • deactivate LocalCDN in your Firefox
  • type "about:debugging" into the address bar and click on "This Firefox"
  • click on the button "Load temporary add-on..." and navigate to the unzipped archive
  • select the file "manifest.json"
  • Done 😉
Sorry about the delay. * download the develop branch first. You will find a download icon on the right side * Unzip the archive somewhere * deactivate LocalCDN in your Firefox * type "about:debugging" into the address bar and click on "This Firefox" * click on the button "Load temporary add-on..." and navigate to the unzipped archive * select the file "manifest.json" * Done :wink:
Owner

Implemented in v2.2.10

Implemented in [v2.2.10](https://codeberg.org/nobody/LocalCDN/src/tag/v2.2.10)
nobody closed this issue 1 year ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.