Reverse trust prompt hosting

There is also another scenario in which this is triggered, and it's not something that can be helped with some refactoring:

When an application needs an OAuth token, it talks to Online Accounts (OA) to get it. If OA doesn't have a cached token (or if it's expired), OA will create a WebView, and load the OAuth URL into it. Since we are saving the session cookies, it is possible that there is no need to interact with the user, and that the WebView will be automatically redirected to the URL where the OAuth token can be collected from. When this happens, we don't want to bother the user at all.

However, in order to run a WebView, we need a QGuiApplication, which will make a blak window appear for some seconds.

What you are saying is clear, a splash screen is being incorrectly generated for these use-cases. Splash screens should only be generated for proper applications, not trust helpers/sessions.

Could you please give us steps to reproduce these issues though?

It's easy:

int main(int argc, char **argv)
{
    QGuiApplication app;
    return app.exec();
}

This program should not trigger a splash screen when run. :-)

Unity8 tries to draw a splash screen for an app as soon as possible, so the UI is responsive to the user. It will paint a splash screen when either of these things happen:
1. user taps an app icon in launcher
2. when upstart notifies it an app is starting
3. when Mir notifies it an app connected

For point 3, note I said "connected" - not created a surface and set it to show(). A QGuiApplication will create a Mir connection on instantiation. A QCoreApplication will not show a splash, as that does not create a Mir connection. Creation of a QWindow has no relation to the creation of a splash screen.

This isn't something we want for desktop ofc, but for phablet I think it makes for a good user experience to paint a splash screen quickly.

As a result, I don't believe there's a way a binary can tell shell not to paint a splash screen for it.
Instead these are the only options I can think of:
1. shell having some heuristics to decide what apps should not get a splash screen
2. app supplies metadata via desktop file to specify if it wants a splash or not

I dislike option 2, as I fear it could be abused by app developers, and make our platform appear slow to react to user input. Option 1 is also poor, as heuristics would be unreliable. So no path forward is clear to me on this matter.

Please rate this as High.

this is required for ota1

I'm not sure this bug is valid any more. The trusted prompt mechanism is different to how apps are created. Trusted prompts don't have splash screens (maybe they should?), but in any case a trusted session is short-lived, just for the duration of the prompt. The connection to Mir needs to happen on the trusted socket, so there's no connection that could trigger the splash screen (even if there was a splash screen) too early.

This bug is still valid: while all the UI interactions involving trust sessions are working fine (there is no splash screen -- as I believe is correct), there are still cases where the Online Accounts UI is not invoked within a trust session, and that's typically when the client process is not a GUI application. This is the case of scopes and some system services (sync-monitor, and maybe telepathy in the future).
As I wrote in comment #1, many times even if the OAuth access token is expired, the cookies are still valid and we might be able to get a new access token without showing a web page. But we cannot know this in advance: we'll know it only after loading a webview (and Oxide requires a QGuiApplication) which we'll keep hidden until either we get redirected to the page where we get the access token (in which case the user will not see any UI at all) or until it's clear that we cannot proceed without the user interaction, in which case we can either show a snap decision or just return an error to the client.

I believe that as far as trust prompts go, we've resolved that they should ultimately never talk to the default Mir socket, which is the only case when they get a splash screen. The backends should open a trust session, even if it's not going to create any UI in the end (that is, if they require a Mir connection to function, as is the case for Oxide). Until we have the headless-client hints implemented on surfaces, you can open the trusted session with dash's PID or whatever else makes sense.

Jury's still out on whether we want to disable splash screens for some apps, but that is more of a UX question than a technical one.

Another approach we might consider is dropping the --desktop_file_hint hack (I believe OA is one of the last instances of it) and think of a different way to allow trusted helpers in. We could also say that only UAL-backed apps get splash screens.

Alberto, can you please confirm if the above is good enough for you for now? And if not, please describe what other use case this lacks support for?

Yes, this is not really blocking me; until the headless-client hints are implemented I can just play safe and simply return an error on all UI requests.

Bearing the above in mind we have time to properly consider all the use cases and implement the long-term solution without hackfixes.

confirmed status in system-image means product team approved it, it is not related to subtask status

This one's targeted to ww51 as well, which is what I tried to counter.

Defer per discussion in the bug

I tried one of the suggested workarounds, that is setting QT_QPA_PLATFORM=minimal before opening the online-accounts-ui when we know that the client doesn't want any UI to be shown on top of it.
Unfortunately this doesn't work, as oxide won't work with the "minimal" backend:

  [1211/183336:FATAL:oxide_browser_process_main.cc(112)] Check failed: native_display_is_valid_.

I don't think we'll manage to make all the necessary changes by ww05, might need to push further out.

note, we need to address this for this bug as well
bug 1387691
see comments #9 & 10

Alberto, having talked through this with tvoss we think we found a sustainable solution for your use case. Just make sure to use ${MIR_SOCKET}_trusted for no-UI oxide thingy. You don't need anything special to connect to that, no need to create a trusted session or anything.

is this going to get attention this iteration?

We discussed this with tvoss in Brussels, there's an improvement on the architecture of this that we want to happen, but AFAIU it's not critical to any user experience at the moment. IMO this should be pulled off the RTM list.

Agreed. I thought this could solve focus issues we're experiencing with
trust prompts

But Saviq confirmed this is unrelated. So I agree that all system clients
that would benefit from that have otherwise found ways around this and
there is no user experience broken by the absence of this I can think of.

On Fri, Feb 13, 2015 at 12:20 PM, Michał Sawicz <<email address hidden>
> wrote:

> We discussed this with tvoss in Brussels, there's an improvement on the
> architecture of this that we want to happen, but AFAIU it's not critical
> to any user experience at the moment. IMO this should be pulled off the
> RTM list.
>
> ** Changed in: canonical-devices-system-image
> Status: Confirmed => New
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1352251
>
> Title:
> Reverse trust prompt hosting
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1352251/+subscriptions
>

Explaining per kgunn's request:

What we have currently is: whatever initiates a trusted session provides a PID of the process it wants to open the prompt on. The problem there is that trusted helpers need not necessarily know what that PID should be, because the request might come from a scope, which has no UI. Currently the helpers just cheat by going `pidof unity8-dash` and open the session with that.

In the general case it's fine because apps interact with trusted helpers directly, so the helpers can identify the connecting PID (with the exception that upcoming multi-surface support will somewhat break this, as the helper has no way to uniquely identify the surface to relate the session to).

What we need is for the trusted "broker", that scope-registry is, to be able to create a non-spoofable relation between whatever surface displays the data for a particular scope, and pass it down to the scope, which will then pass it to trusted helpers. The exact solution is not clear yet.

In addition, somewhat off-topic, we want to add an optional "type" and "metadata" or "geometry" arguments for a trusted prompt, to allow per-type transitions (immediate use case - media player as trusted prompt should grow from a thumbnail to fullscreen).