ankit
commented
4 years ago Thanks for reporting @egcohen. This one is non-trivial to fix since the stylebot UI is still injected into the same DOM (into a shadow DOM, which does reduce conflict and that's why some other styles don't affect it). I will poke around a bit to see if I can get around the display: none issue.
Some styles for the current page also get applied to the style editor itself, and it is easy to accidentally add a style that makes the style editor unusable. It's also pretty hard to recover from this, because without a usable style editor it's hard to change the offending style!
For instance, adding the style
div {display: none}to the current page causes all divs, including the style editor itself, to disappear. You can't locally disable the stylesheet while the editor is open, so as far as I can tell the only way to undo this is to go to the Stylebot options page and directly edit the offending stylesheet.It looks to me like the options page is not affected by Stylebot styles, so at least it should always be possible to recover (even if the bad stylesheet is applied to all pages). But I don't have the guts to test this to make sure.
Now that I'm exploring this more,
display:noneis actually the only style that I have found that seems to get applied to the style editor, so maybe I'm misinterpreting the issue.While it may seem as though anyone including a style like this is just asking for trouble, I managed to do it unintentionally: I was adding another
div.classselector to a pre-existing group which happened to have styledisplay: none, but as soon as I typeddivthe style was applied and everything disappeared! (In a related complaint, I no longer see a way to turn off real-time application of styles as you type, which would have avoided this particular instance of the main bug, since I never intended to apply the intermediate style at all.)