Anchor tags do not function on page once a new Container is created.

[probityrules]

Anchor tags no longer work once a Container is created. It seems that the Container is somehow interrupting the "click" event handling on <a href=""> tags. This isn't happening on all iOS / browser combinations, but has been found to consistently occur on the following combos:

• Safari and Chrome on iPad Mini iOS 8.3
• Safari on iPhone 5s iOS 9.2
• Safari on iPhone 6 iOS 9
• Chrome on iPad Mini iOS 9.0

The issue can be tested on the Dinosaur Train home page on Ernie. (Soup's home page bypasses the SR Container using a regular iframe and does not exhibit the issue.) Let the page load (phones need to be in horizontal orientation so the train loads), and then tap any of the navigation buttons or the header logos. Note that the element is selected, but the link is not followed on release.

[probityrules]

Update: I just tried Chrome and Safari on OS X and the same issue occurs, so it's not limited to mobile browsers.

[bigtimebuddy]

Yup, this is the offending code. A listener is added to document click and focus events to automatically keep focus on the iframe contents (as to not lose keyboard or interactive focus). Right now, this is an opt-out functionality. If you some DOM element that you don't want to trigger an auto-focus to the iframe, you can add the class pause-on-focus. I don't believe this is the best approach and auto-focus should probably be opt-in or at least not return false. Overall, the Container focus could be overhauled and improved. Welcome your thoughts @probityrules, or if you want to take a pass at the FocusPlugin.

[probityrules]

Ah, I see. It didn't occur to me that that's what "pause-on-focus" would do, although I did see it in the docs. I could see that working when there's a defined, limited number of links, but it might get a bit messy to maintain if there are more than a few or if any links are dynamically created.

What are the goals of the FocusPlugin? The two I see are to ensure keyboard events are passed to the app and whether to pause the app. Are there other desired effects tied to its behavior? Out of curiosity, is there currently any way to disable it altogether?

[bigtimebuddy]

The main purpose of the FocusPlugin is manage the pause/unpaused state of the Application depending on what's happening in the parent and iframe windows. For instance, if you navigate to a new tab, or minimize the browser, the FocusPlugin listens for these changes and makes sure the SpringRoll Application respects the current browser state (hidden vs. showing). Here's where it gets tricky: if you're focused on the Container's document and then click on the iframe, the Container's document gets a blur event and loses focus. This plugin keep track of both of the iframe and the Container's document and adds in a little cross-browser workarounds to handle managing this focus. The document click stuff you mentioned before was to always persist the focus to the iframe, but this doesn't work for all situations.

FocusPlugin a complicated piece of functionality because of the iframe/parent relationship isn't an easy one to detect focus/blur in a clear way across all browsers.

There is currently not a public method/option for disabling this functionality.

I want an easier way to accomplish persistent focus, detection of the browser state, and the ability to pause the Application if certain items (textarea, select, input, etc) are focused (either as opt-in or opt-out).