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. ** Changed in: ubuntu-ux Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1650022 Title: We need a "close" action for killing an app in a trust prompt Status in Canonical System Image: New Status in Ubuntu UX: Invalid Status in unity8 package in Ubuntu: Confirmed Bug description: 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. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1650022/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
