Missing dark mode

[jiab77 (Doctor Who)]

Hi @luani,

I was going to suggest the same but you already did it Nice work btw!

When I’ve compared what was done other RRD graph images and the one from WIO that could not be patched as the others, I was surprised to see the use of the iframe tag to display the images as they are just images, the most big deal is to update them regularly and that’s all

[jiab77 (Doctor Who)]

Hi @bonnietwin,

Woow that’s an awesome news! I can make a note in the project README on my side saying that the support for some add-on is currently limited and remove it when you’ve released your work.

What do you think?

Let me know if I can help aside of introducing myself to the dev team like helping you for testing my patch or anything else.

[jiab77 (Doctor Who)]

Hi @luani,

You’ve been very fast! Is there anything I can do for helping or testing from my side?

In case you would like to test changes in my code, you can do the following:

1. Make a backup of the currently installed darkmode.js file
2. Make a backup of the modified functions.pl file
3. In the modified functions.pl file:
   1. Duplicate the injected <script> line located before </body> and comment it
   2. In the duplicated line, just keep the src attribute and remove all others

You should get something like that:

[root@[REDACTED] include]# pwd
/srv/web/ipfire/html/themes/ipfire/include
[root@[REDACTED] include]# diff -y --suppress-common-lines functions.pl functions.pl.dev 
	<script src="/include/darkmode.js" integrity="sha512- |		<!-- <script src="/include/darkmode.js" integrity="sh
							      >		<script src="/include/darkmode.js"></script>
[root@[REDACTED] include]#

Once you’ve finished your tests or if you want to get the latest version, simply revert your changes or restore the backup copies and that’s all

I’m planning to add support for --no-sri in the install script along with a reset feature that will revert all the changes made by the install script.

I’ll keep you all updated when done.

[tphz (iptom)]

@jiab77

2. Czy łatka działa również pod Edge? (Wersja oparta na chromie, nie starsza)

Basic dark mode install/update/remove script for IPFire - v0.4.0
Gathering installed patch version... 0.4.0
Gathering local patch installer version... 0.4.0
Fetching latest version... done
Gathering fetched versions... nothing to update

Microsoft Edge
Version 109.0.1518.78 (Official compilation) (64-bit version)

---

After clicking "Start"

Best

[mumpitz]

@jiab77

Quite funny to see that the website you’ve mentioned is not protected against JS code injections (I just did a quick test with my “Dark Mode” bookmarklet)

They could have just implemented a basic CSP and it would have protected the website against JS code injections… So I find that funny to see many websites talking about security and privacy measures to follow but fails to follow them on their side…

Thanks for the tip, I have written a mail in which I informed the operator about it, he will certainly be grateful.

@jiab77

But if you prefer to debug things by yourself, no problem with that, just check the following:

• The SRI hash is stored in the SH file that install the JS file
• You must have the same SRI hash in the SH file and the line injected in functions.pl
  • You can see the injected line from your browser, on any WUI pages, check the source code and you’ll find it just before </body>

• If both SRI does not match, the JS file will not be loaded in the browser.

