Opened on 11/16/2014 at 03:09:42 PM
Closed on 11/18/2014 at 12:42:30 PM
Last modified on 12/09/2014 at 02:04:13 PM
#1574 closed change (rejected)
Inject element hiding CSS wih chrome.tabs.insertCSS()
Reported by: | sebastian | Assignee: | |
---|---|---|---|
Priority: | P4 | Milestone: | |
Module: | Platform | Keywords: | externaldependency |
Cc: | mapx, trev, greiner | Blocked By: | |
Blocking: | Platform: | Unknown | |
Ready: | yes | Confidential: | no |
Tester: | Verified working: | no | |
Review URL(s): |
Description
Background
Starting with Chrome 41 chrome.tabs.insertCSS() will allow to inject CSS per frame. This approach is preferable over injecting a <style> element with a content script, because it leads to less side effects, and should be more efficient than using Shadow DOM.
What to change
Once Chrome allows to limit chrome.tabs.insertCSS() per frame, use it to implement element hiding on supported Chrome versions. Keep the former approach, injecting a <style> element, as fallback for older Chrome and Opera versions, as well as for Safari.
Attachments (0)
Change History (8)
comment:1 Changed on 11/16/2014 at 03:19:55 PM by mapx
- Cc mapx added
comment:2 Changed on 11/17/2014 at 08:13:43 PM by trev
comment:3 Changed on 11/17/2014 at 08:13:54 PM by trev
- Cc trev added
comment:4 Changed on 11/18/2014 at 10:44:14 AM by sebastian
- Resolution set to invalid
- Status changed from new to closed
Unfortunately you are right. I just tested it, and any <style> and <link rel="stylesheet"> element provided by the web page overrides stylesheets injected with chrome.tabs.insertCSS(), when the conflicting rules have the same priority. However, Shadow DOM lets us override all stylesheets of the web page, except those configured with style attributes, using !important priority.
comment:5 Changed on 11/18/2014 at 12:42:21 PM by trev
- Resolution invalid deleted
- Status changed from closed to reopened
Splitting hairs here but the correct resolution would be "rejected" I think.
comment:6 Changed on 11/18/2014 at 12:42:30 PM by trev
- Resolution set to rejected
- Status changed from reopened to closed
comment:7 Changed on 11/18/2014 at 01:12:07 PM by sebastian
I'd say it's invalid, because the issue was filed under wrong assumptions.
comment:8 Changed on 12/09/2014 at 02:04:13 PM by greiner
- Cc greiner added
Won't this make issues similar to #242 even more prevalent? My understanding is that any rule defined by the web page will always override the ones we define.