unusual url schemes don't work (e.g. about:config?filter=...)

[hg42]

you seem to process the url and reconstruct it.

• protocols can be anything
  • about:config?filter=...
  • mailto:user@server
  • added later like snap: or magnet: (see https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers)
• / after server, this seems to be inserted, but it often doesn't work with it
  • about:config/?filter= doesn't
  • mailto:user@server/ uses "user@server/" as address

What is the purpose/benefit to parse and reconstruct the url? I think it can be done, but it has to follow the standard. All examples are perfectly standard compliant.

[ssborbis]

What action are you performing that is failing?

[hg42]

i wanted to search settings found in a web page in about:config and I found out, that I have to attach ?filter=, so I thought, let's add it to CS as a search engine:

about:config?filter={searchTerms}

but it didn't work. I cannot save it, because it is marked in red as "Template must be an URL". However it is a valid url. The protocol might be unusual, but while about: is a standard in firefox, a new protocol can also be added to firefox, so this should work with every kind of protocol. I don't know how you check this, but I wouldn't be restrictive but let firefox decide. Additionally I noticed that in some cases a "/" is added automatically, which is wrong for several protocols, for example about: and mailto:

The other schemes are theory. But I know there are a lot of protocols apart from the usual http, https, ftp, etc.

[ssborbis]

Looks like i'm just regex testing for ^http there. I'll do what I've done elsewhere and put the string in a new URL() inside a try / catch for validation

[ssborbis]

Just tried testing your about:config idea, but unfortunately it's not going to work. Here's the doc for the url param when creating a new tab in webextensions

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/create

url string. The URL to navigate the tab to initially. Defaults to the New Tab Page. Fully-qualified URLs must include a scheme (i.e. 'http://www.google.com', not 'www.google.com'). For security reasons, in Firefox, this may not be a privileged URL. So passing any of the following URLs will fail: chrome: URLs javascript: URLs data: URLs file: URLs (i.e., files on the filesystem. However, to use a file packaged inside the extension, see below) privileged about: URLs (for example, about:config, about:addons, about:debugging). Non-privileged URLs (e.g., about:blank) are allowed. The New Tab page (about:newtab) can be opened if no value for URL is provided.

[hg42]

I think it's a sign that CS has grown to be more useful and universal over time.

That said, I wonder which is the difference between a search engine and a bookmarklet? Is it only the javascript: protocol? In firefox bookmarklets are simple bookmarks and I think the difference between a bookmark and a search engine is only the additional parameters? Is it possible to unify all these?

[hg42]

sh... it's security by restricting everything instead of thinking. as far as I know I cannot change a setting via about:config, I can only search for it. The same for addons etc.

That said...how do you execute bookmarklets?

[ssborbis]

That said...how do you execute bookmarklets?

Bookmarklet scripts are injected into the current tab using browser.tabs.executeScript. I just checked, and it doesn't look like it works on protected urls like about:config making that a dead end.

[hg42]

I get the feeling that we need a fork of firefox or chromium for power users.

Unfortunately there are already some of those...but they are not getting attention, because everyone focuses on the main browsers, because of the wider user base. Because of this I had another thought: May be it's possible to create (and maintain) a patch for such browsers that removes access restrictions for the gui or makes it controllable in some way. But I guess this would be a binary patch, because security might be buried in native code.

I would not want to allow each and every extension to do such things. But I would be happy to grant access to CS and some other trustworthy extensions. Trust is a psychological thing. Without trust it all becomes very sad.

I can't really accept, that people that must be protected against themselves are effectively controlling my online tools and my daily work.

[hg42]

I can create a bookmark about:config?filter=security.pki.distrust_ca_policy, but a script isn't allowed to do that.

As a bookmark I can even create a javascript: url that restarts the browser. EDIT: my restart bookmark no longer works...but it did some versions before, another bookmarklet that fails

[ssborbis]

There's a thread somewhere on the moz dev site regarding opening up privileged urls to webextensions by requesting the permission in the manifest. I saw it a day or 2 ago when looking into the about:config access issue so it might be possible in the future.

[hg42]

Since they switched to web extensions, they got so many user requests about all these regressions. So I don't have much hope that they will listen this time... we will see... The about:config etc. search isn't really important. So let's wait. However, it would be nice if you don't put your own restrictions on the urls. Then it will automatically work when access becomes granted (other than a manifest solution). I see a lot of people trying to find ways around the restrictions, you will never know who might come up with some brilliant idea.

