IMA SDK takes the keyboard focus on mouse clicks

[Ray Blaak]

Hi. I am using the IMA SDK, things are working fine for the most part, my test ads are playing, etc.

Our app uses key controls to toggle play/pause and to FF/REW in the video, e.g. space, and move left right keys. The keyboard focus is set to the body of our app web page.

When I click on an ad video, my click handling works, but the key controls no longer work. This is because the document.activeElement is now the IMA iframe itself, e.g.

<iframe src="http://imasdk.googleapis.com/js/core/bridge3.486.2_en.html#goog_1118972256" allowfullscreen="" allow="autoplay;trust-token-redemption;attribution-reporting;" id="goog_1118972256" width="1920" height="1080" style="border: 0px; opacity: 1; margin: 0px; padding: 0px; position: relative; color-scheme: light;"></iframe>

You can try my sample test app here. Click "play" to start the video playback with a preroll, hitting spacebar to toggle play pause. After clicking on the video to also toggle play/pause, hitting spacebar no longer works.

Correct behaviour should preserve the keyboard focus, so as not to break the web site / app's key event processing.

My work around was to overlay a div overtop of the ad container, so as to intercept mouse clicks to reset the focus back to the app's focus:

setTimeout(() => window.focus(), 0);

[IMA SDK]

Hi Ray,

 

Thank you for reaching out to us.

 

I have tested the behavior on your shared test app, and I can see that the spacebar to toggle play/pause will not work once you have click on the video content itself, but if you click on the play/pause button, the spacebar will continue to work for toggling the play/pause functionality as well. Could you confirm if this is the behavior you are reporting? If so, I believe this is an intended behavior, as this is also the behavior you will encounter on our VSI.

 

So, I think what is happening here, when you click on the video content, the spacebar is not working because it is not triggering your functionality for play/pause. I believe that this is not an issue with the SDK itself but you may find this document guide helpful, but instead of tracking on mouse click, you should track for when the spacebar is press and put your code for play/pause functionality when it catches it.

Regards,

Michael Angelo Legaspi IMA SDK Team

ref:_00D1U1174p._5004Q2QF4GF:ref

[Ray Blaak]

Hi Micheal, thanks for your reply.

The keystrokes are processed in a central place in the app code (in main.js as it happens), due to a key event listener attached to the body. 

Once I click on the video content, that key event listener stops receiving keyboard events, and I see that the IMA iframe has the keyboard focus at this time, as per document.activeElement.

This "theft" of keyboard focus is the issue I am reporting, since it causes the existing key event processing to no longer work.

Clicking on the play/pause button has a separate mouse handler that toggles play/pause, and supposedly stops mouse event propagation, so I am not sure why clicking there restores the keyboard focus. It seems like the IMA event handlers might restore that? But I view that as a separate issue, since the loss of app key event handler is still occurring regardless.

[Ray Blaak]

Hmm. One clue might be due to the fact that the background mouse click is being field by the page div itself, i.e. an ancestor of the IMA iframe.

Whereas, clicking on the control bar's play/pause button is a div overlaying the video, and the IMA iframe, i.e. a sibling of the iframe.

[IMA SDK]

Hi Ray,

 

Thank you for that additional information. Let me raise this to the rest of our team to get their feedbacks on this as well. We will provide more information once they have responded.

Regards,

[IMA SDK]

Hi Ray,

 

Hope you are doing well.

 

Our team has responded to us with the following verbatim:

 

"I better solution may be to look for the IMA CLICK event and return window focus then.

 

During reproduction of the issue, I noticed that clicking on the ad did not trigger ad click-thru. Is this intentional from the publisher?"

 

Let me hear your feedback on this.

Regards,

[Ray Blaak]

Hi Michael, my comments:

> I better solution may be to look for the IMA CLICK event and return window focus then.

Do you mean fixing the focus with a window.focus() call during the processing of AdEvent.Type.CLICK ? I can certainly try that as a better work around.

But, I guess my question / observation is that the IMA SDK should not be changing the browser's active focus in the first place, since that changes the web page's key event processing behaviour.

> During reproduction of the issue, I noticed that clicking on the ad did not trigger ad click-thru. Is this intentional from the publisher?"

For this app, yes that is the case, since these are just sample ads, used only for testing of ad playback.

[IMA SDK]

Hi Ray,

 

Thank you for confirmation.

 

> Do you mean fixing the focus with a window.focus() call during the processing of AdEvent.Type.CLICK ? I can certainly try that as a better work around.

 

Yes you are correct. Have you tried this recommendation? Let me know your feedback on the result, so I can raise again any follow up question along with your main observation to the rest of our team.

Regards,

[Ray Blaak]

Yes, resetting the window.focus() works fine as a work around. In fact, I can also do it in the background click handler of the page underneath the ad as well.

So, it is good that I have a work around, but I am reporting this issue since I believe the IMA SDK should not change the keyboard focus in the course of its mouse event processing.

Or it is does, it should restore it when complete.

[IMA SDK]

Hi Ray,

 

Thank you for confirming that the recommendation works fine. I will share to the rest of the team your observation and feedback and we will get back to you as soon as possible.

Regards,

[IMA SDK]

Hi Ray,

 

Hope you are doing well.

 

Our team responded back to us and allow me to share it with you.

 

Our team believes this is working as intended. For web players, clicks are expected to focus on the click's context. In addition, changing this behavior now would likely affect other publishers who are expecting IMA focus to work as it currently is so it may not be feasible.

Let us know should you have any other concern.

Regards,