Apparent Bug Centering on Actions That Open URLs in a Safari View Controller

Hey all, so… I wrote an action that opens the Drafts Actions Directory in an in-app Safari View Controller instead of booting the user out to Safari. The problem is that it seems like if the Safari View Controller isn’t exited gracefully (i.e., by tapping “Done”)—as would happen when tapping the “Install” button on an action in the Directory (which kicks the user back out to the main Drafts editor view)—then there’s a long (and seemingly variable) period after the action has, by all appearances, ended during which any attempt to run any new actions fails or is severely delayed (with a perpetually turning activity indicator circle). I surmise that this is because the first action was never instructed to terminate (and only does after a timeout of some sort), but I don’t know for sure. It’s also quite possible that I’m doing something wrong (though I did try various means of exiting the script and/or action from different points within the script as well as varying whether the Safari View Controller is launched directly via the script or via a separate Open URL step—with apparently no effect).

Is there any way to instruct the action to terminate immediately after launching the Safari View Controller (yet have the browser remain open) or any other way of solving this issue? (Ideally, Drafts would handle this more gracefully regardless, showing the Install Action UI on top of Safari View Controller, if possible, or, if not, detecting that the installation was triggered from within a Safari View Controller and immediately after the action is installed shuttling the user back over to the still-in-memory Safari view; in addition to nullifying this issue, it would also be far more convenient, obviating the need to re-run the Directory action over and over again in order to install multiple actions from the Directory.)

Thanks!

That’s a pretty edgy edge case you’ve come across. Generally speaking I don’t recommend using URLs that open Drafts from inside of Drafts - like installing an action would do.

I’ll do a pass at this to see if I can resolve it more gracefully, but there are some potential problems. The best way to resolve may actually just be to through an error and not resolve the the “drafts://” URLs from inside SVC in the app - which would, of course, break the functionality you are going for.

You are left with some questions otherwise as to what the “right” way to resolve this stalemate is - should the action be allow to continue? (Maybe assigning tags and filing the draft?), or should be be considered cancelled and exited?

Clearly neither is happening now, which is problematic.