Opened 3 years ago

Last modified 3 years ago

#4159 new change

Allow better sorting of in-page search match results in Cookie Policy pop-ups

Reported by: scheer Assignee:
Priority: P4 Milestone:
Module: Adblock-Browser-for-iOS Keywords:
Cc: Blocked By:
Blocking: Platform: Adblock Browser for iOS
Ready: no Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

Description

Background

In-page search currently takes characters from the Cookie Policy pop-ups into account when displaying the search results. Due to this, the first displayed result can be a position greater than 1. Result 1 being the first result that should always be displayed after the initial search is done.

What to change

Exclude Cookie Policy pop-ups from the search results or introduce some kind of CSS z-order sorting of the match results.

Change History (4)

comment:1 Changed 3 years ago by philll

I would tend to not manually exclude any visible parts of a site from being searched. I frequently find this very irritating when sites do this on their own and catch the browser's CTRL+F feature.

comment:2 Changed 3 years ago by pavelz

There is no standard representation of Cookie Policy popups, or any kind of meta information attached to it, which would allow us to determine that some part of DOM is such a pop up and should get a different treatment. On the other hand, Safari and Chrome/iOS both search the popups first, which feels somewhat natural - the most obtrusive part of current page rendering is searched first. In any case, it would require an elaborate z-order detection and sorting, which will be tricky to do dependably right. In other words, not to screw more than the current simple but mostly correct approach.

comment:3 Changed 3 years ago by mario

  • Priority changed from Unknown to P4

comment:4 Changed 3 years ago by pavelz

z-index covers 80% of web popups. *Nicely used* z-index covers 70% of web popups. *Nicely: an isolated, one level modification, as contrary to multilevel overlaying modifications. The rest 30% is hacking z-indexing context through other CSS techniques which are not z-index but still introduce z-index-like context - namely transform, position:fixed, accelerations etc. (i don't understand this stuff at all, but Salsita CSSfu master told me)

70% solution: fairly simple. From every text-matching node, walk the DOM parents until first z-index context is found. Record along the match order, sort accordingly.
80% solution: reasonably demanding. Walk the whole DOM until root and record ALL found z-index in reverse order. Sort from topmost down, use deeper levels on z-index equality.
100% solution: possible but challenging. A list of z-index modifying hacks would have to be detected and recorded on every level and assume the mutations it introduces to z-index. Then 80% solution follows.

Salsita CSSfu master session (in czech!) is posted at https://www.pivotaltracker.com/story/show/122196265

Note: See TracTickets for help on using tickets.