[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#965303: reportbug: add support for loading bug reports in web browsers that support mailto: links (Firefox/Chromium)

Control: unmerge -1

These bugs are for two different features, please don't merge them.

On Fri, 2020-10-23 at 22:41 -0400, John Scott wrote:

> Recent versions of reportbug have semi-experimental support for xdg-email, 
> which sends a mailto: URI to whatever the user's configured handler is.
> Would that cover this case?

As I already discussed with Nis Martensen, the existing support isn't
sufficient. Since this discussion was unfortunately not CCed to any
bug, I have attached it to this mail. See also this feature request:

https://bugzilla.mozilla.org/show_bug.cgi?id=1653821

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
--- Begin Message --- 
[Moving off the bug since it is off-topic]

On Sun, 2020-07-12 at 10:09 +0200, Nis Martensen wrote:

> The default MUA in reportbug is and will remain the built-in one,

I'm not sure it is correct to call the default bug handling an MUA :)

> because it most reliably avoids the practical issues involved with
> passing email templates between different applications, and it also
> needs zero configuration effort from users in the most common case. It
> is usable even on systems where no MUA is installed at all, and does not
> require a local MTA either.

On the other hand it likely violates SPF/DKIM/DMARC/ARC policies at
gmail.com and other large providers, leading to bug reports getting
blocked in various places. Of course the BTS remailing stuff also
violates these policies, at least until Debian supports ARC.

> External MUAs are an opt-in convenience option for users that prefer
> this. The main benefit of including xdg-email among the supported MUAs
> is that it provides flexible integration with further MUAs not
> explicitly supported through our own code. There are no plans to make it
> the default MUA for reportbug, not even specifically in the GTK ui, and
> I don't think it makes sense to change that today or in the near future.

A significant advantage of reportbug-ng over reportbug was the MUA
support was much wider, for example since until 2020 reportbug didn't
support any GUI MUAs that non-technical users use. Personally I don't
think the default "MUA" makes any sense to most users of reportbug in
2020. The majority of humanity in 2020 expect all their mail handling
(if they actually still use email) to go through their mail client,
either a local one or much more likely webmail, especially gmail.com.

reportbug-ng supported Opera and gmail.com in addition to the MUAs now
supported by reportbug. At least the latter would be useful to many
submitters and I note that the method it uses (loading a gmail.com URL
in the browser) still works.

https://gmail.google.com/gmail?view=cm&cmid=0&fs=1&tearoff=1&to=%(to)s&su=%(subject)s&body=%(body)s

From some web searching it seems some other Gmail urls work too:

https://stackoverflow.com/questions/6548570/url-to-compose-a-message-in-gmail-with-full-gmail-interface-and-specified-to-b
https://mail.google.com/mail/?view=cm&fs=1&to=someone@example.com&su=SUBJECT&body=BODY&bcc=someone.else@example.com

In addition to directly loading webmail URLs, it seems that some
browsers (Firefox for example) have handling of mailto links that
enables them to open either a local MUA or a remote webmail service.

Firefox seems to use the .desktop files since it knows about local MUAs
that reportbug does not know about.

Firefox also supports the following two webmail providers:

Gmail https://mail.google.com/mail/?extsrc=mailto&url=%s (%s is a mailto: URL)
Yahoo https://compose.mail.yahoo.com/?To=%s (not sure, probably the same)

So I wonder if reportbug should support some extra MUA options?

   1. Explicit support for Gmail, Yahoo and any other webmail services
      that support mailto: URLs or have a compose message URL.
   2. Support for passing a mailto: URL to the default configured browser
      or to a custom browser.
   3. Support for selecting a MUA from the MUAs installed that handle the
      MIME type x-scheme-handler/mailto.

On the other hand, #1 is basically a duplicate of the browser code for
#2 but in theory #1 could make it easier to add support for more
webmail services. Also #3 duplicates xdg-email's support for this.

PS: related blog post:

https://www.enricozini.org/blog/2020/debian/mime-type-associations/

PS: what do you think about splitting the MUA handling of reportbug out
into a Python module that can also be used by other programs?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message --- 
On 14.07.2020 11.48, Paul Wise wrote:
> On Sun, 2020-07-12 at 10:09 +0200, Nis Martensen wrote:
> 
>> because it most reliably avoids the practical issues involved with
>> passing email templates between different applications, and it also
>> needs zero configuration effort from users in the most common case. It
>> is usable even on systems where no MUA is installed at all, and does not
>> require a local MTA either.
> 
> On the other hand it likely violates SPF/DKIM/DMARC/ARC policies at
> gmail.com and other large providers, leading to bug reports getting
> blocked in various places. Of course the BTS remailing stuff also
> violates these policies, at least until Debian supports ARC.

I expect most occasional reportbug users will use the default smtphost,
reportbug.debian.org. The issues you mention then will not block the
initial bug submission from reportbug, "only" what happens after that.

> So I wonder if reportbug should support some extra MUA options?

My preferred solution to this would be to keep the MUA handling code in
reportbug minimal. Ideally I'd hope that webmail services cooperate with
browsers to register mailto handlers with the desktop environments' MIME
handling mechanism(s), and together with the desktop environment provide
a nice user interface to set the default accordingly. Then we don't need
additional code in reportbug, because just passing things through
xdg-email should do the job?

I suspect what today's users possibly really expect is a Web UI for
reportbug. With that it might be possible to have everything in the
browser and we wouldn't need to rely on reportbug, the desktop
environment, and/or xdg-utils for the desired mailto handling.

Weren't there also some ideas years ago to implement a Web UI for
debbugs directly, so that bug reporting in Debian wouldn't need to rely
on email any longer? Wouldn't that be even better?

> https://www.enricozini.org/blog/2020/debian/mime-type-associations/

Thanks for this.

> PS: what do you think about splitting the MUA handling of reportbug out
> into a Python module that can also be used by other programs?

Today interested consumers can already depend on python3-reportbug and
just import reportbug.mailer, and do not need to have full reportbug
installed. I think you are suggesting going beyond that and splitting it
off into its own python3-mua binary package, or something like that?

If you feel there are sufficient potential users for that then I
encourage you to submit a patch. :)  Forking the code into a different
source package is of course also fine; reportbug could then switch to
using that instead of maintaining its own MUA handling code.

 Nis

