Adobe captivate 2019 popup blocker message

[debbie.griffin]

We have just upgraded to Adobe Captivate 2019 and the published courses on our LMS are getting this error message when users try to access links. I have looked throught the community and this has been raised before but the last response was 2019, so I was wondering is there is an update. Thanks 

[Paul Wilson CTDP]

My suggestion would be to talk to your IT department and make them aware of the issue. This is a security setting in either the deployment of browsers or perhaps a setting that is imposed by your LMS.

[W5DB9]

Hi Paul and others who encouter this problem,

In reply to Paul: I disagree with the answer that this is a security setting in the deployment or browser.

I encountered this problem myself today when uploading some new courses for a new customer.

The problem is in the CPM.js file that is generated. I was in the lucky circumstances that there was another course which was working well. I compared the way the link was opened:

The course which is showing the popup has the following code

cp.openURL(\'https://www.mycustomer.com/directory/subdirectory/file.xxx?module=I1\',\'_parent\')

The other course opened the url with: 

'window.top.location.href = \'https://mycustomer.com/directory/subdirectory/file.xxx?module=LH5\'

Once I replaced the cp.openURL with the "window.top.location.href" way of opening, the problem was solved. The popupblocker message disappeared.

The problem is: my customer can't find the way to change this in Captivate. But this makes clear it can be solved by the way Captivate is generating the html/js code.

I hope this helps to analyse and solve the problem.

[Paul Wilson CTDP]

That's great. Thanks for sharing. I wonder how the difference was generated in the first place so as to avoid this issue in the future.

[RodWard]

If the latest builds of Captivate are using this code in the CPM.js file then I would say there must have beeed some issue with the older code approach.  Perhaps the older code did not work as well with mobiles or some new update in web browsers.

Only the person in the Adobe Captivate development team that made this change would be able to give the reason, and they rarely ever chime in here with that kind of information.

The CPM.js file is generated from scratch each time you publish to HTML5.  It doesn't really use a starter template file like the index.html file does.  So I cannot see anywhere that you can make a change to Captivate's properties or to any specific file in the Captivate installation directory where you could influence this behaviour.

[kdmemory]

Hm, the OP debbie.griffin might have left the conversation, but for everyone else and in particular WSDB9 I'll be a bit picky now:

The two CPM.js methods to open up an URL are very different and that is not because they are distinguished through the use of openURL respectively window.top.location.href - it it the use of _parent as opposed to _top that makes them so different.

cp.openURL(\'https://www.mycustomer.com/directory/subdirectory/file.xxx?module=I1\',\'_parent\')

'window.top.location.href = \'https://mycustomer.com/directory/subdirectory/file.xxx?module=LH5\'

According to W3 Schools there are four HTML link target attributes:

1. _self - Default. Opens the document in the same window/tab as it was clicked (Cp interface: Current)
2. _blank - Opens the document in a new window or tab (Cp interface: New)
3. _parent - Opens the document in the parent frame (Cp interface: Parent)
4. _top - Opens the document in the full body of the window (cp interface: Top)

_parent or _top makes a big difference. Supposed there is no _parent window, because there is no subordinate window (i.e. iFrame) in which the link is clicked, then the browser with activated popup-blocker might be triggered into an attempt to create such a _parent window on the fly which somewhat comes close to a window.open() method. That of course triggers the popup-blocker. On the contrary with _top this problem doesn't arise.

Just saying

Klaus

[Lilybiri]

@kdmemory  Interesting! What could be the reason that they choose _parent over _top ? Any guess? 

[W5DB9]

Hi Klaus,

Thanks for pointing this out. I'll ask my customer to generate a course with the _top option to see if this solves the problem. Since both courses currently have the option '_parent', I didn't think of this. It's worth giving it a try.

[kdmemory]

Reply to both: @Lilybiri  and @W5DB9 

It all depends on the "web window structure" which of course I do not know. Hence I'm only following a hunch with the "close to a window.open method" suggestion. 

If the web window hierarchy in the browser is like this

[ Parent window ]

             |

             [ iFrame window ] and here is the clickable link to be applied in _parent

then _parent makes sense if you want to load a new document into the [parent] of [iFrame]. [iFrame] of course would disappear. But - because the link in question (triggering the popup-blocker message) is in a Captivate HTML5 webapp, I consider it as very unlikely that someone wants a user to open a link and make in the process the Captivate webapp disappear. Also it is unlikely that the Captivate webapp resides in an iFrame, mostly it is the other way around. Like an OAM HTML5 animation or a Web Object (i.e. PDF) inserted into a Cp module, those reside in iFrames. But who knows - as I said I don't know the web window hierarchy in the particular case.
When you use _top and actually there isn't a hierarchy of windows because everything is in just one main window, that doesn't matter so much. Because _top is _top. When there is only one window then this is _top. In practise a link to _top in this situation is obsolete, but doesn't do any harm because it's interpreted as _self.

I use in 99% of all links in Captivate anyway _blank. Simply because I want the Captivate module being kept open in a browser tab and the link to some additional learning stuff opened in an extra tab. So that a user can come back to the module. In so far, _parent or _top, from a Captivate module perspective both seem a little odd to me.

Hope this isn't too fuzzy

Klaus

[kdmemory]

One thought to add: In an LMS a Captivate module is indeed often running in an iFrame. Nevertheless links to additional materials via _parent or _top still remain odd.

[Lilybiri]

I had some suspicion of what you explained very clearly. However on my blog I do use an iFrame if I want to insert an example Captivate tutorial. Similar situation as within most LMSs (as you pointed out).  I also prefer to open a new tab, but some clients underestimate (? or know) their learners and want to avoid having to explain how to use multiple tabs in a browser.