Opened 3 years ago

Closed 3 months ago

#4233 closed defect (rejected)

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

Reported by: passbrains Assignee:
Priority: P3 Milestone:
Module: Platform Keywords: closed-in-favor-of-gitlab
Cc: sebastian, scheer, kzar, greiner Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description (last modified by kzar)

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.

Attachments (3)

2315_1466945045_2016-06-26_1544.png (256.5 KB) - added by passbrains 3 years ago.
2315_1466945045_2016-06-26_15441.png (288.8 KB) - added by passbrains 3 years ago.
2315_1466945318_Screen_Recording_50.mov (4.1 MB) - added by passbrains 3 years ago.

Download all attachments as: .zip

Change History (13)

Changed 3 years ago by passbrains

Changed 3 years ago by passbrains

Changed 3 years ago by passbrains

comment:1 Changed 3 years ago by 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.

comment:2 Changed 3 years ago by scheer

  • Description modified (diff)
  • Summary changed from Block element to Scrolling a page whilst having a highlighted element to be blocked causes the element highlight to move with the page

comment:3 Changed 3 years ago by trev

  • Component changed from Unknown to Platform

comment:4 Changed 3 years ago by kzar

  • Cc sebastian scheer kzar added
  • Description modified (diff)
  • Platform changed from Safari to Unknown / Cross platform
  • Priority changed from Unknown to P3
  • Ready set
  • Summary changed from Scrolling a page whilst having a highlighted element to be blocked causes the element highlight to move with the page to Block element red highlighting doesn't move when page is scrolled

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

comment:5 Changed 3 years ago by kzar

  • Owner set to kzar

comment:6 Changed 3 years ago by kzar

  • Cc greiner added
  • Owner kzar deleted

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.

comment:7 Changed 3 years ago by 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).

comment:8 follow-up: Changed 3 years ago by 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...

comment:9 in reply to: ↑ 8 Changed 3 years ago by 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.

comment:10 Changed 3 months ago by sebastian

  • Keywords closed-in-favor-of-gitlab added
  • Resolution set to rejected
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.