--- End Message ---
--- Begin Message --- 
On Tue, 2020-07-14 at 20:17 +0200, Nis Martensen wrote:

> I expect most occasional reportbug users will use the default smtphost,
> reportbug.debian.org. The issues you mention then will not block the
> initial bug submission from reportbug, "only" what happens after that.

Right, "only" things like reaching the package maintainer :)

> My preferred solution to this would be to keep the MUA handling code in
> reportbug minimal. Ideally I'd hope that webmail services cooperate with
> browsers to register mailto handlers with the desktop environments' MIME
> handling mechanism(s), and together with the desktop environment provide
> a nice user interface to set the default accordingly. Then we don't need
> additional code in reportbug, because just passing things through
> xdg-email should do the job?

I agree that would be the most ideal situation but as we know, MUA
handling isn't exactly ideal at the best of times :) AFAICT xdg-email
does not know about the webmail providers registered in the different
browser's codebases. It does know about the different browsers though
but doesn't know that Firefox and Chromium can handle mailto: URLs,
just that they can handle http/https URLs. The package gnome-gmail
provides some glue between the xdg MIME stuff and Gmail, but that
doesn't cover other webmail providers. As far as I can tell, Firefox
provides no mechanism to tell it which webmail to launch a particular
mailto: URL in, so you can't yet tell GNOME to use "Gmail in Firefox"
as your MUA, only "Firefox" and only if you manually add mailto: to the
Firefox .desktop file. Chromium seems to be similar. There are likely
other webmail providers out there with compose mail URLs that aren't
yet supported by browsers. Some folks might want to use their chosen
webmail while using a browser that doesn't yet translate mailto URLs to
webmail URLs, since there are other browsers people may prefer.

https://bbs.archlinux.org/viewtopic.php?id=154031
https://davesteele.github.io/gnome-gmail/
https://support.mozilla.org/en-US/kb/change-program-used-open-email-links

Given the above complexity, I suggest the following actions:

File bugs on Chromium and Firefox asking for XDG MIME mailto:
integration for each of their webmail providers and command-line
arguments used by that integration to select the providers.

Add to reportbug support for passing mailto: URLs to each web browser
that handles mailto URLs in a way that isn't just passing it back to
the mailto: handlers defined by the XDG MIME stuff. Currently I only
know of Chromium and Firefox supporting this but there may be more and
folks on debian-devel or similar may know which ones do this.

Add to reportbug direct support for the webmail providers that are
available in Firefox and Chromium, any other common ones that we can
find that have compose mail URLs and a generic one that allows
customising the URL similar to how Firefox/Chromium internally specify
the URLs. These would all translate the to/subject/body/cc/bcc fields
or mailto URL to http/https URLs and pass them to the default browser
or possibly the browser set in the reportbug config. The configured
browser would be looked up via its .desktop file and passed the URL.

Does this sound like a reasonable plan? If so, I can help.

Firefox has these URLs that accept mailto URLs:

https://compose.mail.yahoo.com/?To=%s
https://email.seznam.cz/newMessageScreen?mailto=%s
https://mail.google.com/mail/?extsrc=mailto&url=%s
https://mail.yahoo.co.jp/compose/?To=%s
https://mail.yandex.ru/compose?mailto=%s
https://poczta.interia.pl/mh/?mailto=%s
https://e.mail.ru/cgi-bin/sentmsg?mailto=%s
https://outlook.live.com/default.aspx?rru=compose&to=%s

> I suspect what today's users possibly really expect is a Web UI for
> reportbug. With that it might be possible to have everything in the
> browser and we wouldn't need to rely on reportbug, the desktop
> environment, and/or xdg-utils for the desired mailto handling.

Agreed, although that would throw under the bus existing contributors
who prefer email and very much dislike the modern web and browsers in
general, so I suspect the mail side is still needed for some folks.

