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=some...@example.com&su=SUBJECT&body=BODY&bcc=someone.e...@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
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
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
signature.asc
Description: This is a digitally signed message part
--- End Message ---
signature.asc
Description: This is a digitally signed message part