Skip to content

Instantly share code, notes, and snippets.

@shaun-stripe

shaun-stripe/sfsvc.md

Last active January 18, 2017 17:37
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save shaun-stripe/cdb8203aeef223d5ffe513dd84702001 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save shaun-stripe/cdb8203aeef223d5ffe513dd84702001 to your computer and use it in GitHub Desktop.
Download ZIP
Safari View Controller - `window.open` bug
Raw
sfsvc.md

Problem

window.open behaves differently inside the following iOS browsers:

  • Mobile Safari - window.open opens a new tab
  • Safari View Controller - window.open redirects current page

Consequences

  • Non-standard: Safari View Controller adds a non-standard step to the WHATWG spec, by overriding the desired target browser context to "_self", rather than going through the standard sandboxing for restricting tab navigation, or simply returning null as described at the end of item 4.
  • Unpredictable: Since it is nonstandard, it is impossible to know beforehand what window.open will do.
  • Flow-breaking: The aforementioned iOS browsers are indistinguishable in code, meaning existing flows using window.open must be removed when Mobile Safari is detected, even though Safari View Controller is the offender.

Solution:

Google's "Chrome Custom Tabs" webview component has the same use-case as Safari View Controller for hiding the tab bar, but elegantly preserves tab flows-- by making the back button navigate the user to the previous tab (i.e. window.opener) when the current tab cannot go back any further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment