Skip to content

Instantly share code, notes, and snippets.

@jamesreggio
Last active August 17, 2018 05:32
Show Gist options
  • Save jamesreggio/98d6846e4b7554f83c2d to your computer and use it in GitHub Desktop.
Save jamesreggio/98d6846e4b7554f83c2d to your computer and use it in GitHub Desktop.
Summary of bugs in SFSafariViewController affecting adoption within the Twitter iOS client

In the process of evaluating the suitability of SFSafariViewController (SFSVC) for use within the Twitter iOS client, I encountered a number of bugs with differing severities, all of which I filed as Radars in Apple's bug reporting tool. Here is my attempt to holistically document their impact on our ability to adopt SFSafariViewController as a replacement for our existing WebViews.

Highest Severity

The fundamental blocker is Radar #23706636, wherein a crash in the remote SFSVC process will cause the host app (i.e., Twitter) to crash without any notification. This is a gap in the sandbox provided by SFSVC, and makes the host app susceptible to Denial of Service (DOS) attacks wherein attackers can force crashes by posting links to pages that exploit known browser bugs.

Radar #23706923 is a concrete manifestation of this problem, wherein a memory leak during resizing of animated GIFs will ultimately exhaust the memory available to the SFSVC process and result in a crash of the host app.

Realistically, DOS attacks are not likely; however, the largest concern is that we have zero insight into crashes within SFSVC (and limited protection from them). The existing WKWebView implementation will render a blank screen if the remote process crashes, allowing the user to continue using the host app; thus, SFSVC would be a regression.

Moderate Severity

SFSVC has issues with contentInsets when the keyboard is visible (Radar #23706138) and when presented in landscape mode (Radar #23706265). Incorrect contentInsets makes it impossible to reach content near the bottom of the webpage.

Normally, I would classify these bugs as low severity, since they appear to be mainly an inconvenience. However, we experienced a similar contentInset bug with the Twitter implementation of WKWebView and I found over five JIRA tickets filed throughout the company which attempted to understand and work around the bug. (In one particular case, it was impacting the revenue of an advertiser because the button to submit a form was unreachable at the bottom of the webpage.)

Low Severity

There are a number of oft-reported inconveniences affecting the SFSVC user experience. Radar #23705421 states that a Back to [Host App] link fails to appear in the iOS status bar when navigation occurs from SFSVC to another app. (This may negatively impact time-in-app due to the inconvenience of returning.) Furthermore, SFSVC doesn't activate Universal Links by default (Radar #23612919), which means that custom schemes remain the only reliable way of deeplinking between the web and native apps. Though I've listed these as low severity, improving the deeplinking and multitasking experiences have been recent priorities at Twitter, and probably matter more to us than other app developers.

Radar #23557272 states that SFSVC may render as a blank canvas for a split-second upon initial use, and Radar #23557171 states that SFSVC will render incorrectly when a in-call status bar appears (i.e., the large green or blue bar indicating an active call or tethering session). These bugs show a distinct lack of polish, which will be attributed by consumers to Twitter.

Finally, SFSVC does not provide a means to exclude the system Twitter activity from its share sheet (Radar #23503333), meaning that the Twitter app is unable to provide a first-party/in-app experience for tweeting links from SFSVC without being redundant.

Accessibility

It's difficult to asses the severity of accessibility bugs, so I've separated them out. Fundamentally, Radar #22492329 (which was filed externally) is a blocker for use with VoiceOver, since it claims that VoiceOver will cease to function on certain pages. I wasn't able to reproduce this problem, but I did reproduce the strange console logging that they described (Radar #23705345), which leads me to think that the original bug is still present and that SFSVC is unstable with VoiceOver active.

Furthermore, SFSVC does not respect the universal dismiss gesture (a two-finger 'Z' shape) as filed in Radar #23420704.

Feature Requests

My colleague, Nolan O'Brien, filed a series of feature requests (Radar #21349835) in June 2015, which predominantly concerned insight into the timing and success of the initial page load. (This is important to advertisers for conversion tracking, as well as helpful for understanding user behavior around organic content.) Apple added a callback to the SFSafariViewControllerDelegate to indicate the completion of the initial page load, but this is still exceedingly coarse feedback, because it fires upon the first window.load event, which can fire significantly after a page has become interactive. It also provides no insight into the various timing components of the load, or the redirects encountered along the way, which have been important for Twitter as we've sought to reduce the number of end-user redirects.

Tooling

I built a simple HTTP service and iOS app to test and reproduce these issues. Many of the Radars refer to this app in the repro steps.

@herrernst
Copy link

Did some of those bugs get fixed?

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