pinterest.co.uk: ads

[MrHappymoose]

Prerequisites

• [X] I read and understood the policy as to what is a valid filter issue
• [X] I verified that the issue has not already been reported (use this button to find out)
• [X] I forced an update of my filter lists (how to do this: click "Purge all caches", then click "Update now")
• [X] I did not remove any of the default filter lists
• [X] I have no custom filter lists, or I verified that the issue still occurs without custom filter lists
• [X] I am not using another content blocker along uBO

URL address of the web page

https://www.pinterest.co.uk/

Category

ads

Describe the issue

Over the last few months previously blocked 'Promoted Pins' have been showing as blank spaces on the page rather than all real pins shifting together properly. I suppose something like a week to ten days ago (Approximately) the 'Promoted Pins' have started showing completely as if not being blocked at all, this includes autorunning video clips in pins.

Screenshot(s)

Screenshot(s)

Configuration

```yaml uBlock Origin: 1.39.2 Chromium: 96 filterset (summary): network: 78443 cosmetic: 39426 scriptlet: 16264 html: 0 listset (total-discarded, last updated): default: easylist: 61345-6, 1m easyprivacy: 26463-17, 1m plowe-0: 3698-811, 1m ublock-abuse: 72-0, 1m ublock-badware: 3539-60, 1m ublock-filters: 29881-127, 1m ublock-privacy: 188-1, 1m ublock-unbreak: 1705-38, 1m urlhaus-1: 8444-0, 1m filterset (user): [array of 1 redacted] trustedset: added: [array of 3 redacted] modifiedUserSettings: [none] modifiedHiddenSettings: [none] supportStats: launchToReadiness: 27090 launchFromSelfie: true popupPanel: blocked: 4 ```

[gorhill]

Side note: 27-second to launch to readiness? This is not expected, and I doubt this is normal.

I want to try to understand why this would happen, can you please answer the following questions?

• Are you launching from a hard disk? (as opposed to from a solid-state disk)
• Do you have other extensions, and if so how many?
• Do you have some sort of antivirus?
• If you consistently get such bad launch timing (should be under a second when a selfie is available), do you have same issue with latest uBO dev build?
  • You can see launch-to-readiness timing in the troubleshooting information at the bottom of Support pane in dashboard.

[MrHappymoose]

Side note: 27-second to launch to readiness? This is not expected, and I doubt this is normal.

I want to try to understand why this would happen, can you please answer the following questions?

• Are you launching from a hard disk? (as opposed to from a solid-state disk) Launching from hard disk

• Do you have other extensions, and if so how many? Currently, as well as uBlock there are 27 other extensions running

• Do you have some sort of antivirus? I tend to not run an antivirus and rely on being careful/sensible as past antivirus software caused me more problems than they solved

• If you consistently get such bad launch timing (should be under a second when a selfie is available), do you have same issue with latest uBO dev build?

  • You can see launch-to-readiness timing in the troubleshooting information at the bottom of Support pane in dashboard. Not sure if LtR is consistent as I'd never realised there was an issue so never looked. Dev build does seem better (I think)

uBlock Origin: 1.39.1rc0 Chromium: 96 filterset (summary): network: 77551 cosmetic: 39191 scriptlet: 16211 html: 0 listset (total-discarded, last updated): default: easylist: 60746-451, never easyprivacy: 25518-214, never plowe-0: 3689-3, never ublock-abuse: 67-0, never ublock-badware: 3421-1, never ublock-filters: 29741-107, never ublock-privacy: 186-0, never ublock-unbreak: 1690-0, never urlhaus-1: 8813-0, never filterset (user): [empty] modifiedUserSettings: [none] modifiedHiddenSettings: [none] supportStats: launchToReadiness: 4902 launchFromSelfie: false

[gorhill]

@MrHappymoose my bad, I forgot the current dev build in Chrome store is too old, they didn't yet approve the latest dev build. But even then, I see that the time-to-readiness is far lower despite not loading from a selfie, and despite probably that the list had to be compiled.

Can you answer to at least this one other question: in your normal installation of uBO, do you consistently get high launchToReadiness values every time you restart the browser (or even just uBO)?

[MrHappymoose]

Can you answer to at least this one other question: in your normal installation of uBO, do you consistently get high launchToReadiness values every time you restart the browser (or even just uBO)?

I just tried the normal installation a few times to see and got the following results so it seems fairly clear it's not consistent.

