Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mailto links should focus subject, not address #7618

Closed
3 tasks done
LorenzHo opened this issue Feb 10, 2024 · 6 comments · Fixed by #7623
Closed
3 tasks done

Mailto links should focus subject, not address #7618

LorenzHo opened this issue Feb 10, 2024 · 6 comments · Fixed by #7623
Labels
type: enhancement New features or improvements to existing features.

Comments

@LorenzHo
Copy link

Checklist

  • I have used the search function to see if someone else has already submitted the same feature request.
  • I will describe the problem with as much detail as possible.
  • This issue only contains a request for one single feature, not multiple (related) features.

App version

6.603

Problem you are trying to solve

When opening a mailto link, I would expect to type the subject and body of the email. However, when K9 opens, the address field is focused, so finishing and sending the mail needs one unneccessary click.

example: mailto:user@example.com

Additionally, when I open a mailto link with the subject already filled, I would expect to type the body, but the address is focused.
example: mailto:user@example.com?subject=subject%20already%20filled

When replying to an email within K9, it directly focuses the body with the address and subject already filled. This is the behaviour I would expect also for mailto links.

Suggested solution

When opening an email from a mailto link, directly focus the subject if just the email address is given, and the body if the email address and subject is given.

Screenshots / Drawings / Technical details

No response

@LorenzHo LorenzHo added type: enhancement New features or improvements to existing features. unconfirmed Newly reported issues awaiting triage or confirmation labels Feb 10, 2024
@cketti
Copy link
Member

cketti commented Feb 10, 2024

We might not get to this anytime soon. But we'd welcome pull requests to implement the suggested behavior.

@cketti cketti removed the unconfirmed Newly reported issues awaiting triage or confirmation label Feb 10, 2024
LorenzHo pushed a commit to LorenzHo/thunderbird-android that referenced this issue Feb 11, 2024
@cketti
Copy link
Member

cketti commented Feb 12, 2024

It's possible to have a mailto URI without a recipient mailto:?subject=text. What should happen in such a case? Focus on the "To" field or the message body?

@LorenzHo
Copy link
Author

Very valid point, focus should be on the first empty field of "To", "Subject" and body in that order.

However this is a little more complex to implement as I currently understand it, as it seems with my (limited) understanding of the codebase that in addRecipientsFromAddresses actually loading the "to" addresses is put off to a RecipientLoader until the field is rendered.

So, there seems to me to be no direct way to access if any email address is going to be loaded into the "To" field from where the distribution of focus currently happens, but I might just be missing it.
Both recipientMvpView.getToAddresses() and recipientPresenter.getToAddresses() turn up empty at that point

@cketti
Copy link
Member

cketti commented Feb 13, 2024

Thanks for looking into it. This feels too complicated address right now. So I merged your PR as is.

We need to clean up the way recipients are handled anyway. That should make it easier to implement the desired focus logic afterwards.

@LorenzHo
Copy link
Author

Actually I've looked into this again and how it is now, it causes a regression apart from the edge-case mailto link without a "to" address: When a user tries to share a file by K9, now the subject field is focused, while the "to" field is unfilled. This is I would say a valid use case.
No hurt feelings if you cancel my original PR.
I'll try to find an easy way to manage focus somewhere where the to addresses are available, maybe during composing the UI. Let's handle this in the issue #7635 you created.

@cketti
Copy link
Member

cketti commented Feb 14, 2024

Thanks for staying on this. I'll revert the change, so we don't change the behavior when handling share intents.

cketti added a commit that referenced this issue Feb 14, 2024
This unintentionally changed the behavior when handling share intents.

This reverts commit 6210852.
This reverts commit 89c7a36.
cketti added a commit that referenced this issue Feb 15, 2024
Revert "#7618 focus subject or content field on external intent"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New features or improvements to existing features.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants