When using this module, for dynamically loading embeds (Such as Vimeo or Soundcloud), based on consent, the `async` tag causes major issues.
From what I can see in the browser log, it's due to the DEFAULT "Content Blocker" feature of Safari.
If I turn off Content Blocker, it works every time.
If the content blocker is on, it works ROUGHLY 33% of the time, when loading the page.
I contacted Cookiebot, and they told me this:
It looks like it's caused by a timing issue, that apparently only happens in Safari. When I am unable to load the placeholder
, I get the following error message that seems to be related to a variable that doesn't yet have any value:
You can either remove the 'async' part of the Cookiebot script, which will force your other scripts to wait for the Cookiebot script to be fully loaded and thereby have the 'Cookiebot' Javascript object loaded with data or you can set up an event listener on your function that dynamically loads your Vimeo videos, to make sure that process doesn't start until Cookiebot is fully loaded.
You can find an overview of the events pushed by the Cookiebot script in our developer documentation: https://www.cookiebot.com/en/developer/.I've tested removing the 'async' part of your Cookiebot script in a local override in Safari, and I am unable to provoke the issue when loading the Cookiebot script synchronously.
He was completely right - when I remove the `async` that is added through this module, it works every single time in Safari.
Proposed solution
Provide an extra setting to allow users to optionally disable the async loading of cookiebot when this causes issues on your project.
Things to do
Provide a patch/Issue fork
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3271014_no-async.patch | 1.07 KB | ras-ben |
| cookiebot-no-async.patch | 939 bytes | ras-ben |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
anybodyThank you @ras-ben. Removing the async in general is not an option, as it's best practice and recommended by cookiebot.
But you may add a setting to disable async. This won't be that hard to implement, I guess.
Which makes it even easier is, that in "cookiebot-declaration.html.twig" it doesn't have to be removed as it's just the cookie declaration which doesn't block anything and should stay as-is.
Comment #3
ras-ben commented@anybody I'm sorry, but how can it be best practice when it results in things being broken in Safari?
It's Cookiebots own support that told me to remove the async
Comment #4
a.milkovskyAs there are different requests from different persons, I propose to add a new setting to deactivate async load.
Comment #5
ras-ben commentedThis is still a big issue in Safari.
I really suggest that you read the description, rather than just reading the patch file
I know that async helps with performance, but seeing as the majority of people use safari, i'd say it's a bigger issue than performance.
Anyway - I've made a new patch to match the latest version of cookiebot.
Comment #6
bramdriesenI don't think we can just delete this. It should be made an option in the settings screen.
I highly doubt that. The order of browser popularity is more like Chrome -> Edge -> Safari and firefox somewhere in between.
This post for example also tells otherwise about Async loading of Cookiebot: https://support.cookiebot.com/hc/en-us/community/posts/360009471020-Why-...
Are you sure it's not something else which is causing your issue?
Comment #7
ras-ben commented@BramDriesen
>I don't think we can just delete this. It should be made an option in the settings screen.
I'm not trying to be a dick, but assuming that I'm right, do you really think it would be a good idea to have an option that breaks cookiebot in a large chunk of browsers?
>I highly doubt that. The order of browser popularity is more like Chrome -> Edge -> Safari and firefox somewhere in between.
Safari is the second most used browser: https://gs.statcounter.com/
It's the default browser for Mac, which is also the second most used OS at 20%.
Regardless - the popularity of an modern browser, universially supported is irrelevant.
Firefox is used by only 4% of users, but we obviously shouldnt just neglect them either.
>This post for example also tells otherwise about Async loading of Cookiebot:
I know - but as i said originally, I have been talking directly with Cookiebot support, who told me that the async can cause issues.
I cant vouch for their documentation.
---
I'm not the owner of this project, and obviously it's not my call, but I cant see how just sticking your head in the sand helps anyone
I've given you examples of how to re-create the issue, and a patch for how to fix it.
How you go about with it from here, is up to the maintainers.
Comment #8
bramdriesen3 maintainers suggested adding an option instead of removing. I also don't think anyone is sticking their head in the sand 😉
Async loading is still the way to go in my opinion, but providing an option for those x% that may encounter issues with async loading is the best way to go. We for example have no issue with this on our projects.
This is like saying to Drupal core that cache can cause issues, so we should remove it.
Not trying to prove anything here, but to move this forward, we simply need a checkbox in the UI and a condition. Nothing more, nothing less. Okay maybe update the documentation and readme, but that's it.
You can of course still use your patch as long as the real fix is not in the latest release :)😉
Comment #9
bramdriesenComment #10
bramdriesenComment #11
ras-ben commentedYeah, 3 maintainers has suggested making it an option, but none of them has actually acknowledged the issue that I've pointed out
If you acknowledge the issue, that the module only works sporadically on Safari, I really cannot see how just making it an option solves anything
That's what I meant about sticking your head in the sand
As i said - I've given you a description of how to recreate the issue..
Just because you rename the issue and change the priority, doesnt mean that it's not a big problem in Safari - the second most used browser in the world.
I'm here, volunteering my own time to try and solve a general issue, that was really hard for me to troubleshoot, and is hard for others to catch.
I feel like you're treating me like an idiot - Hinting that I dont know what async does or what the benefits of it is.
Meh. I've done my bit now. As I said, I dont want to come off as a dick, but this is super frustrating.
I don't want to spend more of my free time on this, seeing as you're not interested in listening.
Comment #12
bramdriesenI checked a few of our projects on Safari and none show any issues with cookiebot. I also checked if content blocker was enabled and it was.
I'm not saying it isn't a problem. Just changing the title and description to what actually needs to be done to land this feature.
I know debugging is not always easy. And totally not want to feel you that way. I'm also here spending my own free time ;)
You sure did! Reporting the issue, debugging it and even providing a patch. For which we all thank you! And I assure you we are listening/reading.
Comment #13
ras-ben commentedThank you. All I wanted was for someone to actually acknowledge the issue, rather than my solution.
I can't talk for how your site is using cookiebot, but both I and the Cookiebot-supporter could recreate the issue consistently.
I use the Cookiebot placeholders, for 'hiding' Youtube/Vimeo until the user has accepted the relevant cookies.
It's this core cookiebot functionality that appears to break when using Async.
You can see the issue in action here:
https://halfdoubleinstitute.org
- Accept cookies
- Scroll down to "How does it work in practice?"
- You should see a video slider
- If you continue to refresh the page, roughly 33% of the time, the video wont show up
- When it happens, you'll also see this error in the console: "TypeError: undefined is not an object (evaluating 'Cookiebot.consent[cookieConsentCategory]')"
Comment #15
bramdriesenI was also able to reproduce it on your site. However on 2 sites of our own with similar video blocking logic I could not. So it still might be a combination of things that will be very difficult to pinpoint.
I created a MR adding it as an option. Also spotted another option that got added but not properly to the schema etc so I fixed that as well in one go.
Comment #16
ras-ben commentedHmm, that's weird.. But thank you for testing it!
Perhaps my site has some weird edgecase. I also experienced it on other of my sites though.
Regardless - I was under the impression that it happened to all sites, so now that you've tested it, we can assume that mine is an edgecase, and then I can also see that an admin-option would suffice.
I've added a little suggestion to your MR, otherwise it looks good to me.
I assume that you dont want my review, as I'm not a maintainer (?)
Thank you for taking the time to actually test it, I appreciate it.
Comment #17
bramdriesenWhat makes you think that? 😉 Everyone is more than welcome to review code! Doesn't matter if you're a maintainer or not :). So thanks for your review.
You even learned me about the suggest change feature of GitLab! Didn't know that was a thing 😁.
Well, unless those sites are nearly identical in set-up (Drupal+Cookiebot) I wouldn't call it an edge case anymore.
Comment #19
bramdriesenSorry for the delay. I just merged the code, let me know if you still encounter issues by creating a new issue :-).
New release will be tagged in a minute.