Flickering padlock on non-local PDF files and DNSSEC websites #2

Seb35 commented 2024年05月06日 21:08:29 +02:00

On non-local PDF files (i.e. not "file://...") like this one for instance, when you move the page (scroll down/up, etc.) the padlock is flickering: removed then a few milliseconds after it reappears. However the padlock icon is correct (DNSSEC on DNSSEC sites, non-DNSSEC on non-DNSSEC sites).

It may be linked to #1. If it is not, some mechanism should be created to avoid this flickering, perhaps keep in some variable the icon state and do nothing if it is the same.

On non-local PDF files (i.e. not "file://...") like [this one for instance](https://www.laquadrature.net/wp-content/uploads/vsa/VSA-brochure-planche.pdf), when you move the page (scroll down/up, etc.) the padlock is flickering: removed then a few milliseconds after it reappears. However the padlock icon is correct (DNSSEC on DNSSEC sites, non-DNSSEC on non-DNSSEC sites). It may be linked to #1. If it is not, some mechanism should be created to avoid this flickering, perhaps keep in some variable the icon state and do nothing if it is the same.

Seb35 commented 2025年10月12日 20:13:05 +02:00

Contrary to my initial statement, the flickering padlock occurs also on DNSSEC websites (e.g. https://www.icann.org), although it is very quick.

The reason is that the function updatePageAction first hides the icon, then compute the new icon, then display the new icon, combined with the fact that this function is called multiple times in these cases:

• on PDF files because the event browser.tabs.onUpdated is called each time the user scroll/move/click on the PDF
• on DNSSEC websites because firstly the event browser.webRequest.onHeadersReceived is triggered and calls updatePageAction, and secondly the event browser.tabs.onUpdated is triggered and calls also updatePageAction.

I will probably modify to make browser.webRequest.onHeadersReceived the main event updating the icon (there are almost always HTTP headers, and all informations are present to detect if DNSSEC and/or DANE are enabled) and browser.tabs.onUpdated a secondary event updating the icon only if the other event did not (in the rare case where the server does not return an answer; only DNSSEC may be detected in this case). When the icon is set, next calls to updatePageAction will do nothing, avoiding the flickering.

I also don’t see a valid reason to update the icon once the initial loading is finished (only the main frame is validated against DNSSEC and DANE, not other resources).

Contrary to my initial statement, the flickering padlock occurs also on DNSSEC websites (e.g. https://www.icann.org), although it is very quick. The reason is that the function updatePageAction first hides the icon, then compute the new icon, then display the new icon, combined with the fact that this function is called multiple times in these cases: * on PDF files because the event `browser.tabs.onUpdated` is called each time the user scroll/move/click on the PDF * on DNSSEC websites because firstly the event `browser.webRequest.onHeadersReceived` is triggered and calls `updatePageAction`, and secondly the event `browser.tabs.onUpdated` is triggered and calls also `updatePageAction`. I will probably modify to make `browser.webRequest.onHeadersReceived` the main event updating the icon (there are almost always HTTP headers, and all informations are present to detect if DNSSEC and/or DANE are enabled) and `browser.tabs.onUpdated` a secondary event updating the icon only if the other event did not (in the rare case where the server does not return an answer; only DNSSEC may be detected in this case). When the icon is set, next calls to `updatePageAction` will do nothing, avoiding the flickering. I also don’t see a valid reason to update the icon once the initial loading is finished (only the main frame is validated against DNSSEC and DANE, not other resources).

Seb35 commented 2026年01月17日 19:17:45 +01:00

The issue also occurs in a more disturbing way on Wikipedia when displaying a redirected article (e.g. https://fr.wikipedia.org/wiki/LCEN ): the padlock is flickering either indefinitely (behaviour of version 0.2.3) either exactly 200 times before stopping (behaviour of 0.2.4, more exactly this is not visual but the event tabs.onUpdated is called this number of times (can be observed by putting a console.log just before the 2nd "return" in onTabUpdated, probably because it is very quick and some mechanism of Firefox is stopping this). In both cases, when you observe about:processes, the process "Extensions" is CPU-intensive.

This behaviour is probably a bug in Firefox, see:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1818392 browser.tabs.onUpdated unnecessary call many times
• https://bugzilla.mozilla.org/show_bug.cgi?id=1405603 changeInfo.url in browser.tabs.onUpdated present when url hasn't actually changed

I can confirm the second parameter of the callback changeInfo is always an object { url: "https://example.org/my-page" } (URL of the current page) and it is unchanged, although it is specified in the addListener to filter when then URL changes.

The issue also occurs in a more disturbing way on Wikipedia when displaying a redirected article (e.g. https://fr.wikipedia.org/wiki/LCEN ): the padlock is flickering either indefinitely (behaviour of version 0.2.3) either exactly 200 times before stopping (behaviour of 0.2.4, more exactly this is not visual but the event tabs.onUpdated is called this number of times (can be observed by putting a console.log just before the 2nd "return" in onTabUpdated, probably because it is very quick and some mechanism of Firefox is stopping this). In both cases, when you observe about:processes, the process "Extensions" is CPU-intensive. This behaviour is probably a bug in Firefox, see: * https://bugzilla.mozilla.org/show_bug.cgi?id=1818392 browser.tabs.onUpdated unnecessary call many times * https://bugzilla.mozilla.org/show_bug.cgi?id=1405603 changeInfo.url in browser.tabs.onUpdated present when url hasn't actually changed I can confirm the [second parameter of the callback `changeInfo`](https://codeberg.org/Seb35/DNSSEC-DANE_Padlock/src/tag/0.2.3/src/background.js#L149) is always an object `{ url: "https://example.org/my-page" }` (URL of the current page) and it is unchanged, although it is specified in the addListener to [filter when then URL changes](https://codeberg.org/Seb35/DNSSEC-DANE_Padlock/src/tag/0.2.3/src/background.js#L71).

Seb35 commented 2026年01月24日 14:30:49 +01:00

Fixed on 0.2.4.

(Although the underlying issue in Firefox makes wasting of CPU, particularly on redirected articles on Wikipedia.)

Fixed on 0.2.4. (Although the underlying issue in Firefox makes wasting of CPU, particularly on redirected articles on Wikipedia.)