Block element red highlighting doesn't move when page is scrolled

[passbrains]

Adapted from ​https://platform.passbrains.com/dashboard/view-ticket.php?ticket_no=ASA-94

Environment

Multiple environments, including:

• Adblock Plus 1.12.0.1622, Safari 6, OS X 10.7
• Adblock Plus 1.12.1.1627, Safari 6, OS X 10.8
• Adblock Plus ​changeset 6a895c3d658d, Chrome Version 51.0.2704.106 (64-bit), Debian Stretch

How to reproduce

1. Load ​https://www.blogger.com/home?bpli=1&pli=1
2. Right click pencil image beside any blog
3. Select Block element option
4. Switch back to the website after the Block element dialog opens
5. Scroll up and down

Observed behaviour

The element is highlighted red after it is selected for blocking. When scrolling up and down on the page the red box does not move with the page.

Expected behaviour

The red highlighting for targeted elements should move properly along with the elements when the user scrolls.

[passbrains]

1 - 30 Jun 2016 14:25:40 posted by Timo Scherf
The attached Video makes it obvious. Personally I could not reproduce this issue. This issue might be caused by multiple layer / element layout of the page.

2 - 08 Jul 2016 13:13:22 posted by Scott Cheer
I was able to reproduce this, although this is a relatively small issue, I have promoted it to our issue tracker. ABP 1.12.1.1627 OSX 10.8 64 Bit. Safari 6.

[kzar]

Can reproduce as described, but does not seem to be limited to Safari. Agreed with Scott that it's a relatively minor issue.

[kzar]

Copying in Thomas since the CSS involved here is out of my depth.

The problem appears to be caused by a parent div with overflow: auto being scrolled. I think our overlays stay still because they are not children of this div and because they have absolute positioning.

The relevant code is the addElementOverlay function in adblockpluschrome/composer.postload.js.

[greiner]

Yes, that appears to be the culprit. I have my doubts that there's a quick and simple fix for this because I haven't seen an extension yet that accomplishes to do this and I assume that the highlighting done by Chrome's DevTool's is using native code.

So the question is how we'd want to tackle this. Maybe styling the element directly by attaching a shadow root to it might do the job because I wouldn't attach our UI elements to any of its parent elements though since these might change (e.g. image in a carousel UI).

[kzar]

Since we traverse the selected element's parents we do have a chance to check for the overflow styles. I figured perhaps we could do something special for those, setting the parent node as the element with the overflow style instead of document.documentElement and making use of the scrollTop scrollLeft attributes for the offsets. I didn't have much luck actually getting it working however...

[greiner]

Replying to kzar:

Since we traverse the selected element's parents we do have a chance to check for the overflow styles. I figured perhaps we could do something special for those, setting the parent node as the element with the overflow style instead of document.documentElement and making use of the scrollTop scrollLeft attributes for the offsets. I didn't have much luck actually getting it working however...

That would be very specific to this one situation. I'd rather go with something more generic like directly linking ourselves to the element or at least updating the element's position when we notice that it changed (if that can be implement with reasonable performance).

That way we'd not only handle this specific situation but any other similar scenarios that we might not be aware of yet.

[sebastian]

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the ​new issue tracker.