[ssborbis]

I just pushed those protocol changes (1.9.6b). I only tested using an ftp protocol in the template/path fields but it worked as expected. It should accept anything new URL() does. I didn't check into the trailing / yet.

[hg42]

nice...

I tried to make a bookmarklet for about:config, but this fails the same way like directly as a search engine (access denied from script). ftp worked, javascript:console.log("{searchTerms}") didn't (expected, but with a kind of unspecified error). A test like snap:{searchTerms} at least invokes the dialog for selecting a handler for this protocol, so I assume it would work. Though I still get an error "Template must be an URL" on such urls.

It seems like the icon field is restricted in a similar way. E.g. I tried to use a gtk stock icon like this: moz-icon://stock/gtk-find which works as a url in the browser but "Icon failed to load" in CS. But about:logo works, which seems to indicate that there is no restriction?

There are quite a lot of possibilities with these moz-icon urls, see: https://dxr.mozilla.org/mozilla-central/search?find=%2Fbrowser%2Fthemes%2Flinux%2F&q=moz-icon So, this could be useful.

Also, when leaving the form path field empty, I get "null" instead and the icon is "null/favicon.ico".

At some point I got a "G" as a green icon. I am not sure, how. Do you create such letter icons or is it from some url I am not aware of?

[hg42]

this also works in icon field: chrome://branding/content/icon32.png

[ssborbis]

I tried to make a bookmarklet for about:config, but this fails the same way like directly as a search engine (access denied from script).

Basically nothing works on about:config or other restricted URLs. I made a bookmarklet that says javascript:alert("test") and placed it on my bookmarks toolbar. Browser to any non-restricted page and click it, it works as expected. No go for restricted pages.

javascript:console.log("{searchTerms}") didn't (expected, but with a kind of unspecified error).

I don't replace {searchTerms} or other params within bookmarklets, although I probably should. There's a possibility of conflict, but it's pretty small.

It seems like the icon field is restricted in a similar way. E.g. I tried to use a gtk stock icon like this: moz-icon://stock/gtk-find

I know resource:// is restricted. moz-icon:// is probably the same. Icons are validated by checking onload(), onerror() so anything that can be loaded as an image within the background page should work.

Also, when leaving the form path field empty, I get "null" instead and the icon is "null/favicon.ico"

I'll see about fixing this, but instead of null/favicon.ico it's going to be protocol://favicon.ico. I've been filling in the icon url by getting the URL.origin of the template URL. It will get sloppy with nonstandard protocols, but it shouldn't throw an error.

At some point I got a "G" as a green icon. I am not sure, how. Do you create such letter icons or is it from some url I am not aware of?

My fallback for failed icons is to create a 16x16 canvas, green background, white lettering and use the first letter of the search engine name to create a somewhat unique icon vs the default magnifying glass.

[hg42]

Basically nothing works on about:config or other restricted URLs

you are right, for some of my tests I forgot that I was on a restricted page (though not about:...) I would use about:config searches from pages telling me I should set this or that...usually not from restricted pages (though, CS options page would be such a case).

I tested

javascript:console.log("{searchTerms}")

either on the browser console or as a search engine.

anything that can be loaded as an image within the background page should work

from what I read moz-icon can be used in web pages. At least I can enter it in the address bar.

null/favicon.ico

I think in such cases there should be a default icon, or something generated from the engine name, first letter or first of each word or similar

My fallback for failed icons is to create a 16x16 canvas, green background

ah, I see, then you already have what I said above. But then it doesn't seem to work for icons that cannot be loaded (like CS tells me)

[ssborbis]

you are right, for some of my tests I forgot that I was on a restricted page (though not about:...) I would use about:config searches from pages telling me I should set this or that...usually not from restricted pages (though, CS options page would be such a case).

Yep, can't even link to about:config from an anchor a href= or I would have put links in options

I tested javascript:console.log("{searchTerms}")

I haven't changed bookmarklets to replace {searchTerms} yet.

from what I read moz-icon can be used in web pages. At least I can enter it in the address bar.

I tested with this moz-icon://.pdf?size=128 Loads fine in the URL bar but it wouldn't embed as an image in HTML.

null/favicon.ico

