0.7.5 hasn't been a Bugfix-Release according to semver

[tpinne]

It is more a suggestion than a question. But it fits better than a bug report or feature request.

Version 0.7.5 added a new behavior for handling of youtube services showing a contextual message pro actively.

Until today we included the script like https://cdn.kiprotect.com/klaro/v0.7/klaro.js to profit from latest bugfixes. Now we set it fixed to 0.7.4 because our customer called us why there is suddenly this unknown layer asking to show a youtube video or not. And because it was a background video it was covered by other elements making the buttons unclickable.

Such new features are cool and well appreciated. But in our opinion this deservers a version bump to 0.8 or a clear opt in to that feature instead of some default settings which make the script behave differently between releases on bugfix level.

Best regards tpinne

[adewes]

Hi @tpinne! Thanks for opening this issue and sorry about the resulting issue. We will be more careful with release naming in the future. In general, we increase the patch version if we add features or bugfixes that do not affect backwards-compatibility, seems this didn't work in this case.

In general the contextual consent feature that caused this behavior needs to be explicitly enabled to manage consent. So the iframe in questions must've had a data-name attribute and corresponding Klaro config already?

[tpinne]

Yes, we already had the YouTube iframe in question under Klaro control to prevent any unwanted data transmission. And because it is just a cosmetic background video with a background image as a fallback the default behavior up to that point has been perfectly fine.

I know that for inline videos which serve a purpose of content information a 2-click option is more viable and I implemented one myself in another project. But if such a functionality is added and works out-of-the-box with no additional config needed, for existing elements that are properly configured but are expected to work the same way as the time they were implemented it definitely should be an opt-in feature. In worst case scenarios it could break the layout somehow. Overlapping content or sitting behind other content (as in our case) and the default background color of the Klaro layer matches somehow the font color lying above and so on....

As follows our implementation which lead to the "misbehavior" after 0.7.5 has been released.

<iframe class="tx_jhsimpleyoutube" width="560" height="315" data-name="youtube" data-src="https://www.youtube-nocookie.com/embed/..."></iframe>

<script type="application/javascript">
window.klaroConfig = {
    htmlTexts: true,
    acceptAll: true,
    mustConsent: true,
    services: [
      // ...,
      {
        name: 'youtube',
        purposes: ['other'],
        translations: {
          zz: {
            title: 'YouTube',
          },
          en: {
            description: 'Embedding videos on our website',
          },
          de: {
            description: 'Einbetten von Videos auf unserer Webseite',
          },
        },
      },
  ],
}
</script>
<script
  defer
  data-config="klaroConfig"
  type="application/javascript"
  src="https://cdn.kiprotect.com/klaro/v0.7.4/klaro.js">
</script>

[adewes]

Thanks for providing this debug information, @tpinne! In general, clicking on "Accept" will also trigger the enabling of the Youtube content. We will add an option to make the context-based overlay opt-in and enable it only in 0.8 by default, that should solve this issue.

[tpinne]

That it also triggers the enabling of those videos is clear. But if you reject everything the layer still is present. Which is good in general to be able to allow playback on a per videos basis even if I reject everything.

So if you make it default as of 0.8 it would be great to have the option to opt-out. I think it would be useful for website like in our example where videos only serve stylistic purposes and run behind other content and have a fallback.

Really great would be to be able to also opt-out via data-attribute on a per video basis. So a user can generally reject all YouTube videos, but within the website one can choose for which videos to provide an on-the-fly-opt-in option to the user. So background videos could be gracefully ignored on rejection but inline videos could have the on-the-fly-opt-in option.

That could make this already good option for videos a perfect option imho ;-)