Without an update since my last massage the SRI Hash is the same.
I send you a pm with the requested information.
Sorry but I didn`t know how to set the language to English in the web console, even Firefox is set to English

Regards

[jiab77 (Doctor Who)]

Hi @tphz,

Thanks a lot again for your extensive testing and proof of work on MS Edge!

Regarding the last screenshots that have their backgrounds in white, I’ll explain you the reason why it does that:

I’ve deliberately injected the <script></script> line just before the </body> tag for these reasons:

1. When you place your scripts to the end of the page body, the browser will load them in lower priority
2. When you place your scripts in the <head></head> block, the browser will load them in high priority

What does it means exactly?

• Scripts placed in <head></head> will block the page rendering until the browser has downloaded everything, applied all the defined changes in scripts on DOM elements and then starts rendering the page
• In order to be able to let my code detecting the DOM elements that needs to have their style overridden, it needs to wait on the browser to have rendered all the DOM elements in each pages
• For doing so, my code needs to be downloaded in low priority which unfortunately creates a loading / rendering delay until my code is triggered and the dark theme applied on the page…

I’ve made this choice for performance reason to avoid the following:

• As my code needs to read the whole DOM to detect elements that needs to be styled differently, it will create the bad side effect to block the whole page rendering during the time the browser is downloading all the page resources to build the DOM and let my code doing it’s job…
• As it would be quite annoying for the users (I mean you guys ) I’ve preferred to let the browser manage the download priorities and avoid unnecessary page redraw.

If you read the page you’ve shared me earlier called “Our top Core Web Vitals recommendations for 2023”, it is very well explained but it remains highly technical.

In general it’s always better to load the Javascript code from the </body> part instead of the <head></head> part to avoid blocking the page rendering but it has some disadvantages as you could see

[jiab77 (Doctor Who)]

Hi @mumpitz,

Thanks for the tip, I have written a mail in which I informed the operator about it, he will certainly be grateful.

No problem, I’m glad if I could help to secure things better To be honest, detecting if a CSP is in place on a website is purely a side effect of my little “dark mode” bookmarklet

Without an update since my last massage the SRI Hash is the same.

I’ve updated the project README to remove this image and replaced it by the current SRI hash.

I’ll check your PM right now.

[sec-con]

You could perhaps use preload tag to load relevant scripts before rendering the page. The downside is that the page will take a few milliseconds longer to load waiting for the scripts.

[jiab77 (Doctor Who)]

Yeah I thought about the the preload attribute and also defer + async but I’ve preferred to get a working code first and not do premature optimization. I think now I can try to add them but I’d like to finish the support of all WUI pages first then handle the tables content before doing such optimizations.

Hope you don’t mind but thanks again for your suggestion.

[awphuch (Brian Compton)]

Brilliant! Thank you!!!

[jiab77 (Doctor Who)]

Hi @awphuch, I’m glad you liked my work! Thanks a lot for your appreciation!

[jiab77 (Doctor Who)]

Hi guys!

Sorry for my silence, I’m currently facing several unexpected issues that does not allow me to focus on this project as much as I want.

Yesterday, I’ve released the version 0.5.0 that includes the following changes:

• Improved code isolation
• Reduced flashing side effect when the white background got switched in dark
• Added missing visual fixes (but might have changed things incorrectly so it will be fixed again in the next release)
• Added --no-sri install / update option in patch.sh

@sec-con, I’ve moved the load of the JS file from the <body> to the <head> block and used the async and defer flags to make it loaded after all other JS files. This allows to the browser enough time to render and parse existing DOM elements to allow my code to detect and alter their styles.

I’ll try to use the preload flag but I’m pretty sure it will load the JS file before the others and create the bug I’ve observed that if the browser has not rendered / parsed all the DOM elements, my code is not able to inject the theme selector to the right of the traffic monitor because I’m using it’s current position to place it.

One last thing, regarding the --no-sri option added to the patch.sh script, you should not use it! It’s only useful for testing or debugging purposes and nothing else. The SRI feature has been put in place to ensure that the JS code is not tampered prior arriving to your browser, so even if normally we all running our IPFire boxes in a safe place, I don’t recommend to use that --no-sri option unless as said, for testing or debugging purposes only.

Thanks again to all of you for your support and appreciation of my work, it means a lot to me.

[sec-con]

Thanks. Will check it out ASAP.

Don’t worry about time, in community efforts we all do what we can when we can. RL takes precedence.

[sec-con]

Werd. It is acting very randomly. Something is not right.
I do not get the switch icon nor can I change between dark/light mode.

I tried cleaning out the old by update -r and then deleting the ipfire-dark-theme directory, getting afresh download and installing it. Did not help. Tried in Edge as well. No diff.

The only way I see the dark theme now is if i go somewhere else and then click the browser Back button.

Can someone else confirm this?

[roberto (Roberto Peña)]

Hi @sec-con.

I´ve problems with last update (0.5.0):

The selector button does not appear. Latest version of Firefox.

line 45:

line 643:

BR

[sec-con]

Thanks. i never went in to the code to check, but good call. It might help solving it.

[jiab77 (Doctor Who)]

Hi all,

Can you please run ./patch.sh -u from the project folder to get the latest installer version? You should have 0.5.2 as installer version.

It should solve rendering issue created with the version 0.5.0.

I’m sorry about that, I’ve forgot to change 2 hardcoded lines in the installer script that was incompatible with the script now placed in <head>…

Please let me know if you still have issues with the new installer script.

[jiab77 (Doctor Who)]

Hi @roberto,

This is what I wanted to avoid and was a bit worried about the move to <head> instead of <body>…

Can you please try to get the latest version by running ./patch.sh -u from the project folder? I’m hoping it will solve your issue.

The new installer version is 0.5.2

My best guess is that Firefox ran the quirk mode due to the bug introduced in version 0.5.0 and so loads the script before the others.

If you go the network tab and check the loading priority, the file darkmode.js should be loaded in low or normal priority:

Chromium

Firefox

[jiab77 (Doctor Who)]

Hi @sec-con,

Normally it’s due to the quirk mode that browsers uses in case of broken HTML code that unfortunately the installer script introduced in the version 0.5.0…

It should be resolved with the new installer script version 0.5.2.

[jiab77 (Doctor Who)]

Hi again @sec-con,

As said it was due to a big introduced in the installer script version 0.5.0 that should be resolved with the version 0.5.2.

If not, then the move to <head> was a bad idea and I’ll revert to <body> or try to introduce a loading delay if you all prefer it in <head>.

Sorry again for the introduced bug