I've made a few changes not pushed yet. For one, I renamed the Cancel to Close. It never really cancelled anything. Pressing Save shows errors, prevents the form from closing, but it always saves the changes. I'll rework the autofill for the default icon / monogram icon a bit.

[hg42]

yepp, moz-icon is blocked by: "Security Error: Content at https://s.codepen.io/[...] may not load or link to moz-icon://stock/gtk-find?size=menu." I hoped it would be allowed for extensions. But this shouldn't work for injections.

Btw. editing an entry by double clicking on it, expands the "dialog" below the entry but doesn't scroll, so usually you dont't see that something happened.

I am also a bit confused that editing a bookmarklet only gives me an icon. I guess it uses the bookmark where it is defined? I didn't think it's handled like this, but it makes sense now, that it's a different thing. If it is this way I think it doesn't make much sense to replace {searchTerms} in a bookmarklet, because as a pure bookmark it wouldn't work?

[hg42]

I'll rework the autofill for the default icon / monogram icon a bit

how? the monogram icon is fine... I think the detection of icons that fail to load is incomplete in some way.

can I force the use of this monogram icon? for some search engines it would be a better icon that the favicon. An empty icon field is also replaced by null/favicon.ico.

[ssborbis]

how? the monogram icon is fine... I think the detection of icons that fail to load is incomplete in some way.

can I force the use of this monogram icon? for some search engines it would be a better icon that the favicon. An empty icon field is also replaced by null/favicon.ico.

I've made a few revisions so this might not be exactly what you're seeing, but the icon field being autofilled as null/favicon.ico should still display a monogram icon in the manager to the left of the name, and if you close the edit form and reopen, you should see the URI field filled in with a data:// uri for the monogram icon. The reason I don't fill in the form with the data:// uri on an icon loading error is I don't want to just erase whatever the user put into the field on the chance there was a typo or something that could easily fixed. However, if you leave the edit form or reload Options the field should show the monogram URI. There is a fallback to using the magnifying glass icon, but even looking at the code I'm not exactly sure what chain of events gets you there. There's no way to 'force' the monogram icon per se, but you really shouldn't have to. Leaving the icon field blank should get you there even with an error message.

[ssborbis]

@hg42

I forgot to mention I added the variable CS_searchTerms to be used with bookmarklets. For instance, I added a bookmarklet for highlighting from the quick menu using this as the bookmark url

Because I'm using browser.tabs.executeScript() to run the bookmarlet code, it has some access to context script methods.

javascript:if (CS_searchTerms) document.dispatchEvent(new CustomEvent("CS_mark", {detail: CS_searchTerms}));

[hg42]

please help me :-) I don't have a clue, how you do this...

How do you add a bookmarklet to the quickmenu? am I missing something? the only way I can think of, is to add it as a search engine, but then CS complains about missing {searchTerms}. So I guess you meant the context menu? (which is the only place I see bookmarklets)

But even from the context menu I don't see any effect on the page... I guess CS_searchTerms uses the terms in the findbar? or does it use the terms in the search box on the various menus? I tried both...

I guess it's only a test, or otherwise how is this particular bookmarklet useful?

[ssborbis]

Add bookmarklets as new bookmark first, then change the url to a javascript script. Next, go into the CS search engines manager and bring up the custom context menu with a right-click, choose Add Bookmarklet, then pick the bookmark you just created from the list. CS scans all bookmarks for /^javascript:/ and populates the list. I could add an entry for "new bookmarklet" so users could start a new bookmark(let) through the CS options but since most bookmarklets are added as bookmarks first, it seemed unnecessary.

[hg42]

yeah, "the right click menu" was the necessary hint, thanks.

I tend to forget that there are actions not related to the object on which it is invoked. I think it's mainly because the "Add" button below the search engines list has a very similar purpose, so I am only looking there. I am also searching for "New Folder" from time to time. Is there a difference between "Add" button and "New Engine" in the menu?

[hg42]

ok, I see what it does...that's useful, thanks.

I still wonder what's the difference between a search engine entry and a bookmarklet or any other bookmark if it could be entered.

I guess you are stripping the javascript: prefix and executing it?

What if some url would be entered in the search engine list (for now ignoring the term "search engine") and it would not contain {searchTerms} and this would be allowed. Wouldn't it invoked the same way like the search Engine? or do I miss something? And if a bookmark could be created this way, you could also enter a javascript url. In this case, on invocation, you would strip the javascript: and execute it like you probably do with the bookmarklet. Ok I see, something like the form path isn't necessary in this case (but it seems to be unused for some search engines, too?).

