Trusted prompts make application inactive: Qt.application.active == false

To be correct, in the situation you described, Qt.application.active should remain true, but the camera window will be unfocused. Ok?

@Gerry: I guess you're right.

If you read https://wiki.ubuntu.com/Security/TrustStoreAndSessions
"From a lifetime perspective, the TPS ends whenever the TPP or its surface is dismissed. Similarly, if the session is terminated for any other reason, the TPP and its surface are dismissed, too. The app cannot exercise any sort of control in this scenario and is not even guaranteed to run.

Only after the trust session has ended, control is transferred back to the app. More to this, while a TPS is active, focus mgmt. treats the session as atomic and prevents the app from being refocused separately."

It seems that this could be impossible by design. However, it also seems that the application remains active while the TPS is displayed, and only switches to inactive when the TPS is closed (the app quickly switches back to active, but I suppose this could be enough to break certain things).

@josharanson, are you saying that somehow the camera app should behave differently? Does it have enough information to know that this process is happening to it? (sorry if those are noob questions).

This is blocking silo 30 from landing, which has trust store integration for audio & camera.

Note, the app should not be allowed to record until the user says it is ok to record (or that answer is cached elsewhere). I'm not sure what the result of Qt.application.active staying true will have, but if it means the app continues recording, that is not correct. Consider the user opening the app then gets distracted by something else and doesn't notice the prompt but the app is still recording and possibly sending it over the network.

note the UI has been recently updated: bug #1481913

sorry. #7 is for the wrong bug.

@John theoreticaly the camera app could handle this, but I think we have a work-around, as well as a proper fix in the works.

This branch is a work-around.
https://code.launchpad.net/~josharenson/unity8/fix_tps_active
I'm not quite sure what the far reaching implications of this fix are yet. However, I have performed some manual/automated testing, and I certainly don't see anything obviously wrong. I'm going to kick off a ci build for it in a bit as well (for even more automated testing)

This branch contains the proper fix.
https://code.launchpad.net/~dandrader/qtmir/mirSurface/+merge/264923
It removes the same code that the first branch does, but it depends on 2 other branches (in two different projects), so getting it landed will take some effort.

I imagine that the first branch should work, in a pinch, but I'd appreciate confirmation from dandrader.

just an update, we are currently reviewing and testing the MirSurface branches for unity8/unity-api/qtmir.
A silo is being readied for team testing.
This is the correct way to address the issue, however the change is larger than we would like for this late in the OTA prep cycle.
The good news is that these branches have been around a while so there is a fair amount of engineering testing that has happened during devel.

With this fix we now get further. But on arale camera records black video after accepting prompt.