Amphtml: amp-consent: Allow fullScreen prompt only with user interaction

[zhouyx]

Based on recent discussion, the <amp-consent> is applying the new check to only allow fullScreen API after user interaction.

The decision was made because of two reasons

1. Security Concern. Avoid full screen embedded iframe without user interaction.
2. UX Concern, Better user experience. A non blocking prompt that takes up to 30vh is recommended based on our UX study. (Having the initial prompt expand right away is used as a workaround to display blocking full screen prompt, but it leads to flicker of the dialog which is not desirable. )

Because of these, the fullScreen API will only be allowed after user has interacted with the CORS iframe. To achieve this we are thinking about checking the document.activeElement. @ampproject/wg-ui-and-a11y Please let me know if that sounds like the right approach.

@MaximePlancke and @andresilveirah Could you please confirm that the Didomi and SourcePoint will continue to work correctly after the change. Thank you very much.

cc @ampproject/wg-analytics

[jawadst]

@zhouyx
Thanks for keeping us updated! Chiming in here as Maxime is OOO this week.

Fullscreen consent collection (ie dialog / popin) is a very important feature for publishers as it forces users to make a choice (whether positive or negative) and has a direct impact on publishers' revenue. A fair amount of our publishers use this option and it would be very disappointing to them and a big limit in their AMP experience/adoption.

Is there any chance to revisit/rediscuss this change with publishers to better take into account their requirements?

From a tech perspective, we'd need to make a few changes on our side to disable that format as well as communicate it to our publishers that already use it.

[andresilveirah]

Hi @zhouyx thank you for the heads up.

I'm with @jawadst in that one. Since some publishers rely entirely on revenue coming from ads, and those publishers are taking the right path of informing the user about it, it'd be fair to allow them to block users from navigating further without a concrete decision (consent or reject).

I believe, if <amp-consent> enforces the "bottom message" as default, publishers would still be able to implement a "consent all" by adding one extra page before their actual content. In my understanding that is not necessarily better than simply allowing for fullscreen consent messages :)

Regarding the implementation though, our solutions would continue to work with a few tweaks and costumer communication.

[zhouyx]

Add @yoannOgury @PierigOgury as well.

[zhouyx]

Thank you both for the feedback! I do understand that blocking consent dialog is a common pattern (I see that a lot), and I agree with both of you that it should eventually be publishers call.

The two reasons we want to put restrictions on fullScreen are 1. security concern, 2. bad user experience due to flicker UI from initial height to fullscreen. To add on top of that, AMP does support blocking Prompt with overlay: true config (This need to be turned on by publishers in inline config). The difference is that the initial prompt can be blocking, but cannot take the entire screen. (60vh maximum) . We hope that this can satisfy publishers' requirement.

I'd be more than happy to hear more from publishers. As I am not working directly with publishers on collecting user consent, it would be great if you could help us gather some feedback.

[yoannOgury]

Thanks @zhouyx !

I concur with both @jawadst and @andresilveirah . From our experience with publishers, a requirement is often to be able to block the navigation until the user has given an answer to the consent in order to inform the end-user and limit their legal risk regarding the data collection they (or their partners) are using.
But still, the proposition to manage this case, publisher side, with overlay: true should do the trick with enough explanation in our documentation.

Regarding the actual implementation, can you confirm that the intent is to keep the default size to 30vh but allow a configuration up to 60vh ?

[zhouyx]

Hi @yoannOgury, yes I can confirm that 30vh is the default size, but we allow a height range from 10vh to 60vh.

Can I summarize the request here to two 1. FullScreen. 2. Blocking prompt. Based on the discussion we agree that it's OK to allow fullScreen after some sort of user interaction as long as the initial prompt is blocking.

If everyone is OK with the proposal, the AMP team is going to change the behavior with some flag. This would allow enough time for testing and making according changes.

[micajuine-ho]

Hi all, just wanted to follow up with this discussion.

To echo @zhouyx, the main takeaways are as follows:

• Disallow the consent prompt immediately going full screen
• Only allow full screen after the user has interacted with the consent prompt
• This behavior is acceptable as long as the consent prompt is blocking with overlay: true

If there are no objections, we will begin to implement and document the changes. We are expecting there to be minimal changes required on CMP's end (which we will communicate).

[zhouyx]

cc @zewenliang

[micajuine-ho]

Hi all.

Here is the design doc. Work on this project will be tracked here #26432.

The timeline for implementation should be around 2 weeks. All changes will be guarded under a feature flag that you can opt into using so that you can test behavior, etc. The experiment name is amp-consent-restrict-fullscreen.

Once all the changes have landed in production, we will communicate any changes that you need to make (should be minimal, if any). Then after about 2 weeks, we will remove the feature flag.