[ssborbis]

Was going through some old open threads and saw I missed this.

I guess you are stripping the javascript: prefix and executing it?

Yep.

What if some url would be entered in the search engine list (for now ignoring the term "search engine") and it would not contain {searchTerms} and this would be allowed. Wouldn't it invoked the same way like the search Engine? or do I miss something? And if a bookmark could be created this way, you could also enter a javascript url. In this case, on invocation, you would strip the javascript: and execute it like you probably do with the bookmarklet.

Are you wanting to enter scripts directly into CS? Or use CS as a bookmarks speed dial?

[hg42]

seems I also missed your answer :-)

At first I was trying to understand the difference between a bookmarklet and a search engine.

Then, knowing that bookmarklets can also do search engines, I had the idea that both are very similar and there might be a single concept allowing both, eventually simplifying code and usage. I guess a search engine would only be a specific kind of bookmarklet pattern.

CS has become my favorite interface for "actions" on marked text and sometimes I thought I could also do other things with it. Like invoking bookmarks I use very often, or a script etc. Unfortunately it only works when text is marked. It's partly because I can use folders, it's simply more organized. Also, I like the multiple ways to invoke CS actions and the convenient and configurable interface.

Creating a bookmarklet directly in CS might be more convenient.

My brain is trained to look for active actions in CS. So bookmarklets would naturally live in CS alone.

I always tend to forget how to add a bookmarklet, perhaps you could add your description above to the help page?: "Add bookmarklets as new bookmark first, then change the url to a javascript script. Next, go into the CS search engines manager and bring up the custom context menu with a right-click, choose Add Bookmarklet, then pick the bookmark you just created from the list. CS scans all bookmarks for /^javascript:/ and populates the list".

[ssborbis]

I guess a search engine would only be a specific kind of bookmarklet pattern.

GET engines would be pretty simple; just change the URL and include {searchTerms} or whatever. I think some other add-ons use that method, actually.

Creating a bookmarklet directly in CS might be more convenient.

When I first added that functionality, it was requested by a user that had existing bookmarklets. There are also websites out there, albeit a bit antiquated now, that host various bookmarklets for some lighter scripting that didn't require a full add-on. So, adding scripts via bookmarklet seemed like the right choice at the time. Additionally, if a user altered a bookmarklet, the changes would show in CS, but not vice-versa and it seemed cleaner than having 2 copies. I've considered changing things a bit though, or adding an option to enter scripts directly, but with tools like greasemonkey, it felt a bit redundant. It would be nice to have some way to include greasemonkey scripts into the tiled menus.

[hg42]

yes, it's all a bit redundant. I guess, most extensions could be implemented as user scripts. In fact I often switch back and forth between similar script and extensions if one becomes better than the other. E.g. youtube enhancements etc. I also have my own special user scripts, that try to restyle some annoyances, I have with my special usage of pages. I also have some firefox gui enhancements via a few user styles (via some tricky userchrome.xml/css/js).

From my point of view, CS has by far the best menu interface available. So, basically I would want to have access to anything from CS menus :-)

I just tried some things with bookmarklets and I think, defining them in the bookmarks and use them from CS is ok. I agree with your reasoning. May be, it could be a little bit easier to add them to the menu. In my case I already have them organized in folders. So for me, it would be ideal to add one or more bookmarklet folders and CS would do the rest (e.g. a dynamic sub menu following the bookmarklet folder structure including sub folders).

If a bookmarklet uses special CS features (variables etc.), it may not work as a normal bookmarklet. But it should be possible to account for this in the bookmarklet script.

[ssborbis]

I could add an "Import Bookmarklets" button and stuff them all in a Bookmarklets folder I suppose. Probably won't help established users who've already imported by hand, but it's something.

[hg42]

Hmm, I didn't mean a special (single) folder named "Bookmarklets". Instead I was thinking of (multiple) folders in the CS menu which are each paired with a bookmark folder containing bookmarklets (and sub folders).

For example I have a bookmarklets folder called "webdev" with actions for web development (e.g. search engines, style changes, topology styles etc.). I wanted to replicate this folder in the quickmenu.

