[email] Sharing a photo by email calls up a dekko send window that can't exit.

[James Lewis]

Steps to replicate:-

1. Take a picture with the camera
2. Share it to an email and send the email.

Expected behaviour.

1. Mail sends and mail sending window closes returning you to camera.
or
1. Mail sends and user is returned to mail sending window.
2. Pressing the "back" ( down arrow "V" ) at the top left closes the mail sending window and returns to camera.

Actual behaviour.
1. Mail sends and user is returned to mail sending window.
2. Pressing the "back" ( down arrow "V" ) at the top left gives tactile feedback buz but does nothing, have to use app switcher to close mail sending window.

Tested on Meizu MX4 with OTA-7 - I'm not sure if this is a Camera bug, or a bug in Dekko,... or some plumbing.

[Dan Chapman  (dpniel)]

Is it desired that an email client should close itself after mail submission? This wouldn't be inline with how the rest of the platform handles content shares where the receiving app usually just stays open and focused after handling the shared content.

Although the expected behaviour is actually the same as how it currently works on the desktop, so I can see why this would be the expected. It's also trivial to add a Qt.quit() on successful submission.

I'm going to include ubuntu-ux for this to get their take,

[James Lewis (james-fsck)]

Dan,

The UI for using one app from with another changes the back button from a < to a V to imply that it returns to the calling app, not the previous screen in the app..... this works in most cases but not in the example above.. In fact it is only a send window that opens for the share function and a send window does close when a message is sent.

However, if it was decided that one should be able to send multiple mails to share the image before returning then that would be OK, but in this case the UI does not function.... The window does not close, but the back/return button also does not function.

[Dan Chapman  (dpniel)]

Hey James,

The change of the back button is to do with how the bottom edge is used. see bug 1432696. So in Dekko the message composer usually lives down in the bottom edge so during normal usage the composer will present the V chevron to dismiss the composer back downwards. But when dekko is launched due to a content share the composer is invoked in a different way and not opened from the bottom edge which results in the different chevron direction as it's now just a page on the stack and not owned by the bottom edge.

There is definately a bug in the back button here as the composer is being created in the wrong state and is trying to dismiss the dialog to the bottom edge rather than pop it off the page stack.

https://git.launchpad.net/dekko/tree/qml/main.qml#n118 should be

var composePage = rootPageStack.push(Qt.resolvedUrl("./Composer/ComposePage.qml"),
                                         {
                                             replyMode: ReplyMode.REPLY_NONE,
                                             pageTitle:qsTr("New Message"),
                                             isBottomEdgeMode: false // IT'S MISSING THIS
                                         });

So that's a trivial fix and i'll prepare a fix for that now.

My real concern here is the expected behaviour, should the user be returned to the calling app after submission. Currently no other apps do this after handling the shared content (that I have used anyway....) and there doesn't seem to be any UX documentation for this particular flow.

[Alan Pope 🍺🐧🐱 🦄 (popey)]

For what it's worth on Android if you open a photo in dropbox app and "share" it to twitter (by way of an example), after tweeting, you're left inside the twitter app, not returned to dropbox.

We certainly need some guidance on what the platform should do in these cases.

[Dan Chapman  (dpniel)]

FTR the merge proposal that fixes the back action is now here https://code.launchpad.net/~dekko-developers/dekko/+git/dekko/+merge/277803

[James Lewis (james-fsck)]

Dan,

I agree, it's not completely clear what "should" happen, which is why I listed 2 possible "expected" behaviour options... currently the send mail window returns, with the image again attached as if to allow you to send another mail with the image attached... this would be reasonable behaviour, so long as the "back" button functioned... I believe we're agreed that in this case the back button returns to the calling app, not back to the dekko inbox screen?

[Dan Chapman  (dpniel)]

For now i've just done this as Dekko remains open but the composer exits correctly. I'll wait for a decision from design on whether Dekko should actually quit after the submission