New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 778816 link

Starred by 5 users

Issue metadata

Status: Started
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Feature



Sign in to add a comment

Allow access to closed shadow roots from extensions

Project Member Reported by m.jeth...@eyeo.com, Oct 26 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36

Steps to reproduce the problem:
 1.  Go to https://manishjethani.com/examples/closedshadow
 2.  Observe the blinking ad
 3.  Install Adblock Plus 1.13.4 or newer
 4.  In the extension's options, add the custom filter manishjethani.com#?#.info:-abp-contains(Flashy Ad)
 5.  Reload the page
 6.  Observe that the ad is hidden
 7.  Wait for 5 seconds and observe again

What is the expected behavior?
The ad should remain hidden.

What went wrong?
The ad is back!

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 62.0.3202.62  Channel: n/a
OS Version: OS X 10.12.6
Flash Version: 

See the script, it removes the ad from the light DOM and adds it to the shadow DOM. As the shadow root is closed, there's no way for the ad blocker to access it to hide the ad again.

Please note that Adblock Plus 1.13.4 doesn't try to access the shadow DOM at all, closed or not, but that's precisely because it would be easy for page authors to circumvent it by using a closed shadow DOM. We would like to have access to the shadow DOM, even if it's closed, from the extension. It's reasonable as extensions work on the user's behalf, an extension should be able to modify any part of the DOM.
 
page.html
1.8 KB View Download

Comment 1 by m.jeth...@eyeo.com, Oct 26 2017

Ideally this would be done via the MutationObserver API. When a new shadow is attached, it should dispatch an event from the host element.
Labels: Needs-Triage-M62

Comment 3 by hayato@chromium.org, Oct 27 2017

Components: -Blink>DOM Platform>Extensions>API
Cc: sc00335...@techmahindra.com
Labels: -Type-Bug -Pri-2 Triaged-ET M-64 hasbisect OS-Linux OS-Windows Pri-1 Type-Bug-Regression
Owner: hayato@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 62.0.3202.62 and on latest canary 64.0.3251.0 using Mac 10.12.6, ubuntu 14.04 and Windows 10.

Manual Bisect Info:
================
Good Build: 53.0.2783.0
Bad Build: 53.0.2784.0

You are probably looking for a change made after 402721 (known good), but no later than 402736 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/add903e53f376a09a3b92a4912eed69b92d389e0..936536dbbfd6cb9cf468c80aba316cabafb0f002

Review-Url: https://codereview.chromium.org/2108533002

Suspecting same from above changelog.

@hayato: Please confirm the bug and help in re-assigning if it is not related to your change.

Thanks.

Comment 5 by m.jeth...@eyeo.com, Oct 28 2017

I should add that this is not a bug per se but more of a feature request.

Comment 6 by hayato@chromium.org, Oct 30 2017

Labels: -hasbisect -Hotlist-Interop -Type-Bug-Regression -M-64 -Needs-Triage-M62 -Triaged-ET Type-Feature
Owner: ----
Status: Available (was: Assigned)
Yup, this is clearly a feature request. Not a bug.

Comment 7 by m.jeth...@eyeo.com, Feb 2 2018

Owner: m.jeth...@eyeo.com
Status: Started (was: Available)

Sign in to add a comment