But, when thinking a bit further, I would finally need mixed folders, that include search engines, bookmarks and bookmarklets for each topic.

Currently I have three places:

• search engines in CS
• bookmarklets in a bookmarklets folder (because there are a lot of them)
• bookmarks in some other folders

I generally have two kinds of bookmarks:

• a lot of normal ones to remember pages
• a kind of tools related to several topics, that are organized in appropriate folders

So it seems, my real goal is to move all the topic related actions (currently bookmarks and bookmarklets) to CS.

So, the missing features seem to be:

• adding normal bookmarks to CS
• invoking CS menus without a selection
• may be a simpler/quicker method to import bookmarks (including bookmarklets), may be drag and drop? (single bookmarks, bookmark folders...)

well, it's just a bunch of dreams...

[ssborbis]

The trouble with importing bookmarks into CS is losing the updates to the actual bookmarks. I wonder if having a "live" folder in the CS search engines manager named "Bookmarks" would work. Instead of being imported into CS, it could be a real-time reflection of the user's bookmarks, following the same hierarchy and changes without the ability to modify within CS. Just throw'em all in there or maybe add them on a folder by folder basis.

[hg42]

from my experience, duplication of "items" always leads to problems. Either it must be a clear master slave relation or there has to be a version control like algorithm with time of change and ancestry tracking for each item. Especially with sync of bookmarks and extensions.

Your idea of a live folder is certainly one way to solve this.

Actually, I don't want to have access to all my 10000 bookmarks in CS. This would probably slow down CS a lot and it's generally not necessary.

I could imagine a few smaller live bookmark folders, though.

I am not sure about the organization in folders. I usually gather items into folders based on topics. E.g. I have folders for image processing, 3D-printing, photography, web development, programming languages, ... Live folders would not allow to intermix bookmarks with search engines etc.

My focus is more on adding single items at the right position in the menu hierarchy than adding many of them easily. Actually, I wouldn't import all of my bookmarklets into CS, only those I need regularly.

So, I think the current bookmarklet implementation fits my needs for now and I should play with it for some time.

[ssborbis]

I have a working dnd for Firefox bookmarks set up. Currently, I can drag individual bookmarks from my bookmarks toolbar into the CS Sidebar menu and launch them using the same Search Action as any other tile. Looks promising.

[hg42]

that's interesting... Currently, I am not loading from the repo but using the official extension. may be I should switch debugging mode?

[ssborbis]

nothing in the repo yet. working out some kinks. I'll let you know when I make a push

[hg42]

jupp, that's what I had in mind ;^)

EDIT: I'm loading from the repo now...ready to test

[ssborbis]

Push made.

Things to know:

EXPORT YOUR SETTINGS before trying, just to be safe. Everything seems ok, but adding a new type to the node tree can cause havoc.

No bookmark handling in context menu or search engines manager. In fact, opening Options will remove bookmarks from the menus.

(edit) Bookmark folders will be ignored

(edit) Favicons are fetched from google using bookmark url's hostname ( no API to get directly )

(edit) titles won't show for added bookmarks until menu reload

QM is receiving all sidebar functions. The merger between QM and sidebar / toolbar search may cause issues.

[hg42]

nice...

some notes:

• normal bookmarks seem to work without a selection
• the bookmarklets I tested (e.g. zap colors or topografic view) only work with selected text
• if I use "zap colors" on https://github.com/ssborbis/ContextSearch-web-ext/issues/147 (this page), only the drag handle of the sidebar turns to black (hmm currently it's white) and dragging the sidebar renders the whole page black until I release the button. On whatsapp both are rendered white. I guess, as the sidebar is injected into the page it's not possible to protect it against such page style changes?

zap colors

javascript:(function(){var%20newSS,%20styles='*%20{%20background:%20white%20!%20important;%20color:%20black%20!important%20}%20:link,%20:link%20*%20{%20color:%20#0000EE%20!important%20}%20:visited,%20:visited%20*%20{%20color:%20#551A8B%20!important%20}';%20if(document.createStyleSheet)%20{%20document.createStyleSheet(%22javascript:'%22+styles+%22'%22);%20}%20else%20{%20newSS=document.createElement('link');%20newSS.rel='stylesheet';%20newSS.href='data:text/css,'+escape(styles);%20document.getElementsByTagName(%22head%22)[0].appendChild(newSS);%20}%20})();

[ssborbis]

