Enabling Dark Reader kills the example output about bob HOT 13 CLOSED

This also happens on Yari, BTW.

from bob.

Please do some co-work to solve this issue pray (cc @Gusted)

mdn/sprints#3742

Also the error that got logged for me:
![](
Seems to be some error that the wrong child is being removed. However this is triggered by Dark Reader somehow, but the code is on MDN side which execute and thrown a error.

Regards,
Gusted

from bob.

Debugger says it's happening inside a shadow root, but I'm not sure how Dark Reader can affect shadow tree? Oh I see it does insert some style elements inside shadow tree.

I tried installing Dark Reader on Edge and this doesn't happen there, so this is currently Firefox specific.

from bob.

Okay, so there is a repo named mdn/bob where the relevant code is:

Still not sure what's causing this though.

from bob.

Dark Reader somehow gets access to <shadow-output> element earlier than the renderer does (on Firefox but not on Edge/Blink), and thus hits the condition that otherwise wouldn't.

Without Dark Reader it does not get anything:

@Gusted What could be a reason when Dark Reader opens an empty shadow root and insert styles there?

from bob.

https://github.com/mdn/bob is used in the same way more or less in Kuma and in Yari.
So shall we move this issue to that repo? Or is it very much a bug in the Dark Reader extension?

from bob.

Let's move to that repo 👍

from bob.

@Gusted What could be a reason when Dark Reader opens an empty shadow root and insert styles there?

It's basic practice for Dark Reader to insert those 2 styles. The first one is to make overriding inline styles work. The second one is the override that's provided by dynamic-theme-fixes.config for the correct site.

https://github.com/darkreader/darkreader/blob/master/src/inject/dynamic-theme/index.ts#L130 This function add those styles into it.

EDIT:

Or is it very much a bug in the Dark Reader extension?

No it doesn't seems to be... the code that causes this error doesn't expect Dark Reader styles to be there... and therefore handles it as it's own? which causes issues.

from bob.

Opened up a PR to fix this problem #539.
As it simply wants to remove an undefined or null in some cases a simple check should prevent this.

Same error when you try to remove an non-object.

from bob.

It's basic practice for Dark Reader to insert those 2 styles. The first one is to make overriding inline styles work. The second one is the override that's provided by dynamic-theme-fixes.config for the correct site.

Could it be done in a lazy way? It doesn't seem right to insert styles when the root is empty.

from bob.

Could it be done in a lazy way?

It's static so it doesn't have any checks in place, only the dynamic styles are being placed when needed.

It doesn't seem right to insert styles when the root is empty.

It insert the styles after Dark Reader detects that an new root is opened as this should be filled with elements later and waiting on the shadowroot to wait for elements coming in doesn't seems to be a good practice in my eyes.

from bob.

only the dynamic styles are being placed when needed.

That's good, but why can't the static ones be lazily inserted only when that happens?

from bob.

That's good, but why can't the static ones be lazily inserted only when that happens?

Not really.... Because this style override is for fixes. Because the shadow root doesn't necessary have dynamic style it can have a style that's being fixed by the override but doesn't have dynamic styles and therefore won't get actually fixed.

from bob.