In addition we would need the webui to only allow people with a
reportbug browser WebExtension installed to file a bug, otherwise most
people doing bug reporting would miss the usual information that
reportbug provides and Debian package maintainers would be drowning in
much less useful bug reports. The extension could set a hidden form
field that would be unset by default and the webui backend would check
on the server side that it is set.

There would also be the usual SPF/DKIM/DMARC/ARC complexities if
existing contributors are to still recieve bugs via mail.

> Weren't there also some ideas years ago to implement a Web UI for
> debbugs directly, so that bug reporting in Debian wouldn't need to rely
> on email any longer? Wouldn't that be even better?

There was a prototype called Amancay but it was never adopted:

https://wiki.debian.org/ReportbugWeb
https://wiki.debian.org/SummerOfCode2007/DebbugsWebUI
https://wiki.debian.org/SummerOfCode2008/DebbugsWebUI
https://wiki.debian.org/SummerOfCode2009#Debbugs_Web_UI:_Amancay_Strikes_Back
https://alioth-archive.debian.org/svn/bts-webui.tar.xz

> Today interested consumers can already depend on python3-reportbug and
> just import reportbug.mailer, and do not need to have full reportbug
> installed. I think you are suggesting going beyond that and splitting it
> off into its own python3-mua binary package, or something like that?

I am suggesting to move the MUA handling into an entirely new upstream
source project that is entirely separate to reportbug and can be used
by any project that wants to deal with MUAs. This would be distributed
on PyPi and other places that Python code is consumed from.

> If you feel there are sufficient potential users for that then I
> encourage you to submit a patch. :)  Forking the code into a different
> source package is of course also fine; reportbug could then switch to
> using that instead of maintaining its own MUA handling code.

I'm not the right person to lead such a fork and I haven't done much
research to find out who else would use it, but I expect that there
would definitely be some folks who could. Using the Debian code search
it seems there is one other package in Debian written in Python
(kupfer) that seems to have MUA launching capabilities. The GitHub code
search provides 14 pages of projects with MUA launching capabilities.

https://codesearch.debian.net/search?q=thunderbird.*-compose&literal=0
https://github.com/search?q=thunderbird+-compose&type=Code&l=Python

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message --- 
On 15.07.2020 02.59, Paul Wise wrote:
> On Tue, 2020-07-14 at 20:17 +0200, Nis Martensen wrote:

> Given the above complexity, I suggest the following actions:
> 
> File bugs on Chromium and Firefox asking for XDG MIME mailto:
> integration for each of their webmail providers and command-line
> arguments used by that integration to select the providers.
> 
> Add to reportbug support for passing mailto: URLs to each web browser
> that handles mailto URLs in a way that isn't just passing it back to
> the mailto: handlers defined by the XDG MIME stuff. Currently I only
> know of Chromium and Firefox supporting this but there may be more and
> folks on debian-devel or similar may know which ones do this.
> 
> Add to reportbug direct support for the webmail providers that are
> available in Firefox and Chromium, any other common ones that we can
> find that have compose mail URLs and a generic one that allows
> customising the URL similar to how Firefox/Chromium internally specify
> the URLs. These would all translate the to/subject/body/cc/bcc fields
> or mailto URL to http/https URLs and pass them to the default browser
> or possibly the browser set in the reportbug config. The configured
> browser would be looked up via its .desktop file and passed the URL.
> 
> Does this sound like a reasonable plan? If so, I can help.

Sorry, I don't have a good answer for you.

At the moment I'm just happy that reportbug's MUA integration has
finally been brought to what I think is a reasonable level, and I am not
(yet?) thinking about how to move it further. Reportbug still has other
bugs that have been open for too long.

Perhaps you could file wishlist bugs so that your ideas won't be
forgotten? Maybe someone else finds the time and motivation to work on
this sooner than either of us.

>> Today interested consumers can already depend on python3-reportbug and
>> just import reportbug.mailer, and do not need to have full reportbug
>> installed. I think you are suggesting going beyond that and splitting it
>> off into its own python3-mua binary package, or something like that?
> 
> I am suggesting to move the MUA handling into an entirely new upstream
> source project that is entirely separate to reportbug and can be used
> by any project that wants to deal with MUAs. This would be distributed
> on PyPi and other places that Python code is consumed from.

Thank you for the idea. At the moment I'm not planning such work, but
we'll see how things develop.

Regards,
 Nis

--- End Message ---
--- Begin Message --- 
On Sat, 2020-07-18 at 23:20 +0200, Nis Martensen wrote:

> Sorry, I don't have a good answer for you.

OK, fair enough.

> At the moment I'm just happy that reportbug's MUA integration has
> finally been brought to what I think is a reasonable level, and I am not
> (yet?) thinking about how to move it further. Reportbug still has other
> bugs that have been open for too long.

Agreed :)

> Perhaps you could file wishlist bugs so that your ideas won't be
> forgotten? Maybe someone else finds the time and motivation to work on
> this sooner than either of us.

I'll try to do that for the Firefox & reportbug changes at least, but
I'll leave interacting with Chromium upstream to someone else.

> Thank you for the idea. At the moment I'm not planning such work, but
> we'll see how things develop.

Perhaps if/when the webmail stuff happens it will be more warranted.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: