1763420 - Sidebar images linked in css are not always rendered

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[Andreas Wagner [:TheOne] [use NI]]

Sometimes, after starting Firefox, images in extension sidebars are not rendered.

I experienced this with Tree Style Tab where the "close tab" and "new tab" icons are sometimes just invisible. Several things do not help, like closing/reopening the sidebar, disabling/re-enabling the extension, restarting Firefox.

What seems to help is executing the snippet from https://bugzilla.mozilla.org/show_bug.cgi?id=1746841#c10 (and closing and reopening the sidebar), which could indicate it is related to caching or preloading images in linked css.

I investigated this with Luca, who has a better understanding of the issue and could likely add some more information here.

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

Andreas and I did an initial investigation of the issue as happening locally on Andreas machine over zoom and we did notice that:

• the icon image was initially not rendered in the Tree Style Tab sidebar
• while inspecting it from a DevTools toolbox attached to the extensions and inspected the DOM element where the image was meant to be rendered:
  • the image url is a relative url (relative to the current page, and the current page is nested in a subdirectory of the extension package)
  • disabling and re-enabling the rule from the DevTools panel seems to able to fix the issue (at least for that sidebar, but it was happening again after closing and reopening the sidebar)

If I'm not mistaken disabling and re-enabling the rule from the DevTools toolbox panel will force the related CSS to be refreshed (e.g. parsed and applied to the page again).

Based on the observed behaviors, my current theory is that the issue may be triggered because:

• the url of the image in the CSS is relative to the extension page location that is importing the CSS
• the extension page is not in the root of the packages extension, but in a subdirectory
• the first time the CSS is loaded and interpreted while the extension page is loading, it is possible it is being interpreted as relative to the root URI of the extension (maybe as a side-effect of the CSS being preloaded)
• when we have toggled the rule in the DevTools toolbox panel, we forced the CSS to be re-applied and in this case the image url may have been interpreted as relative to the extension page as it should

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

As a next step, I plan to create a reduced test case based on the theory described above to confirm if that allow us to recreate the conditions that is triggering the bug (and then dig into it to gather more details about which are the components involved into triggering the issue and determine approaches to fix the issue).

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

The issues has been also investigated on the TreeStyleTab github issue here: https://github.com/piroor/treestyletab/issues/3142 and then workarounded on their side with the workaround from this small patch:

• https://github.com/piroor/treestyletab/commit/b01fa48703fd7d75ab4d16022c87ffbadd6c4eed

The workaround is basically going through all stylesheets in the extension page, then for every rule with a rule.style.maskImage property:

• it stores the values set on rule.style.background and rule.style.maskImage
• if there was a background set then it sets the background to 'none', and it sets the maskImage to an empty string
• then after a short delay it sets back the original background and maskImage previously stored

Hi Emilio,
I was wondering if the fact that issue seems to be related to rule.style.maskImage and that they workarounded with the approach described right above may ring any bell for you and could help to gather some more ideas about what we may dig into to investigate this further on our side (e.g. a MOZ_LOG we may try to set to collect some additional logs if we manage to reproduce it again, or a theory about what may be going on that may help us to figure out what we could try to put together a reduced test case that would reproduce this issue consistently enough).

Comment 4

[Emilio Cobos Álvarez (:emilio)]

mask-image is the only CSS property that does CORS-enabled fetches... That's the only thing that is special about it I suspect.

Is there any reliable way to reproduce this? If so happy to poke a bit. I'd try to check if there's any CORS error in the console or so.

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

mask-image is the only CSS property that does CORS-enabled fetches... That's the only thing that is special about it I suspect.

Is there any reliable way to reproduce this? If so happy to poke a bit. I'd try to check if there's any CORS error in the console or so.

I was able to trigger it only with TreeStyleTab and I was not able to trigger it consistently enough to record it with rr.

I also tried to reduce it to a more minimal test extension, even one that would be triggering (apparently) intermittently like with TreeStyleTab, but I was not yet able to trigger it.

But at the time I have not noticed yet that it was triggered by using mask-image and so I'm going to give it another try, and I'll let you know if I manage to get an STR (and possibly a minimal test extensions) that we can use to dig into it more.

In the meantime thanks a lot for the quick reply and additional pointers, that is already very much appreciated!

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Pyro,
is there any chance that you may have any additional detail from your investigation for https://github.com/piroor/treestyletab/issues/3142 that may help us to get to a STR to reproduce it consistently enough and/or to get to a reduced test case?

Comment 7

[YUKI "Piro" Hiroshi]

Hmm, it is hard for me to reproduce the problem on my environment also - it happens very intermittently. On my case, there may be some points increasing possibility to reproduce:

• Many tabs are opened, over 50.
• Reloaded via about:debugging (I'm dogfooding TST via about:debugging). When I reload TST again and again, the problem sometimes happen.

Unsetting and setting mask-image workaround aims to simulate the DOM inspector workarounds. Unsetting of background-color is just to reduce visual problem when mask-image become blank.

But while investigation I saw that hidden icons suddenly become visible when I just deactivate and re-activate background-color for the CSS declaration section containing mask-image. In other words, re-setting mask-image was unnecessary on the case. Does this information help deep debugging?