clickTrackingElement disables <Icon> click behavior in VAST ads (HTML5 SDK)

[Elson Yeh]

Hi IMA team,

We’re using the IMA HTML5 SDK, and we needed to customize the clickable area in our player, so we provided a third parameter — clickTrackingElement — when creating a new AdDisplayContainer.

Everything worked perfectly until we discovered an unexpected issue:
When clickTrackingElement is provided, the <Icon> element in the VAST response becomes unclickable.

To be more specific — normally, clicking the <Icon> should navigate to the URL specified in <IconClickThrough>.
However, after setting clickTrackingElement, clicking the icon instead triggers a pause ad action.

Is there any recommended way to handle this issue?

Thank you!

[IMA SDK]

Hi,

Thank you for reaching out to the IMA SDK Support team.

Could you please share the following details via reply to author option? This will help us to investigate further.

• VAST tag reproducing the issue
• SDK version

Thanks,
 

IMA SDK Team

Feedback
How was our support today?

               
[2025-10-23 14:55:03Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vRaV8:ref" (ADR-00336331)

[Elson Yeh]

Hi IMA SDK Team,

Here are the requested details:

VAST tag:
https://storage.googleapis.com/interactive-media-ads/ad-tags/ima_wta_sample_vast_4_2.xml

SDK version:
v3.728.0

I’ve also uploaded a sample code based on the official IMA HTML5 SDK sample with a few small modifications:

1. Added a custom button to use as the clickTrackingElement.

2. Hardcoded the above VAST xml (which includes an <Icon>) as the ad to be played.

Please test it on a mobile device.
When the ad plays and the icon appears, try tapping the icon — the ad will pause instead of navigating to the URL defined in <IconClickThrough>.

[IMA SDK]

 Hi,

 

Thank you for sharing the details.

I will check with the team and get back to you shortly.

Thanks,
 

IMA SDK Team

Feedback
How was our support today?

               

[2025-10-27 15:31:56Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vRaV8:ref" (ADR-00336331)

[IMA SDK]

Hi,

 

Thank you for sharing the details.

According to the IMA SDK for HTML5 documentation, clickTrackingElement specifies an alternative element to handle video ad clicks. If you set this to null, the SDK automatically manages click behavior. Even if you provide a custom click element, the SDK will only use it for non-AdSense or non-AdX ads on devices that don’t support overlaying UI elements on top of a video player (for example, iPhone or pre-4.0 Android).

Thanks,
 

IMA SDK Team

Feedback
How was our support today?

               

[2025-10-29 15:09:11Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vRaV8:ref" (ADR-00336331)

[Elson Yeh]

Hi,

I understand the limitations of clickTrackingElement. However, the issue I’m reporting is that when clickTrackingElement is provided to AdDisplayContainer, the <Icon> elements defined in the VAST become unclickable — they no longer navigate to their <IconClickThrough> URLs.

For example, in the screenshot below, the icons in the lower-left and upper-right corners can’t be clicked to open their links.

To make the behavior easier to compare, I’ve created a demo page with two players:

• The top player provides a clickTrackingElement to AdDisplayContainer.

• The bottom player does not.

Please test it on a mobile Android device (I used a Samsung Galaxy A32, Android 11).
You’ll see that in the top player, tapping the icon only pauses the ad instead of navigating to the linked page, while in the bottom player, the icon works as expected.

If, as the documentation states, the restriction only applies to certain devices (e.g., pre-4.0 Android or iPhone), then the expected behavior on other devices like mine should still allow normal icon click-through actions.

IMA SDK 在 2025年10月29日 星期三晚上11:09:25 [UTC+8] 的信中寫道：

[IMA SDK]

Hi, 

 

This doesn't look like an IMA SDK bug to me. As the AdDisplayContainer documentation warns, this custom element is intercepting the click event intended for the VAST Icon, causing the unexpected pause behavior.

 

I would suggest the potential fix - Z-index correction by below approach.

• Find the physical element the SDK created for the VAST Icon.
• Force this element to the top of the DOM stacking order.
• This ensures that when a user clicks the Icon, the click hits the Icon's handler first (triggering the <IconClickThrough> link) instead of being intercepted by the custom adClickThrough overlay.

Thanks,
 

IMA SDK Team

Feedback
How was our support today?

               

[2025-11-07 22:48:08Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vRaV8:ref" (ADR-00336331)

[Elson Yeh]

Hi,

Thanks for the suggestion.

Unfortunately, the proposed z-index fix isn’t feasible in our setup. All ad-related UI (countdown, skip button, clickthrough overlay, and the VAST <Icon>) is rendered inside an IMA-managed, cross-origin iframe. Due to browser security constraints, we can’t access or restyle elements within that iframe—so we can’t “force the Icon element to the top of the stacking order.”

Conceptually, our understanding is that the custom clickTrackingElement should only handle ad clickthroughs (i.e., <ClickThrough>). In our case, once we pass a clickTrackingElement to AdDisplayContainer, taps on the VAST <Icon> no longer trigger the <IconClickThrough>; instead, the tap pauses the ad. Intercepting the general clickthrough should not disable an icon-specific clickthrough, especially on devices that do support overlay UI.

Given the iframe constraint, could you advise on a supported way to keep VAST <Icon> clicks working while using clickTrackingElement? For example, is there an SDK option or recommended pattern that preserves <IconClickThrough> priority over the generic click overlay? If this limitation is expected, can you confirm so we can adjust our implementation accordingly?

Thanks again for your help.

IMA SDK 在 2025年11月8日 星期六清晨6:48:17 [UTC+8] 的信中寫道：

[IMA SDK]

Hi, 

Thanks for getting back to us. 

From the SDK side, there is no recommended way to handle the clickTrackingElement, but you can potentially use JavaScript to manually set the VAST Icon's layer to the highest priority, ensuring its dedicated click handler is triggered before the custom click element can intercept the event.

Thanks,
 

IMA SDK Team

Feedback
How was our support today?

               

[2025-11-10 16:05:10Z GMT] This message is in relation to case "ref:!00D1U01174p.!500Ht01vRaV8:ref" (ADR-00336331)

[Elson Yeh]

Hi,

As mentioned earlier, the VAST icon elements are created inside an iframe served from the domain imasdk.googleapis.com.
Due to the browser’s Same-Origin Policy, it’s not possible for JavaScript in the parent page to adjust the icon’s layer or modify any elements within that iframe.

Additionally, I’ve observed that the Skip Ad button continues to function correctly, which suggests that this issue is not caused by z-index or layering.
(See Figure 1)

Looking further, I monitored the IMA SDK’s postMessage events. When the VAST icon is clicked, a "videoIconClicked" message is indeed sent — indicating that the click on the icon is recognized.
(See Figure 2)

This implies that the problem isn’t about the click event being blocked, but rather that the clickthrough navigation doesn’t occur afterward.

While tracing the code, I found a possible clue:
When a custom clickTrackingElement is provided, a variable named disableClickThrough inside ima3.js is set to true.
(See Figure 3)

Later, in bridge3.731.0_en.html, when the VAST icon is clicked, the logic checks whether disableClickThrough is true before deciding whether to open the URL.
(See Figure 4)

From my understanding of the VAST specification, <VideoClicks>/<ClickThrough> and <Icons>/<IconClickThrough> are independent behaviors with no defined dependency between them.
(See Figure 5)

Therefore, it seems that the IMA SDK’s internal disableClickThrough flag — which is meant to control general video clickthroughs — also inadvertently suppresses the <IconClickThrough> behavior because both share the same click-handling logic path.

I believe this is a logical design oversight in the SDK, and I hope the IMA SDK team can consider fixing it in a future release.
Thank you.

IMA SDK 在 2025年11月11日 星期二凌晨12:05:21 [UTC+8] 的信中寫道：