Closed Bug 824909 Opened 8 years ago Closed 6 years ago

Print/Print preview of .eml files shows blank on linux - don't add wrong file association to ~/.local/share/applications/mimeapps.list

Categories

(Thunderbird :: OS Integration, defect)

17 Branch
All
Linux
defect
Not set
normal

Tracking

(thunderbird36 fixed)

RESOLVED FIXED
Thunderbird 36.0
Tracking Status
thunderbird36 --- fixed

People

(Reporter: ext-bug-report, Assigned: firefox)

References

(Blocks 1 open bug)

Details

(Whiteboard: [not fixed for existing installations: workaround see comment 45])

Attachments

(3 files, 5 obsolete files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121129165506

Steps to reproduce:

I saved an e-mail as example.eml. Opened this e-mail with Thunderbird and tried to print it.


Actual results:

The print preview contains nothing but the words "about:blank" and when you try to print it, an empty page comes out of the printer


Expected results:

The print preview should contain a preview of what thunderbird is about to print and the e-mail should be printed.
ext-bug-report, due to the current unavailability of Mozilla's secret service or suitable trojans to grab a copy of your message data for inspection, we kindly ask you to provide a testcase.eml message which exposes the symptoms you describe, for further analysis... ;) Without such, this bug shall be doomed for closure as incomplete.

Just joking, but really there's nothing we can do without an affected testcase.eml message added as an attachment to this bug.
There is also a similar report in bug 839659, with screenshots.
Flags: needinfo?(ext-bug-report)
(In reply to Thomas D. from comment #1)
> Just joking, but really there's nothing we can do without an affected
> testcase.eml message added as an attachment to this bug.

I've provided a sample email in bug 839659.
It's very simple though, so I doubt the content has anything to do with it.
Hi, this is the requested e-mail that doesn't print. It works with all e-mails though and is not limited to this specific e-mail.
Flags: needinfo?(ext-bug-report)
The supplied message worked for me fine, I could print-preview it.
I added this comment on bug 839659:

------------------------

I confirm this bug on Thunderbird 17.0.5 on Ubuntu 12.04. :

- .eml files open but can't be printed
- this does NOT depend on the file content nor on the printer; no saved .eml file can be printed
- print preview shows a blank window
- both the print and print preview function trigger the "Open/Save" dialog which offers the possibility of opening the same .eml file again (!)

-----------------------

Just to stress that the problem is confirmed. I would be good that these two reports got merged.

I'm available to perform more tests since the problem is reproducible.
To reproduce this issue

Select Preferences->Preferences->Advanced->System Integration->Check Now ( email ). Thunderbird inserts the wrong file type association into ~/.local/share/applications/mimeapps.list . 

This causes the window manager to incorrectly interpret file associations. Removing the lines
starting with "application/x-extension-eml=thunderbird.desktop" fixes
the problem. 

A workaround is to amend the file manually in order to fix the file association issue
machines which started with old profiles.
Hey folks. Please review my attached patch which offers a remedy for Thunderbird installations with both new and existing user configuration.
Attachment #8412245 - Flags: review+
Attachment #8412245 - Flags: feedback+
A scan of the sample email printed out, both before and after applying my patch.
Attachment #8412248 - Flags: review+
Attachment #8412248 - Flags: feedback+
Comment on attachment 8412245 [details] [diff] [review]
fix-broken-printing-eml-files.patch

Hi, for future reference, when adding a patch, the review and other fields are meant to be requests to specific people to review the patch, indicated by selecting the value '?' and adding a requestee.
Attachment #8412245 - Flags: review?(mkmelin+mozilla)
Attachment #8412245 - Flags: review+
Attachment #8412245 - Flags: feedback+
Attachment #8412248 - Flags: review+
Attachment #8412248 - Flags: feedback+
Thanks for bringing that to my attention, Joshua. Sorry about that.
OS integration or Printing will be a more appropriate home.
(plus we dont' really want fixed bugs left in Untriaged)
Status: UNCONFIRMED → ASSIGNED
Component: Untriaged → OS Integration
Ever confirmed: true
Hi Kip. Magnus is quite busy with release-related activites, so it may be a few days until a review is possible
Assignee: nobody → kip
Thanks a lot Wayne. I would have changed those, but didn't have permissions until now. Thanks again and looking forward to liaising with Magnus when he has time. Always happy to improve and contribute to software freedom whenever and wherever I can.
Kip, thanks for providing a patch here, that's great! Perhaps you want to have a look into Bug 297702? :)
Hey Thomas. I took a look at #297702 and, at least my first impression, the bug I don't think is related to this one. They both involve printing issues, but I think the latter might not be CUPS related. 

I could try to take a look at it down the road more in detail and fix it though, as I don't think it would be very difficult to do. My guess is it isn't a "bug" in the classical sense, but probably the programmer never got around to writing out the header fields code before passing the email out of the application for printing. But I'd have to look more carefully to be sure.
Comment on attachment 8412245 [details] [diff] [review]
fix-broken-printing-eml-files.patch

Review of attachment 8412245 [details] [diff] [review]:
-----------------------------------------------------------------

Thx for the patch Kip! The general idea sounds good.

The indention is really off, please fix it (and make it consistent)
You could also break out getting the brandshortname to a helper function as it's also used in nsMailGNOMEIntegration::MakeDefault

::: AUTHORS
@@ +243,4 @@
>  Kevin Puetz <puetzk@iastate.edu>
>  Kin Blas <kin@netscape.com>
>  Kipp Hickman <kipp@netscape.com>
> +Kip Warner <kip at thevertigo dot com>

the AUTHORS file is really just legacy, authorship is preserved by source control

::: mail/components/shell/nsMailGNOMEIntegration.cpp
@@ +21,4 @@
>  #include "mozilla/Services.h"
>  
>  #include <glib.h>
> +#include <gio/gio.h>

this would have to be 

ifdef MOZ_ENABLE_GIO

... and functionality adapted to that

@@ +50,5 @@
>  };
>  
>  static const AppTypeAssociation sAppTypes[] = {
> +  
> +    /* 

prefer // Comment even when a bit lengthy. That makes it so much easier for someone to comment out some larger chunk to test something out... 
and remove the whitespace on the empty lines

@@ +113,4 @@
>    // the locale encoding.  If it's not set, they use UTF-8.
>    mUseLocaleFilenames = PR_GetEnv("G_BROKEN_FILENAMES") != nullptr;
>  
> +  // Fix for <https://bugzilla.mozilla.org/show_bug.cgi?id=824909>

exepct for special cases we don't put bug comments in the source, if someone needs it they can always look at hg blame

@@ +146,5 @@
> +      //const guint length = g_list_length(eml_applications_list);
> +
> +    // Go through the list of applications registered for the problematic
> +    //  MIME type, each time seeing if we're in it...
> +    for(GList *list_node = g_list_first(eml_applications_list);

space after for
but, isn't this a while?

@@ +158,5 @@
> +      // Query it for its application identifier...
> +      const char *current_app_name = g_app_info_get_name(current_app_info);
> +
> +      // We found what is probably ourselves...
> +      if(g_strcmp0(current_app_name, app_name.get()) == 0) {

space after if

@@ +161,5 @@
> +      // We found what is probably ourselves...
> +      if(g_strcmp0(current_app_name, app_name.get()) == 0) {
> +
> +        // Issue a warning...
> +        g_warning("Cleaning up broken MIME... (see bugzilla #824909)");

instead of bug nbr, state that you're unregistering application/x-extension-eml

@@ +169,5 @@
> +        g_app_info_remove_supports_type(
> +          current_app_info, problem_mime, &error);
> +
> +          // Failed...
> +          if(error) {

space after if
Attachment #8412245 - Flags: review?(mkmelin+mozilla) → review-
Duplicate of this bug: 1007072
Blocks: 1007072
I'm not at Thunderbird peer, so feel free to ignore anything I say.

> +      // We'll need the string bundle service...
> +      // ...and then we'll need to create a brand bundle from the brand service...
This is standard mozilla boilerplate so we don't really need these comments.

> +      brandBundle->GetStringFromName(
> +        NS_LITERAL_STRING("brandShortName").get(),
> +        getter_Copies(brandShortName));

For new code we prefer:
  brandBundle->GetStringFromName(MOZ_UTF16("brandShortName"),
                                 getter_Copies(brandShortName));

> +      // The problem MIME type...
> +      const char *problem_mime = "application/x-extension-eml";

> +        // Issue a warning...
> +        g_warning("Cleaning up broken MIME... (see bugzilla #824909)");

> +          // Failed...
> +          if(error) {

> +            // Issue a non-fatal warning...
> +            g_warning("Cannot remove application as default for MIME type (%s): %s",
Comments are good. Unless they just re-state the obvious.

> +    for(GList *list_node = g_list_first(eml_applications_list);
> +        list_node != NULL;
> +        list_node = g_list_next(list_node)) {
Does the following work?

> for (GList *list_node = eml_applications_list; list_node != nullptr; list_node = list_node->next) {

> +      // Get the current registered application...
> +      GAppInfo *current_app_info = static_cast<GAppInfo *>(list_node->data);
> +      g_assert(current_app_info);
Under what conditions will this assert?
Please use MOZ_ASSERT() in Mozilla code.

> +      if(g_strcmp0(current_app_name, app_name.get()) == 0) {
Use standard strcmp unless g_strcmp0 does something extra that you need.

> +        GError *error = NULL;
GError *error = nullptr;
Attachment #8412245 - Attachment is obsolete: true
(In reply to Magnus Melin from comment #17)
> Thx for the patch Kip! The general idea sounds good.

Hey Magnus. Thanks for taking the time to review. Upon reviewing your review, I realized the patch was incomplete and there were certain situations I needed to also address, such as what happens when the user as explicitly registered the problem mime with another application or applications. So I did quite a bit of refactoring.

> The indention is really off, please fix it (and make it consistent)

Fixed.

> You could also break out getting the brandshortname to a helper function as
> it's also used in nsMailGNOMEIntegration::MakeDefault

Fixed. No problem anymore with the new refactoring.

> the AUTHORS file is really just legacy, authorship is preserved by source
> control

Ok noted, but I don't have commit access and my Mercurial Kung Fu is rusty.

> this would have to be 
> 
> ifdef MOZ_ENABLE_GIO
> 
> ... and functionality adapted to that

Fixed.

> prefer // Comment even when a bit lengthy. That makes it so much easier for
> someone to comment out some larger chunk to test something out... 
> and remove the whitespace on the empty lines

Fixed.

> exepct for special cases we don't put bug comments in the source, if someone
> needs it they can always look at hg blame

Fixed.

> space after for

Fixed.

> space after if

Fixed.

> instead of bug nbr, state that you're unregistering
> application/x-extension-eml

Fixed.

> space after if

Fixed.

Sorry for taking a while to get back to you. It took me a while to carefully ensure that the patch works properly and it meets your requirements. Hopefully this is what you need now.
(In reply to Kip from comment #21)
> > the AUTHORS file is really just legacy, authorship is preserved by source
> > control
> 
> Ok noted, but I don't have commit access and my Mercurial Kung Fu is rusty.

That's ok, hg allows you to set who the patch is from. With good settings it get's set automatically. See https://developer.mozilla.org/en-US/docs/Creating_a_patch_that_can_be_checked_in

Once the patch has the needed reviews, set the checkin-needed and someone will check it in for you.
For future reference, remember to set the review flag, or your patch risks just sitting there. (I'll do it now.)

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch#Getting_the_patch_reviewed
Attachment #8423456 - Flags: review?(mkmelin+mozilla)
Attachment #8423456 - Attachment is obsolete: true
Attachment #8423456 - Flags: review?(mkmelin+mozilla)
Attachment #8424123 - Flags: review?(mkmelin+mozilla)
Hey Magnus. No problem. Just added the functionally equivalent patch as before, but exported with Mercurial metadata from a local commit as per your MDN link.
Comment on attachment 8424123 [details] [diff] [review]
fix-broken-printing-eml-files.patch

Review of attachment 8424123 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay, please fix the below and i'll take another look (faster)

::: AUTHORS
@@ +242,5 @@
>  Kevin Gerich <kevin@kmgerich.com>
>  Kevin Puetz <puetzk@iastate.edu>
>  Kin Blas <kin@netscape.com>
>  Kipp Hickman <kipp@netscape.com>
> +Kip Warner <kip@thevertigo.com>

please skip this, the file is legacy

::: mail/components/shell/nsMailGNOMEIntegration.cpp
@@ +111,5 @@
>    // the locale encoding.  If it's not set, they use UTF-8.
>    mUseLocaleFilenames = PR_GetEnv("G_BROKEN_FILENAMES") != nullptr;
>  
> +  // Attempt to repair broken desktop MIME association on GNU systems...
> +  #ifdef MOZ_ENABLE_GIO

I'm surprised ifdef not at start of the line even compiles, anyhow, it should be the first thing on the line.

@@ +119,5 @@
> +
> +    // Query for all applications registered with the problematic MIME type...
> +
> +      // The problem MIME type...
> +      const char *problem_mime = "application/x-extension-eml";

indention odd, here and below

@@ +123,5 @@
> +      const char *problem_mime = "application/x-extension-eml";
> +
> +      // Query system...
> +      GList *eml_applications_list = g_app_info_get_all_for_type(problem_mime);
> +      //const guint length = g_list_length(eml_applications_list);

remove uncommmented stuff

@@ +142,5 @@
> +        // Try again...
> +        user_mimeapps_config = g_build_filename(
> +          g_get_user_data_dir (), "applications", "mimeapps.list", nullptr);
> +        MOZ_ASSERT(g_file_test(user_mimeapps_config, G_FILE_TEST_EXISTS));
> +      }

this whole block is also wrongly indnted

@@ +179,5 @@
> +      const char *desktop_id = g_app_info_get_id(current_app_info);
> +      MOZ_ASSERT(desktop_id);
> +
> +      // This doesn't look like us...
> +      if (g_strcmp0(program_name, current_app_executable) != 0) 

remove trailing space

@@ +216,5 @@
> +        // Check each value (application) in the list registered on the key
> +        //  (problem MIME) to find ourselves so we can remove us and rebuild a
> +        //  new list...
> +        for (gsize old_value_index = 0 ; 
> +             old_value_index < old_length; 

remove trailing spaces, and there should be no space before ;

@@ +232,5 @@
> +            // Do not preserve it...
> +            continue;
> +          }
> +
> +          // Preserve everything else in the user's third party application 

trailing space

@@ +234,5 @@
> +          }
> +
> +          // Preserve everything else in the user's third party application 
> +          //  registration back on the MIME type...
> +          new_values[old_value_index - (old_length - new_length)] = 

trailing whitespace

@@ +240,5 @@
> +        }
> +
> +        // Write back to disk...
> +
> +          // They had other stuff registered on the problem MIME, so save 

trailing whitespace
and here indention jumps again

@@ +242,5 @@
> +        // Write back to disk...
> +
> +          // They had other stuff registered on the problem MIME, so save 
> +          //  that...
> +          if(new_length > 0)

space after if

@@ +258,5 @@
> +        g_strfreev(new_values);
> +      }
> +    }
> +
> +    // Save...

indention jumps after this
Attachment #8424123 - Flags: review?(mkmelin+mozilla) → review-
Hey Magnus. No problem. I'm just away on leave until Thursday inclusive and I'll get right to this and have it all done for you probably Friday (6 June). Take care buddy.
Attachment #8424123 - Attachment is obsolete: true
Hey Magnus. Please check this revised patch. Hopefully this is the final iteration, as I must split my time between many other bugs.
Please don't forget to flag patches for review, they are easily missed...
Sure thing Magnus. For future reference, I set the review flag to '+' and use (at least in this case) your user name?
No, you set it to ? and my email address. Once it gets review, I mark it + (or - if not yet accepted)
https://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree#Getting_the_patch_reviewed
Attachment #8437128 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8437128 [details] [diff] [review]
fix-broken-printing-eml-files.patch

Review of attachment 8437128 [details] [diff] [review]:
-----------------------------------------------------------------

I think i'm basically happy, but let's see what philip says. I'm not all that into c++

::: mail/components/shell/nsMailGNOMEIntegration.cpp
@@ +143,5 @@
> +      MOZ_ASSERT(g_file_test(user_mimeapps_config, G_FILE_TEST_EXISTS));
> +    }
> +
> +    // Used for checking status of file I/O...
> +    bool status = false;

might as well declare this where it's first used

@@ +159,5 @@
> +    // Go through the list of applications registered for the problematic
> +    //  MIME type, each time checking if we found ourselves...
> +    for (GList *list_node = g_list_first(eml_applications_list);
> +        list_node != nullptr;
> +        list_node = g_list_next(list_node)) {

indention if off, you should align as
 Glist
 list_node != ...
 list_node

@@ +177,5 @@
> +      const char *desktop_id = g_app_info_get_id(current_app_info);
> +      MOZ_ASSERT(desktop_id);
> +
> +      // This doesn't look like us...
> +      if (g_strcmp0(program_name, current_app_executable) != 0)

use standard strcmp, like Philip said

@@ +180,5 @@
> +      // This doesn't look like us...
> +      if (g_strcmp0(program_name, current_app_executable) != 0)
> +        continue;
> +
> +      // Issue a warning...

yeah this comment is not necessary...

@@ +224,5 @@
> +          // Check if this is us. If so, skip it...
> +          if (g_strcmp0(current_value, desktop_id) == 0)
> +          {
> +            // Remember that the new list is one less...
> +          --new_length;

please indent (two more spaces)
Attachment #8437128 - Flags: review?(philip.chee)
Comment on attachment 8437128 [details] [diff] [review]
fix-broken-printing-eml-files.patch

> 
I think i'm basically happy, but let's see what philip says. I'm not all that into c++
A. I'm not all that into C++ either
B. Not a Thunderbird peer (These files are TB shell service specific)
C. I suggest mconley or irving,
Attachment #8437128 - Flags: review?(philip.chee)
Attachment #8437128 - Flags: review?(mconley)
Attachment #8437128 - Flags: review?(irving)
Fixed, as per Magnus' request.
Attachment #8437128 - Attachment is obsolete: true
Attachment #8437128 - Flags: review?(mkmelin+mozilla)
Attachment #8437128 - Flags: review?(mconley)
Attachment #8437128 - Flags: review?(irving)
Attachment #8437926 - Flags: review?(mkmelin+mozilla)
Attachment #8437926 - Flags: review?(philip.chee)
Attachment #8437926 - Flags: review?(mkmelin+mozilla)
Attachment #8437926 - Flags: review?(mconley)
Attachment #8437926 - Flags: review?(irving)
Ok hopefully this is the final iteration gentlemen, as I have many other bugs I need to focus on in my queue =)
I'm very much not a GNOME specialist. In fact, my C++ is only marginal. I'm going to bring in a specialist (karlt) to comment on this while I take a look at the patch.

karlt, care to comment?
Flags: needinfo?(karlt)
Hey :) I wouldn't call myself a GNOME specialist.
I'm not familiar with what this file has been doing.
I suggest checking the history for the person who added "eml" to sAppTypes and
asking them for review.

But here are some questions.  Answers would help explain the need for this
patch.

Why does registering a desktop application for 
("message/rfc822", "eml") conflict with an existing
message/rfc822 eml association in mime.types?
i.e. Why is this a problem for cups filters?

I'm a bit surprised that cups even knows or cares that this file ends in .eml.  I would have expected Thunderbird to send postscript or pdf to the print system.

Where did "application/x-extension-eml" come from?
Is this a freedesktop convention to register .eml extensions?
Does GIO add this when adding an entry for .eml?

It would be helpful to have a comment in the removal code to explain that
Thunderbird added such entries in the past (if that is the case).

If Thunderbird added these entries, and that was wrong, then the approach of
only removing Thunderbird entries for "eml" seems appropriate.

I would have expected GIO to have an API that let GIO find the appropriate
config file(s) for altering, given GIO has methods such as
g_app_info_set_as_default_for_extension().
Flags: needinfo?(karlt)
(In reply to Karl Tomlinson (needinfo?:karlt) from comment #37)
> Hey :) I wouldn't call myself a GNOME specialist.
> I'm not familiar with what this file has been doing.

Hey Karl. No problem. There might be others who feel the same way and who might benefit from whatever answers I can come up with.

> Why does registering a desktop application for 
> ("message/rfc822", "eml") conflict with an existing
> message/rfc822 eml association in mime.types?
> i.e. Why is this a problem for cups filters?

I think you might find an answer to that in my comments in lines 55 to 75.

> I'm a bit surprised that cups even knows or cares that this file ends in
> .eml.  I would have expected Thunderbird to send postscript or pdf to the
> print system.

That makes two of us =)

> Where did "application/x-extension-eml" come from?

I have no idea, but it isn't really necessary since RFC822 data shouldn't be restricted to .eml extensions, regardless of what the system CUPS filter rule might be.

> Is this a freedesktop convention to register .eml extensions?

As far as I know, that was a strictly Thunderbird construct, and one that wasn't necessary. The association should have been to RFC822, with that being detected however the system CUPS filter rules are setup as.

> Does GIO add this when adding an entry for .eml?

Nope.

> It would be helpful to have a comment in the removal code to explain that
> Thunderbird added such entries in the past (if that is the case).

I had that, but Magnus requested I remove that in comment #17. 

> If Thunderbird added these entries, and that was wrong, then the approach of
> only removing Thunderbird entries for "eml" seems appropriate.

Yes, that is what my patch attempts to do.
Hardware: x86_64 → All
Comment on attachment 8437926 [details] [diff] [review]
fix-broken-printing-eml-files.patch

Review of attachment 8437926 [details] [diff] [review]:
-----------------------------------------------------------------

I don't know anything about GNOME desktop integration either, so I can't speak to the correctness of the changes being made to the MIME binding. At the C++ level, I'd like to see more run-time error handling instead of MOZ_ASSERT, and there are a couple of places where I wasn't sure about the memory management.

::: mail/components/shell/nsMailGNOMEIntegration.cpp
@@ +139,5 @@
> +      user_mimeapps_config = g_build_filename(g_get_user_data_dir(),
> +                                              "applications",
> +                                              "mimeapps.list",
> +                                              nullptr);
> +      MOZ_ASSERT(g_file_test(user_mimeapps_config, G_FILE_TEST_EXISTS));

MOZ_ASSERT (a) crashes the application if the assertion fails and (b) doesn't execute the test in non-DEBUG builds. Why do you want to ASSERT on the existence of this file?

@@ +150,5 @@
> +      user_mimeapps_config,
> +      static_cast<GKeyFileFlags>(
> +        G_KEY_FILE_KEEP_COMMENTS | G_KEY_FILE_KEEP_TRANSLATIONS),
> +      nullptr);
> +    MOZ_ASSERT(status);

Again, MOZ_ASSERT crashes the application, but only in DEBUG builds. I'd prefer to see run-time error handling logic around this (and most of the other failures in the code you're adding) rather than MOZ_ASSERT.

(for example, in this case if the file exists but is not readable, you could end up with a program that always crashes)

@@ +167,5 @@
> +      //  Note that we have to do this rather than use the application name
> +      //  because it could be "Thunderbird" in some cases, "Thunderbird Mail",
> +      //  or yet something else in other cases...
> +      const char *current_app_executable =
> +        g_app_info_get_executable(current_app_info);

Once again, the GNOME docs don't say whether or not this string needs to be g_free()ed.

@@ +171,5 @@
> +        g_app_info_get_executable(current_app_info);
> +
> +      // We'll also need the application desktop ID for later...
> +      const char *desktop_id = g_app_info_get_id(current_app_info);
> +      MOZ_ASSERT(desktop_id);

Again, please double-check whether this needs g_free(). Also, since it can legitimately be NULL, we shouldn't MOZ_ASSERT on it (http://www.freedesktop.org/software/gstreamer-sdk/data/docs/2012.5/gio/GAppInfo.html#g-app-info-get-id)
Attachment #8437926 - Flags: review?(irving) → review-
Kip, just wanted to check if you are still working on this? (If not, I'd be up for trying my hand at it..)
Flags: needinfo?(kip)
Hey buddy. Unfortunately I don't have time right now, but you are welcome to go at it and adapt my patch if necessary. Good luck man.
Flags: needinfo?(kip)
Comment on attachment 8437926 [details] [diff] [review]
fix-broken-printing-eml-files.patch

I think irving's r- makes sense.
Attachment #8437926 - Flags: review?(philip.chee)
Attachment #8437926 - Flags: review?(mconley)
I've been failing at parsing the bigger patch myself.  On the other hand, we do have a simple fix to make this not affect any new users.
Assignee: kip → gQuigs+bugs
Attachment #8510428 - Flags: review?(mconley)
Comment on attachment 8510428 [details] [diff] [review]
stop_breaking_eml_printing.patch

Resetting reviewer to Magnus because it shows Mike as a lot of reviews in his queue.
Attachment #8510428 - Flags: review?(mconley) → review?(mkmelin+mozilla)
Comment on attachment 8510428 [details] [diff] [review]
stop_breaking_eml_printing.patch

Review of attachment 8510428 [details] [diff] [review]:
-----------------------------------------------------------------

Yes I think this is good. r=mkmelin

The workaround is fairly simple (though one obviously have to know about it): just remove lines with application/x-extension-eml=thunderbird.desktop from ~/.local/share/applications/mimeapps.list
Attachment #8510428 - Flags: review?(mkmelin+mozilla) → review+
Attachment #8437926 - Attachment is obsolete: true
Summary: can't print .eml files - print preview remains blank → Print/Print preview of .eml files shows blank on linux - don't add wrong file association to ~/.local/share/applications/mimeapps.list
I added a comment in the code and landed this.

https://hg.mozilla.org/comm-central/rev/0dad46359315 -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 36.0
For future reference, let's spell out that we didn't fix existing installations...
Whiteboard: [not fixed for existing installations: workaround see comment 45; see wip patch attachment 8437926]
Whiteboard: [not fixed for existing installations: workaround see comment 45; see wip patch attachment 8437926] → [not fixed for existing installations: workaround see comment 45]
Magnus: No problem. Eventually someone else who has more time than us can circle back to adjusting my patch, if needed, so that we can solve this issue for existing installations (sadly, probably most people who use Thunderbird).
You need to log in before you can comment on or make changes to this bug.