launchToReadiness: 18570 launchToReadiness: 3061 launchToReadiness: 2783 launchToReadiness: 1395 launchToReadiness: 1572

Might be a stupid question (I'm really not that up on the inner workings of this kind of thing) but could the broadband connection affect it? We live out in the sticks with an utterly shocking broadband that is constantly up and down. Probably got nothing to do with this but I thought I'd mention it just in case.

[gwarser]

@gorhill I recall uBO will wait for filter lists to update in some circumstances. Fresh installation? Blocked storage? I talked with you about this once.

[gorhill]

I recall uBO will wait for filter lists to update in some circumstances.

This happens only when a list is not part of the package (added: and only at install time), in which case it must be downloaded, but as per config above, they are all part of the package.

[gorhill]

could the broadband connection affect it?

uBO does not need a network connection at launch, it uses all the resources cached locally, so network latency should not have any effect on launch speed.

---

Maybe Chrome does something at launch which could delay fetching resources from local storage by the browser API. Did you get the above figures by launching the browser or by just disabling/enabling uBO. If the former, can you see the results with just disabling/enabling uBO when the browser is idle?

[MrHappymoose]

Maybe Chrome does something at launch which could delay fetching resources from local storage by the browser API. Did you get the above figures by launching the browser or by just disabling/enabling uBO. If the former, can you see the results with just disabling/enabling uBO when the browser is idle?

The first set of figures was indeed from rebooting the entire browser, the following figures are from rebooting just uBO itself.

launchToReadiness: 576 launchToReadiness: 589 launchToReadiness: 583 launchToReadiness: 605 launchToReadiness: 552

[mapx-]

@MrHappymoose provide screenshot, specific page, indications on the ads

[MrHappymoose]

Not entirely sure why this has been closed as I wasn't exactly given a lot of time to respond. Is it even worth me bothering to provide the screenshots now??

[mapx-]

provide the info (screenshot, specific page, indications on the ads)

[MrHappymoose]

Example 01 - https://www.pinterest.co.uk/pin/727049933586892218/

Example 02 - https://www.pinterest.co.uk/pin/844493665938055/

Example 03 - https://www.pinterest.co.uk/

As you can see the adverts that were previously blocked now appear on multiple pages

[mapx-]

All fine on my side, the promoted by are still hidden by:

pinterest.co.uk##div[data-test-id="pin"]:has(div[title="Promoted by"])

[mapx-]

You should reset uBO to default settings, then force an update of all lists. Don't use other extensions while testing again.

[MrHappymoose]

You should reset uBO to default settings, then force an update of all lists. Don't use other extensions while testing again.

I just set up a fresh instance of Chrome with uBO being the only app even installed and I still got the ads. I also checked Firefox with just uBO and still have the same issue

[gorhill]

I don't have an account on that site, I see that even with uBO disabled I do not see such ads as seen in your screenshots.

[mapx-]

I have an account and the existent filters are still working fine.

[gorhill]

It would be useful to see the HTML layout of those ads in the browser inspector.

---

Can you right-click on the "Promoted ads" label and select "Inspect" and post a screenshot of what it shows?

[amuhav]

sorry, the button to check if anything had already been logged didn't show any open issues as I'm using .com rather than .co.uk. Would like to add that for some reason, some accounts do not seem to get ads and we don't know why. I have two other friends that use the site, both with ordinary accounts, and one never gets any ads even with all adblockers off.

[amuhav]

wasn't sure how much to screenshot

[Yuki2718]

Test pinterest.*##.Hsu.iyn.zI7 > div[style^="-webkit-line-clamp"] > span:has-text(Promoted by):upward(2)

[amuhav]

that just removes the "Promoted by" label, not the ad.

[Yuki2718]

How about pinterest.*##.Hsu.iyn.zI7 > div[style^="-webkit-line-clamp"] > span:has-text(Promoted by):upward(a[tabindex]):upward(2) There may be better way, but anyway.

[amuhav]

nope, just gets rid of the little bit telling you who the ad is for, unfortunately!

[Yuki2718]

I guess pinterest.*##.Hsu.iyn.zI7 > div[style^="-webkit-line-clamp"] > span:has-text(Promoted by):upward(14) would work but want more wider screenshot of the tree (including parents). No, depth varies.

[MrHappymoose]

Not sure if this is still of any use, but here's the screenshot after clicking Inspect on the Dremel ad

.

[amuhav]

not sure which element to inspect, exactly, as the ads are broken up into different parts (the label, the ad itself, the containers etc)

[Yuki2718]

I missed the EL rule. Test pinterest.*##.Hsu.iyn.zI7 > div[style^="-webkit-line-clamp"] > span:has-text(Promoted by):upward(div[data-test-id="pin"])

Fixed typo

[gorhill]

Typo: pinterst => pinterest

[gorhill]

.Hsu.iyn.zI7 >

Starting with ##span:not([class]):has-text(Promoted by) does not seem bad, I get only 7 matches on my side for span:not([class]).

---

How about:

pinterest.*##span:not([class]):has-text(Promoted by):upward([data-grid-item="true"])

[Yuki2718]

.Hsu.iyn.zI7 >

Starting with ##span:not([class]):has-text(Promoted by) does not seem bad, I get only 7 matches on my side for span:not([class]).

Yep, but not sure if that's true to all the pages. Even on the same page ##.Hsu.iyn.zI7 > div[style^="-webkit-line-clamp"] > span halves the match compared to ##span:not. I can say .Hsu.iyn.zI7 has been stable at least for a year.

[amuhav]

yuki's seems to work, we're back to blank spaces in place of ads, which I'd def take over the alternative. I don't think it's catching anything other than ads, but hard to tell when you can't replicate the exact same page with a refresh.

[Yuki2718]

@amuhav Does alternating the rule with pinterest.*##.Hsu.iyn.zI7 > div[style^="-webkit-line-clamp"] > span:has-text(Promoted by):upward(div[data-test-id="pin"]):remove() and reloading the page removes the blank space?

[gorhill]

I don't think it's catching anything other than ads, but hard to tell when you can't replicate the exact same page with a refresh.

You can use uBO's own DOM inspector to reveal what was hidden by the cosmetic filter.

[amuhav]

unfortunately not!

[gorhill]

@Yuki2718 Why stop at div[data-test-id="pin"]? On my side I can go up to [data-grid-item="true"].

Can you guys try:

pinterest.*##span:not([class]):has-text(Promoted by):upward([data-grid-item="true"])

[Yuki2718]

Hiding won't work so pinterest.*##span:not([class]):has-text(Promoted by):upward([data-grid-item="true"]):remove()

[gorhill]

Hiding won't work

Right, the page positions the items with absolute x,y values. uBO's DOM inspector won't show removed items so there is no point using it then.

[gorhill]

Just to be reduce likelihood of false positives, we can use data-test-id to narrow down, so maybe final version:

pinterest.*##div[data-test-id="pin"] span:not([class]):has-text(Promoted by):upward([data-grid-item="true"]):remove()

[amuhav]

that one broke the page when trying to scroll down...

[amuhav]

the last one to work and not break everything when scrolling was

pinterest.*##.Hsu.iyn.zI7 > div[style^="-webkit-line-clamp"] > span:has-text(Promoted by):upward(div[data-test-id="pin"]):remove()

[Yuki2718]

I can reproduce (I don't see ads so with an alternative rule), if removed page breaks

[Yuki2718]

pinterest.*##div[data-test-id="pin"] span:not([class]):has-text(Promoted by):upward([data-grid-item="true"]) should work tho leaves the space.

[gorhill]

So maybe data-grid-item should not be removed after all. Can you try:

pinterest.*##div[data-test-id="pin"] span:not([class]):has-text(Promoted by):upward([data-test-id="pin"]):remove()

I just like that it does not rely on random-looking class names.

[Yuki2718]

@gorhill He already tried that and that can't remove the space, as expected.

[gorhill]

He said similar worked above. I just use a different selector before :has-text(Promoted by):upward([data-test-id="pin"]):remove().

[Yuki2718]

He meant it doesn't break but leaves space, if I understand correctly.

[Yuki2718]

Probably pinterest.*##div[data-test-id="pin"] span:not([class]):has-text(Promoted by):upward([data-grid-item="true"]) is the best we can, as scriptlet can't be used.

[amuhav]

I'm getting confused 😅

The ones I said "broke the page" literally broke the page when scrolling, the pins part of the page completely disappears.

Otherwise, every other one worked exactly the same, got rid of the ad pins leaving a white space. Takes a split second to hide them though, which I don't think it was doing before whatever ublock was doing originally stopped working, but suspect that's the best that can be hoped for? Still better than seeing them permanently.

[Yuki2718]

Yep, at least I can't do anything better. Thanks for your cooperation.