[MaximePlancke]

Hi @micajuine-ho

Sounds good, thank you!

[micajuine-ho]

Hi all, just an update: code is still out for review, so we are looking to have it finished (still guarded with the experiment flag) in next Tuesday's cut.

[PierigOgury]

@zhouyx our consent notice has been updated, now the fullscreen is displayed on user interaction

[MaximePlancke]

Hi @zhouyx, @micajuine-ho

Thank you for the updates.

We started working on the changes on our side and will let our clients that are using the full screen know about the future changes.

Could you confirm the date of deployment (when the feature flag will be removed)?

Thank you!

[micajuine-ho]

Hi @MaximePlancke, our desired timeline is as follows:

• Turn on Canary flag, which can be tested starting Feb 18th by opting into the Beta/Experimental channel
• Turn on Production flag, which will be in Stable March 3rd

There are no config changes required by CMPs.

[micajuine-ho]

Hi @andresilveirah, wanted to check in and see if you needed anything for this change.

[MaximePlancke]

@micajuine-ho Thank you. Knowing the dates is important to us as some of our clients are displaying a popup in full screen mode on page load. We would have to force a bottom banner position on our side a few days before the deployment to avoid breaking the UI.

[andresilveirah]

@micajuine-ho apologies for the late reply. I see the new changes are in prod (don't ask me how I noticed 😅).

yes I can confirm that 30vh is the default size, but we allow a height range from 10vh to 60vh.

@zhouyx how can one configure the height? I tried to find this info in the docs but no success.

[micajuine-ho]

Hi @andresilveirah

how can one configure the height? I tried to find this info in the docs but no success.

In the "ready" post message sent by your iframe, you can set the initialHeight key to some vh value (eg '30vh').

Take a look at this example.

[andresilveirah]

Wonderful, thank you @micajuine-ho !

I have one more question. Once we enter fullscreen, can we return to the reduced size message? Use case:

1. We show a message at the bottom of the screen
2. The user clicks on a link to see more details/preferences
3. We expand to full-screen
4. The user clicks on a _Cancel_ button to return to the previous screen
5. As a user I'd expect to see the fullscreen part closing and be left with the bottom notice only.

Is there a way to accomplish that?

[hrkhal]

@micajuine-ho / @zhouyx Can the fullScreen API be allowed without user interaction when promptTrigger is equal to action?

https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/0.1/consent-ui.js#L488

When a prompt has been triggered by a user clicking a button with on="tap:consent.prompt" then user intent and interaction has already been demonstrated and thus the fullScreen API should be allowed without further user interaction within the prompt iframe.

There are no quarrels with disallowing the fullScreen API until user interaction when it's for a prompt that was launched automatically on load (promptTrigger === 'load').

This change has hobbled our current user work flow in AMP.

We have a link in the footer in all of our properties that users can click to launch the second layer of our CMP. This contains options to change consent alongside vendor and purposes information. It is information dense, hence why we request fullScreen as soon as it loads and we're only doing this when promptTrigger is equal to action and this has been the case since we first integrated our CMP into amp-consent.

As of now our second layer launches in an iframe that is 30% of the viewport height (as intended by this issue) and that makes for a poor user experience.

It does not make for great user experience for us to now add in a new intermediary layer to our CMP so that the user can just click a link/button for the sole purpose of granting us access to the fullScreen API before actually displaying the content they wanted. The same is true for adding in an "expand" button similar to the amp-iframe overflow route.

[micajuine-ho]

Is there a way to accomplish that?

@andresilveirah Hmm.. I do not think this functionality is currently supported. I believe we only support hiding the message fully. Is this something that you require?

Can the fullScreen API be allowed without user interaction when promptTrigger is equal to action?

@hrkhal Thanks for your input. This sounds reasonable to me. To reiterate your need: there's a footer at the bottom of your page, and by clicking it, you send the prompt signal to amp-consent, with promptTrigger: action, and the iframe should be allowed to be fullscreen. Does that sound right?

[hrkhal]

@micajuine-ho That is correct, in that specific situation we should be able to use the fullScreen API without any need for user interaction.

[micajuine-ho]

@hrkhal Ok, thanks. We will see how we can prioritize this.

[ptrickney]

@micajuine-ho Has there been any movement on the use case suggested by @hrkhal as we are running into the same problem.

[micajuine-ho]

Hi @ptrickney & @hrkhal, thank you for the reminder. I haven't had any free cycles recently to take on this work. I will look to get something out soon. Will update.

[hrkhal]

@micajuine-ho Appreciated. Movement sooner than later would be ideal, we've a new site launching soon that will also face the same issue.

[micajuine-ho]

Hi @hrkhal & @ptrickney. I have created a new issue for amp-consent fullscreen change. We can continue the discussion there.