We need a "close" action for killing an app in a trust prompt

[Ken VanDine]

The original designs for trust prompts included a close action in the header to close apps that were opened in a trust session. This is particularly important when apps might not behave well or hang, there is no way out. The close action is like a back button to take you back out of the app.

We're close to landing trust session support in content-hub, where we'll open source apps for content picking in a trust prompt. We've found apps that have a tendency to hang, leaving the user no way out besides killing both the source and destination apps. Clearly those apps need some fixing, but we need to give the user an easy way out.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michał Sawicz (saviq)]

The problem there is that we can't rely on what the app draws, we need to carefully design how this works.

Some prompts are full-screen, others just show a dialog in the center of the screen and darken the background.

One idea just came to mind is that, since the dialog is modal, we could treat it as a layer in front of the parent app, and clicking the close button anywhere in the shell, or swiping away in the switcher, would just get rid of the visible layer (so the prompt), not the whole tree.

[Michał Sawicz (saviq)]

The above obviously only makes sense for staged mode, and maybe client-side-decorated dialogs. When it's a server-side decorated one, it will have its own close button in the title bar and the problem is gone.

[Matthew Paul Thomas (mpt)]

As far as I know, “the original designs for trust prompts” are what I specified in July 2013. <https://wiki.ubuntu.com/SecurityPermissions?action=recall&rev=8#Phone> They have never — then or since — included a header at all, let alone a close button.

This is because a close button for a dialog is an anti-pattern: it has ambiguous effect, and it makes it less obvious that the window is a dialog at all. That is also why, if “a server-side decorated [dialog has] its own close button in the title bar”, that is a bug in Mir: per spec, no dialogs ever should. <https://goo.gl/N0pizp>

Now, an app might misbehave or hang when a trust prompt is open. But most of the time when an app misbehaves or hangs, a trust prompt is not open — simply because a trust prompt is not open the vast majority of the time that any app is running! So having a different method for force-closing the app, when a trust prompt happens to be open, would increase cognitive load for no obvious reason. The method of force-closing an app should be — and is — exactly the same regardless of whether a trust prompt is open or not.

But while content hub transfers will be only a small minority of the cases of an app hanging, an app hanging is a common case — arguably the majority legitimate case — for wanting to force-close an app. So it would be reasonable to have a prompt inviting you to force-close an app whenever it’s hung for any reason, whether the hang involves any trust prompt or not. This would be equivalent to the “The app {Name of App} has stopped responding” dialog I specified for apport. <https://wiki.ubuntu.com/ErrorTracker#app-hang>

Separately, if either content-hub source or destination apps hanging causes the other to hang too, that’s probably a bug in content-hub. One possible solution would be to cancel the transfer if nothing has happened after a given period. Perhaps there are other solutions.

I’m marking this as Invalid because those two issues would be tackled independently, while the change assumed in this report should not be implemented at all.

[Michał Sawicz (saviq)]

Actually the main concern is not for a hanging (we can try and detect that), but rather a broken / ill-designed one. If, in app A, you choose to open content from app B, and app B does not give you a way to go back, your only way out is to close both, hoping that there's no data loss in app A, in which you're probably editing content, since you just wanted to import some from app B.

[Matthew Paul Thomas (mpt)]

The same applies for non-hang misbehavior: the method of force-closing an app should be exactly the same regardless of whether a trust prompt is open or not.

However, I’m sorry I should have read the report more closely and noticed the phrase “content picking in a trust prompt”. To me, trust prompts and the content picker are very different things, so I don’t understand this phrase. I designed trust prompts, but I have never come across any design document from anyone covering the content picker (there are none on the design site).

So, what do you mean by “app B does not give you a way to go back”? Why is the ability to exit the content picker under the control of app B at all? For example, the macOS Open file dialog lets you browse the libraries of iTunes, iPhoto, and Photos, but you aren’t “in” those apps and they don’t get to control the dialog’s Cancel button.

[Ken VanDine (ken-vandine)]

@mpt from my understanding of the original designs, content picking was one of the use cases. There was a desire to open the source app in a trust prompt for the duration of the content picking operation. Keeping the users work flow from switching focus to another app, we are embedding the source app in the app requesting the content.

[Matthew Paul Thomas (mpt)]

I’ve explained what I understand by “original designs”. So, which designs are you referring to? Can you point me to a design document, or a mockup, or anything? I’m happy to work on this, but I can’t change the design of something I can’t locate.