Closed
Bug 1041071
Opened 11 years ago
Closed 11 years ago
[e10s] Element hiding helper for ABP doesn't work with e10s
Categories
(Firefox :: Extension Compatibility, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: tenisthenewnine, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 6.3; rv:33.0) Gecko/20100101 Firefox/33.0 (Beta/Release)
Build ID: 20140718030202
Steps to reproduce:
Hi, EHH doesn't work on e10s.
Updated•11 years ago
|
Blocks: e10s-addons
Summary: Element hiding helper for ABP doesn't work with e10s → [e10s] Element hiding helper for ABP doesn't work with e10s
Updated•11 years ago
|
Comment 1•11 years ago
|
||
This seems to be related to the error message: "Argument 1 of Document.importNode does not implement interface Node." While there is no line number there, it should be related by this line:
this.boxElem = doc.importNode(E("ehh-elementmarker").firstElementChild.cloneNode(true), true);
What this does is taking an <html:div> element (a template) from a XUL document, cloning it, then importing it into a content document. My guess it that doc.importNode() sees a wrapper and doesn't recognize it as a DOM node.
We can fix this fairly easy on our end by changing the templating mechanism.
Status: UNCONFIRMED → NEW
Component: Untriaged → Extension Compatibility
Ever confirmed: true
Comment 2•11 years ago
|
||
I created https://issues.adblockplus.org/ticket/1091 for that. Using a different templating mechanism I can confirm that creating the nodes directly in the content document fixes the issue.
Updated•11 years ago
|
Assignee: nobody → wmccloskey
I think this bug was mistakenly assigned to me. It's not a regression, but an add-on compat issue that we've had for a while. If the EHH devs can fix it on their end, that would be much better.
Assignee: wmccloskey → nobody
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 5•10 years ago
|
||
Assignee: :tracy
Link to add-on: https://addons.mozilla.org/en-US/firefox/addon/elemhidehelper/?src=search
Contact info for add-on: trev.moz@adblockplus.org
Bug #: This bug 1041071
Add-on ID: elemhidehelper@adblockplus.org
How well does it work?: 90% (data indicates it's in cpow some)
Any obvious performance problems? no
SDK-based: restartless addon
Chromium version: no
Comment 6•10 years ago
|
||
Yes, there is some remaining CPOW usage when selecting an element, this can also be noticeably slow. There is https://issues.adblockplus.org/ticket/2879 for that, AFAIK the last E10S compatibility issue for Element Hiding Helper.
Comment 7•9 years ago
|
||
Latest Element Hiding Helper beta, not work with latest AdBlock Plus beta. Again...
Comment 8•9 years ago
|
||
Works fine for me, so you will need to provide more details. Either way, this pretty certainly has nothing to do with this bug. I think it's best if you file a new bug under https://issues.adblockplus.org/newticket.
Just wanted to report that, though in https://arewee10syet.com/ it lists EHH v1.3.10 as e10s compatible,
if you launch FF 51 stable x64 in a fresh profile, install only EHH and restart FF,
then unfortunately e10s becomes disabled, as shown in about:support (Multiprocess Windows --> 0/1 (Disabled by add-ons)).
If I disable EHH and restart FF then e10s becomes enabled again.
Comment 10•8 years ago
|
||
AFAIK, there is still a separate whitelist for add-ons that won't disable E10S in stable Firefox versions, not every E10S-compatible add-on is accepted.
Comment 11•8 years ago
|
||
Thanks for the information.
Could someone please provide a link to that whitelist?
Comment 12•8 years ago
|
||
Comment 14•8 years ago
|
||
Isn't it closed already, since 2014? But just in case, next EHH release will work without CPOWs, the necessary changes have been implemented already.
Flags: needinfo?(trev.moz)
Comment 15•8 years ago
|
||
Oh yeah it is. Sorry I misread.
You need to log in
before you can comment on or make changes to this bug.
Description
•