2 ms·

> And I have to say, I would be pretty irritated if every site demanded to open in my main browser. Many if not most links I tap are quick one and dones I’d pre

by derefr 4y ago

> And I have to say, I would be pretty irritated if every site demanded to open in my main browser. Many if not most links I tap are quick one and dones I’d prefer to not clutter up my tabs. Sure, but why does that have to imply that you get "per-app cookies, storage, etc"? What I want is a Safari tab as a modal temporarily overlaying the app. It is a tab of my regular web browser, with access to my regular web-browsing profile, and without the app having access to it any more than the app would have access to a tab it caused to open in regular Safari — except that 1. it doesn't show up in Safari's tabs, only as a window "stuck on top of" the particular app; and 2. the window knows what it's displaying is ephemeral, so it's easy to close it and return to the app by just swiping it away. (A lot like the Safari long-press preview modal, actually.) Basically, SFSafariViewController should work less like an isolated browsing session, and more like the way OS file-pickers work in desktop OSes — where the UI-as-client makes a synchronous request to another app-as-IPC-server to pop a window, and then blocks until that window goes away.

kitsunesoba 4y ago
I do agree that SFSafariViewController should use the newer style of sheet that can be pulled down on to be be dismissed. It makes more sense than the current navigation stack style presentation, and the extra context of the spawning app being visible around the top edges under the sheet would be helpful in app switcher. The reason SFSafariViewController switched to per-app containers is because the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes, dampening the benefits of it being out-of-process and isolated from the spawning application. I suppose it might be nice to have a setting to toggle this behavior, but it'd need to have disclaimers with red text next to it to prevent advertisers, etc social engineering users into toggling modes.
- derefr 4y ago
  > the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes How did this work, exactly? Was the app able to observe/interact with the SFSafariViewController in any way? In my mind, the SFSafariViewController should literally "be" a Safari tab, in the sense that once it's open, the spawning app has no more connection to it than it would have to a tab in Safari itself which it caused to open; other than the fact that this tab would be 1. modal on top of the app, like a sheet; and 2. the app would be told when you closed this sheet, so that it could pause anything actively going on "underneath" the sheet until it was closed. (And, to be clear, the Safari tab would be running _in_ Safari, and just composited onto the sheet, rather than running inside the app process in any way. This is how OS file-pickers et al work, which is what I was trying to get across with that comparison.) The closest analogy would actually be within the browser itself: one browser tab using JS window.open(target=_blank, opener=false) to open another browser tab within the same browsing profile, where the new tab loads a page from a different origin; where when that new tab gets focused, the original tab gets obscured, and so the page it has loaded is given a visibilityStateChanged event; followed by another one when you close the new tab and the original tab comes back to focus.
  - kitsunesoba 4y ago
    No, apps didn’t have any more ability to observe/interact with the view controller than they do now. SFSafariViewController has always been a separate process spawned by the OS, not the app. It was for all intents and purposes a “real” Safari tab the app couldn’t touch. The way tracking was happening is by apps putting an identifier in the URL, which JavaScript put into the linked page by the authors (social media widgets, Google Analytics, etc) would pick up on the cookies and other identifiers in the SFSafariViewController session carried over from “real” Safari and then tie those with the URL identifier. Boom, Twitter, etc have a nicely fleshed out tracking/advertising profile to attribute to that clicked link, even though they didn’t use a custom webview. This is exactly how tracking works with regular browser tabs, too. The only way to mitigate it is to give each app its own separate Safari container for SFSafariViewController to run in and encourage devs to use SFSafariViewController instead of the full browser.
- alickz 4y ago
  >I do agree that SFSafariViewController should use the newer style of sheet that can be pulled down on to be be dismissed. SFSafariViewController can be presented in the newer sheet modal style, it would seem Twitter specifically chose not to in this case.
manmal 4y ago
What you describe can be achieved by the app opening the page via the system browser. I don’t see any benefit of using a tab in the app instead. The swipe-left gesture at the bottom makes app switching super fast, making rapid switching between app and page a better experience than dragging and re-opening.

by derefr 4y ago

kitsunesoba 4y ago

I do agree that SFSafariViewController should use the newer style of sheet that can be pulled down on to be be dismissed. It makes more sense than the current navigation stack style presentation, and the extra context of the spawning app being visible around the top edges under the sheet would be helpful in app switcher. The reason SFSafariViewController switched to per-app containers is because the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes, dampening the benefits of it being out-of-process and isolated from the spawning application. I suppose it might be nice to have a setting to toggle this behavior, but it'd need to have disclaimers with red text next to it to prevent advertisers, etc social engineering users into toggling modes.

derefr 4y ago
> the older behavior in iOS 9/10 where it used the same environment as the browser proper was being rampantly abused for advertising/tracking purposes How did this work, exactly? Was the app able to observe/interact with the SFSafariViewController in any way? In my mind, the SFSafariViewController should literally "be" a Safari tab, in the sense that once it's open, the spawning app has no more connection to it than it would have to a tab in Safari itself which it caused to open; other than the fact that this tab would be 1. modal on top of the app, like a sheet; and 2. the app would be told when you closed this sheet, so that it could pause anything actively going on "underneath" the sheet until it was closed. (And, to be clear, the Safari tab would be running _in_ Safari, and just composited onto the sheet, rather than running inside the app process in any way. This is how OS file-pickers et al work, which is what I was trying to get across with that comparison.) The closest analogy would actually be within the browser itself: one browser tab using JS window.open(target=_blank, opener=false) to open another browser tab within the same browsing profile, where the new tab loads a page from a different origin; where when that new tab gets focused, the original tab gets obscured, and so the page it has loaded is given a visibilityStateChanged event; followed by another one when you close the new tab and the original tab comes back to focus.
- kitsunesoba 4y ago
  No, apps didn’t have any more ability to observe/interact with the view controller than they do now. SFSafariViewController has always been a separate process spawned by the OS, not the app. It was for all intents and purposes a “real” Safari tab the app couldn’t touch. The way tracking was happening is by apps putting an identifier in the URL, which JavaScript put into the linked page by the authors (social media widgets, Google Analytics, etc) would pick up on the cookies and other identifiers in the SFSafariViewController session carried over from “real” Safari and then tie those with the URL identifier. Boom, Twitter, etc have a nicely fleshed out tracking/advertising profile to attribute to that clicked link, even though they didn’t use a custom webview. This is exactly how tracking works with regular browser tabs, too. The only way to mitigate it is to give each app its own separate Safari container for SFSafariViewController to run in and encourage devs to use SFSafariViewController instead of the full browser.
alickz 4y ago
>I do agree that SFSafariViewController should use the newer style of sheet that can be pulled down on to be be dismissed. SFSafariViewController can be presented in the newer sheet modal style, it would seem Twitter specifically chose not to in this case.

manmal 4y ago

What you describe can be achieved by the app opening the page via the system browser. I don’t see any benefit of using a tab in the app instead. The swipe-left gesture at the bottom makes app switching super fast, making rapid switching between app and page a better experience than dragging and re-opening.