Bug 427697 - KMail did not apply data from mailto information.
Summary: KMail did not apply data from mailto information.
Status: RESOLVED FIXED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 5.15.2
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-14 15:00 UTC by Markus Elfring
Modified: 2020-10-15 10:28 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.15.3


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Elfring 2020-10-14 15:00:31 UTC
SUMMARY
I installed the software package “kmail 20.08.2-1.1” also on my Linux system.

STEPS TO REPRODUCE
I clicked on a few mailto links which are displayed by the browser “Mozilla Firefox” according to the communication interface “public inbox”.

OBSERVED RESULT
Another email composition window was opened.
An address field “To” was filled with undecoded data from the clicked mailto link.

EXPECTED RESULT
Each item which was passed in a mailto string should be properly extracted and put into corresponding message fields.
* Subject
* To
* Cc
* In-Reply-To

SOFTWARE/OS VERSIONS
Linux: 5.7.16
KDE Frameworks: 5.75.0
Qt: 5.15.1

ADDITIONAL INFORMATION
https://public-inbox.org/README.html
https://en.wikipedia.org/wiki/Mailto

kmail doesn't honor Subject and In-Reply-To in mailto: links
https://bugs.kde.org/show_bug.cgi?id=395353
Comment 1 Laurent Montel 2020-10-14 15:23:02 UTC
Please provide me mailto url which created your bug.
Thanks
Comment 2 Markus Elfring 2020-10-14 16:24:33 UTC
(In reply to Laurent Montel from comment #1)
You can try mailto links from mailing lists out.

Example:
https://lore.kernel.org/cocci/
Comment 3 Laurent Montel 2020-10-15 05:22:29 UTC
Git commit 6e5baafc27748d870ab37f2fcbbfb63e53cc121c by Laurent Montel.
Committed on 15/10/2020 at 05:21.
Pushed by mlaurent into branch 'release/20.08'.

Fix Bug 427697 - KMail did not apply data from mailto information.
FIXED-IN: 5.15.3

M  +15   -0    messagecore/autotests/stringutiltest.cpp
M  +3    -1    messagecore/src/utils/stringutil.cpp

https://invent.kde.org/pim/messagelib/commit/6e5baafc27748d870ab37f2fcbbfb63e53cc121c
Comment 4 Laurent Montel 2020-10-15 05:34:24 UTC
Git commit a4715e7efc0909c6e37dbbcf21c4309c769a1fd9 by Laurent Montel.
Committed on 15/10/2020 at 05:33.
Pushed by mlaurent into branch 'release/20.08'.

Fix Bug 427697 - KMail did not apply data from mailto information.

Add missing in-reply-to support
FIXED-IN: 5.15.3

M  +5    -1    src/job/opencomposerjob.cpp

https://invent.kde.org/pim/kmail/commit/a4715e7efc0909c6e37dbbcf21c4309c769a1fd9
Comment 5 Markus Elfring 2020-10-15 06:54:52 UTC
(In reply to Laurent Montel from comment #3)
> Git commit 6e5baafc27748d870ab37f2fcbbfb63e53cc121c by Laurent Montel.

Thanks for such a quick and helpful response.


Now I wonder about the need for the following change in the implementation of the function “parseMailtoUrl”.
https://invent.kde.org/pim/messagelib/-/blob/6e5baafc27748d870ab37f2fcbbfb63e53cc121c/messagecore/src/utils/stringutil.cpp#L190

+                pairElement.first = queryItem.first.toLower();


Can case-sensitivity matter for any field names?


How will the program version “5.15.3” handle mailto links from another mailing list archive interface?

Example:
https://systeme.lip6.fr/pipermail/cocci/2020-October/thread.html


By the way:
Do such links work also with the browser “Konqueror 20.08.1” (at the moment)?
Comment 6 Markus Elfring 2020-10-15 07:00:33 UTC
(In reply to Laurent Montel from comment #4)
> Git commit a4715e7efc0909c6e37dbbcf21c4309c769a1fd9 by Laurent Montel.

Thanks for another software improvement.
Will the attention grow any more around the support for the message header field “In-Reply-To”?
Comment 7 Laurent Montel 2020-10-15 07:43:15 UTC
(In reply to Markus Elfring from comment #5)
> (In reply to Laurent Montel from comment #3)
> > Git commit 6e5baafc27748d870ab37f2fcbbfb63e53cc121c by Laurent Montel.
> 
> Thanks for such a quick and helpful response.
> 
> 
> Now I wonder about the need for the following change in the implementation
> of the function “parseMailtoUrl”.
> https://invent.kde.org/pim/messagelib/-/blob/
> 6e5baafc27748d870ab37f2fcbbfb63e53cc121c/messagecore/src/utils/stringutil.
> cpp#L190
> 
> +                pairElement.first = queryItem.first.toLower();
> 
> 
> Can case-sensitivity matter for any field names?

By default kmail use lowercase so this fix is ok.

> 
> 
> How will the program version “5.15.3” handle mailto links from another
> mailing list archive interface?
> 
> Example:
> https://systeme.lip6.fr/pipermail/cocci/2020-October/thread.html

Please provide me the mailto: url please.
I opened it but I didn't see mailto which creates a bug for you.

> 
> 
> By the way:
> Do such links work also with the browser “Konqueror 20.08.1” (at the moment)?

Really I don't know I work on kmail not on konqueror
Comment 8 Laurent Montel 2020-10-15 07:44:04 UTC
(In reply to Markus Elfring from comment #6)
> (In reply to Laurent Montel from comment #4)
> > Git commit a4715e7efc0909c6e37dbbcf21c4309c769a1fd9 by Laurent Montel.
> 
> Thanks for another software improvement.
> Will the attention grow any more around the support for the message header
> field “In-Reply-To”?

What is the problem with "In-Reply-To" support ?
Comment 9 Markus Elfring 2020-10-15 08:07:37 UTC
(In reply to Laurent Montel from comment #7)
> By default kmail use lowercase so this fix is ok.

How do you think about to make it configurable if field names should be kept unchanged?


> I opened it but I didn't see mailto which creates a bug for you.

I suggest to take take another look at the links for senders (at the top) of archived messages which were generated by the software “Pipermail 0.09 (Mailman edition)”.

Example:
https://systeme.lip6.fr/pipermail/cocci/2020-October/008322.html


> Really I don't know I work on kmail not on konqueror

I stumbled on another software surprise while checking the handling of mailto links also together with the browser “Konqueror 20.08.1”.
Now I am curious which developers would like to help with the clarification of undesirable software behaviour.
Comment 10 Markus Elfring 2020-10-15 08:16:29 UTC
(In reply to Laurent Montel from comment #8)
> What is the problem with "In-Reply-To" support ?

Some software components got challenges with proper data processing.
I am looking for corresponding software improvements and extensions.
Comment 11 Laurent Montel 2020-10-15 08:32:24 UTC
(In reply to Markus Elfring from comment #9)
> (In reply to Laurent Montel from comment #7)
> > By default kmail use lowercase so this fix is ok.
> 
> How do you think about to make it configurable if field names should be kept
> unchanged?

I don't understand your question here ?
We have a mailto with use no lowercase in url as here.
but kmail uses lowercase element. So it's fixed now. I don't understand your question.


> 
> 
> > I opened it but I didn't see mailto which creates a bug for you.
> 
> I suggest to take take another look at the links for senders (at the top) of
> archived messages which were generated by the software “Pipermail 0.09
> (Mailman edition)”.
> 
> Example:
> https://systeme.lip6.fr/pipermail/cocci/2020-October/008322.html

And ?
it works.
Did you see a problem for this one too ?
My autotest confirms that it works.
So I want to know what bug did you find.

> 
> > Really I don't know I work on kmail not on konqueror
> 
> I stumbled on another software surprise while checking the handling of
> mailto links also together with the browser “Konqueror 20.08.1”.
> Now I am curious which developers would like to help with the clarification
> of undesirable software behaviour.
Comment 12 Laurent Montel 2020-10-15 08:33:11 UTC
(In reply to Markus Elfring from comment #10)
> (In reply to Laurent Montel from comment #8)
> > What is the problem with "In-Reply-To" support ?
> 
> Some software components got challenges with proper data processing.
> I am looking for corresponding software improvements and extensions.

My work is to make mailto working with kmail.
I will not fix all apps (that I don't use/don't maintain)
Comment 13 Markus Elfring 2020-10-15 08:51:11 UTC
(In reply to Laurent Montel from comment #11)
> I don't understand your question.

* May field names be kept unmodified?
* How will views evolve around case-insensitivity?


> Did you see a problem for this one too ?

I observe another questionable behaviour with the software combinations on my system.


> My autotest confirms that it works.

I might look again when your software update will arrive here.


> So I want to know what bug did you find.

I am unsure if the selected browser is responsible for an undesirable test result.
Comment 14 Markus Elfring 2020-10-15 09:30:37 UTC
(In reply to Laurent Montel from comment #12)
> My work is to make mailto working with kmail.
> I will not fix all apps (that I don't use/don't maintain)

I assume that you might reconsider software aspects also according to previous clarification approaches and additional experience reports for involved tools.
Comment 15 Laurent Montel 2020-10-15 09:54:29 UTC
(In reply to Markus Elfring from comment #13)
> (In reply to Laurent Montel from comment #11)
> > I don't understand your question.
> 
> * May field names be kept unmodified?
> * How will views evolve around case-insensitivity?

Just for explaining:
you click on url (mailto) it will call kmail as default.
KMail will parse url => I know that kmail need lower case
=> I use lowercase.
So it will not break if url changed.


> 
> > Did you see a problem for this one too ?
> 
> I observe another questionable behaviour with the software combinations on
> my system.
> 
> 
> > My autotest confirms that it works.
> 
> I might look again when your software update will arrive here.
> 
> 
> > So I want to know what bug did you find.
> 
> I am unsure if the selected browser is responsible for an undesirable test
> result.

If you click on url and you find a bug in kmail I can fix it.
but I will not fix for other apps.
Comment 16 Markus Elfring 2020-10-15 10:28:20 UTC
(In reply to Laurent Montel from comment #15)
> but I will not fix for other apps.

I would find it nice if more contributors will help to improve the collaboration between the used programs.