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)

33 Branch
x86
Windows 8.1
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
e10s + ---
firefox32 --- wontfix
firefox33 --- affected

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.
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
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
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.
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
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
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.
Latest Element Hiding Helper beta, not work with latest AdBlock Plus beta. Again...
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.
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.
Thanks for the information. Could someone please provide a link to that whitelist?
Wladimir, can we close this issue?
Flags: needinfo?(trev.moz)
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)
Oh yeah it is. Sorry I misread.
You need to log in before you can comment on or make changes to this bug.