Chromium issue

colak · 2023-05-19 06:38:40

Recently I noticed that the cookie consent divs for youtube videos are not displaying in chromium based browsers (Brave and Chrome). I am pulling my hair as I cannot understand why. Can someone shed some thoughts on what may be blocking that content which actually shows in the source of the pages?

Sample url: www.neme.org/projects/state-machines/unbuilding-citizenship

phiw13 · 2023-05-19 07:25:27

Do you mean the div.gdpr does not display at all? (a box with a yellow background, at the top a still or poster image, at the bottom some legaleze)

Safari does not display that div here, but Firefox and Brave both do.
And as a result, I cannot watch the video.

I suspect a possible adblocker issue.

Bloke · 2023-05-19 07:28:47

The block at the bottom shows fine for me in Chrome for mobile.

Pat64 · 2023-05-19 14:13:46

Hi, Yiannis.

Here are some screenshots from the (real browsers) lambdatest.com Platform.

https://postimg.cc/gallery/by5Qrbm

phiw13 · 2023-05-19 23:38:00

phiw13 wrote #335436:

I suspect a possible adblocker issue.

That is indeed the case – both #eucookies and .gdpr are in the list (in 1Blocker: “annoyances” category – there are quite a few of those “eu cookie” thingies in the group). The source is easylist.to, used by many/most ad&content blockers.

colak · 2023-05-22 14:09:15

phiw13 wrote #335439:

That is indeed the case – both #eucookies and .gdpr are in the list (in 1Blocker: “annoyances” category – there are quite a few of those “eu cookie” thingies in the group). The source is easylist.to, used by many/most ad&content blockers.

Firstly apologies for my late response. I was stranded abroad without my power supply.

That was indeed the problem. I replaced gdpr with the title of my favourite John Carpenter movie (theylive) and eucookies with soylentgreen and everything appears to have come back again.

phiw13 · 2023-05-22 22:26:43

colak wrote #335440:

I replaced gdpr with the title of my favourite John Carpenter movie (theylive) and eucookies with soylentgreen and everything appears to have come back again.

That is a good strategy – using completely unrelated “tags”. Another strategy, used e.g. by the WSJ site is using random generated ids and classes that commonly used on the site.

BTW – Same thing applies to comments, many variations of comments-*** are included in contents-blockers. The default TXP comments set-up is hidden by many contents-blockers.

Bloke · 2023-05-23 06:01:11

phiw13 wrote #335441:

Same thing applies to comments, many variations of comments-*** are included in contents-blockers. The default TXP comments set-up is hidden by many contents-blockers.

Is there an argument to change it then, somehow? Make the prefix customisable from config.php, perhaps, in case someone gets blocked?

colak · 2023-05-23 06:28:10

phiw13 wrote #335441:

BTW – Same thing applies to comments, many variations of comments-*** are included in contents-blockers. The default TXP comments set-up is hidden by many contents-blockers.

Good catch!!!

Submitted it as a issue.

colak · 2023-05-23 06:32:04

Bloke wrote #335443:

Is there an argument to change it then, somehow? Make the prefix customisable from config.php, perhaps, in case someone gets blocked?

I was posting as you were writing. I actually believe that we should change the default class and id. Can. it be customised in the preferences instead of the config file?

phiw13 · 2023-05-23 06:39:44

Bloke wrote #335443:

Is there an argument to change it then, somehow? Make the prefix customisable from config.php, perhaps, in case someone gets blocked?

I am not sure about comments, honestly. Those blocks exists for people who want to tune out the noise, and / or not be distracted by those comments. They come to the site to read the main content (video / article (text) / …). It is kinda nice to respect their choice.

Most contents blockers offer per-site configuration options, nowadays, I think.
(and IIRC, my content blocker – 1Blocker – initial set up had the comments block category turned off. But don’t quote me on that. It has been humming along for so long…).

BTW – as fas as I can tell, in the Textpattern case the comments form is visible but the actual comments are hidden (.comments-list).

Bloke · 2023-05-23 08:49:12

I’m fine with leaving it. Thinking it through a bit more, customising is not an option as it also affects the CSS file. Can’t think of a neat way round that.

colak · 2023-05-23 17:23:31

Visitor respect v functionality is always a tough decision on the web. The issue to me is that content blockers are (understandably) becoming as aggressive as tracking systems.

Comments in txp are, as far as i noticed, harmless and although I have not used them for may years, some of our users may depend on such feedback and they will not get it because of the blockers.

It does indeed require more thinking.

Textpattern CMS

Textpattern CMS support forum

#1 2023-05-19 06:38:40

Chromium issue

#2 2023-05-19 07:25:27

Re: Chromium issue

#3 2023-05-19 07:28:47

Re: Chromium issue

#4 2023-05-19 14:13:46

Re: Chromium issue

#5 2023-05-19 23:38:00

Re: Chromium issue

phiw13 wrote #335436:

#6 2023-05-22 14:09:15

Re: Chromium issue

phiw13 wrote #335439:

#7 2023-05-22 22:26:43

Re: Chromium issue

colak wrote #335440:

#8 2023-05-23 06:01:11

Re: Chromium issue

phiw13 wrote #335441:

#9 2023-05-23 06:28:10

Re: Chromium issue

phiw13 wrote #335441:

#10 2023-05-23 06:32:04

Re: Chromium issue

Bloke wrote #335443:

#11 2023-05-23 06:39:44

Re: Chromium issue

Bloke wrote #335443:

#12 2023-05-23 08:49:12

Re: Chromium issue

#13 2023-05-23 17:23:31

Re: Chromium issue

Board footer