FYI, the latest pushes can handle the bookmarks type in the search engines manager, so you can open options and move / copy / delete without losing bookmarks. No editing yet, and they are a copy of the relevant bookmark info, not a live version, so edits to bookmarks will not propagate to CS. I might add a "refresh" icon or something.

the bookmarklets I tested (e.g. zap colors or topografic view) only work with selected text

I haven't tested dragging bookmarklets, but given the code, they'll be added as type=bookmark vs type=bookmarklet. I'd like to merge the 2 types, but for the time being, they will be treated similarly, but not identically.

I guess, as the sidebar is injected into the page it's not possible to protect it against such page style changes?

It usually comes down to the page's CSS and it's specificity. I've seen some sites use some very global CSS selectors + !important declarations that are all but impossible to override, and the CS iframe menus suffer styling bugs as a result. I'll check that particular bookmarklet. How did you add it to CS? DnD or as a bookmarklet through the manager?

[hg42]

my tests were done with the first version two days ago. However, I had no time to comment after the test. Will do another test with the current version today.

[ssborbis]

zap colors is causing an all-white page because to capture the mouse move over iframes when dragging, an empty div is placed over the entire page. zap colors is turning overlaid div opaque. (edit) adding an opacity rule to the div seems to have fixed the issue.

Failed bookmarklets when no text was selected is fixed on my local branch.

[hg42]

that's interesting... while normal bookmarks work without a selection, bookmarklets added by dnd only work when text is selected. So I first thought, they cannot be type=bookmark. BUT... if I add the same bookmarklet (zap colors) via the context menu in the manager, it is added with a bookmarklet icon (the dnd version gets a loupe icon). This one works also without a selection.

So, I guess there must be some code in the bookmark (execution?) handler, that reacts on the "javascript:" or similar.

How did you add it to CS? DnD or as a bookmarklet through the manager?

both...and both work the same (apart from the selection thing)

I copied the "zap colors" bookmarklet years ago from somewhere... it is clear that it is very general, as it turns all backgrounds to white and all texts to black or blue

this is the CSS:

* { background: white ! important; color: black !important }
:link, :link * { color: #0000EE !important }
:visited, :visited * { color: #551A8B !important }

perhaps CS doesn't use !important on some styles? the star shouldn't be too specific :-)

Also interesting that it once turned to black backgrounds. The code above clearly says "white". Currently I don't get black anymore, it's always white.

I added the same bookmarklet with background yellow and foreground gray, which changes everything to those colors when using the bookmarklet. So, I think, it never should have been black...

[hg42]

btw. I first disabled my own styles in the settings...

[ssborbis]

both issues should be fixed in the push going up now

(edit) and don't worry about the discrepancy between type=bookmark & type=bookmarklet. I'll merge them and sort the bugs out then.

[hg42]

dragging the sidebar works, nice

the drag handle still becomes white and I also found that the button for a closed sidebar becomes empty. probably these are background images and replaced by "background: ..." ?

but it's only a minor issue in special cases

--- mom ---

adding !important to every background line in inject_sidebar.css fixes this. Probably it's not necessary to add it to every background line for this special case. However, if taking this further, each line would need an !important... and the user styles would probably need this, too. Isn't there a way to say !important for the whole style definition? or may be add it programmatically.

[hg42]

Isn't there a way to say !important for the whole style definition?

at least not in CSS, also the !important in the bookmarklet can only be overridden by an !important and a higher specificity

[ssborbis]

Yep, using user styles to catch all the rules the script overrides will cause more problems. You're best bet may be modifying the bookmarklet to skip CS_ rules

[ssborbis]

javascript:(function(){var newSS, styles='*:not(.CS_handle) { background: white ! important; color: black !important } :link, :link * { color: #0000EE !important } :visited, :visited * { color: #551A8B !important }'; if(document.createStyleSheet) { document.createStyleSheet("javascript:'"+styles+"'"); } else { newSS=document.createElement('link'); newSS.rel='stylesheet'; newSS.href='data:text/css,'+escape(styles); document.getElementsByTagName("head")[0].appendChild(newSS); } })();

[hg42]

or may be the injection could add !important before each ;

I think there are much more cases, where CS could be broken by page styles and bookmarklets etc. The only way to protect CS against !important would be to also use !important. Or may be adding the styles directly to the ui elements (set style="...").