If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Attachment displayed by plugin should not open in the message display frame (and codepage is affected).

VERIFIED FIXED in mozilla1.3alpha

Status

SeaMonkey
MailNews: Message Display
VERIFIED FIXED
16 years ago
13 years ago

People

(Reporter: !Mike, Assigned: Jean-Francois Ducarroz)

Tracking

({intl})

Trunk
mozilla1.3alpha
x86
All

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL RTM][adt2][ish1+])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

If I open an english pdf file (inline) from message 1, then view the german
message 2, the german message 2 has a wrong character coding for special chars:

Text in german message 2:
 before: "welche Version würde"
 after : "welche Version würde"

Settings stay the same. If I change the character coding to unicode (UTF-8)
afterwards, the german special chars are ok again. This would have to be done
for all messages.

Restart of the mail-client fixes the probem.

Reproducible: Always


Steps to Reproduce:

Settings:
Folder character coding: Western (ISO-8859-1)
Apply default to all messages: Yes

Message 1:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Message 2:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

1. View english PDF inline
2. Switch to a message with german special characters

Seems like this problem only apears if something has been viewed "inline". I
cannot remember, but I think it is not limited to pdf`s. I think there where
some mails with non-local codings that produced the same thing.

Comment 1

16 years ago
Can't reproduce with 2001112104/Win95, when browsing greek ISO8859-7 messages
immediately after a western ISO8859-1 message with pdf attachment (whether pdf
is opened or not).

>Folder character coding: Western (ISO-8859-1). Apply default to all messages: Yes

This might be the root of your problems. Applying default to all messages
("charset override") ignores the MIME charset information of any incoming
message. Uncheck "Apply default to all messages" (or change default to unicode
UTF-8) and report what you see. Pdf could not be relevant, I think.
(Reporter)

Comment 2

16 years ago
No, unchecking "Apply default to all messages" does not help. I tried a lot of
combinations, the error stays the same.

Comment 3

16 years ago
*** Bug 113221 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

16 years ago
*** Bug 111567 has been marked as a duplicate of this bug. ***

Comment 5

16 years ago
This might be a similar problem as the mail startup page bug 59787, cc to mscott.
Keywords: intl

Comment 6

16 years ago
fix for bug 112904 was just checked in. Related?
(Reporter)

Comment 7

16 years ago
Bug http://bugzilla.mozilla.org/show_bug.cgi?id=112904 is not related.

Checked with build 2001120908 for Windows.

Comment 8

16 years ago
reassigning to ducarroz
Assignee: sspitzer → ducarroz
Target Milestone: --- → mozilla1.2

Updated

16 years ago
Status: NEW → ASSIGNED

Comment 9

16 years ago
*** Bug 125258 has been marked as a duplicate of this bug. ***

Comment 10

16 years ago
I have the same problem in Mozilla 0.9.9 on Windows 2000.
Very annoying for everyone using more US-ASCII, I suspect.

Comment 11

16 years ago
this in fact is a very annoying bug for intl users, there is no way to correct
the display of mail body, and the next non-ascii mail would be displayed garbled
as well. The workaround is to close Acrobat, close mozilla, reopen.Can we
consider to fix it? Nominating , changing qa contact
Keywords: nsbeta1
QA Contact: esther → marina

Comment 12

16 years ago
Discussed in Mail News bug meeting with Engineering, QA, Mktng and PjM. 
Decision was to minus this bug.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.2 → mozilla1.0

Comment 13

16 years ago
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!

Comment 14

16 years ago
*** Bug 136337 has been marked as a duplicate of this bug. ***

Comment 15

16 years ago
*** Bug 138293 has been marked as a duplicate of this bug. ***

Comment 16

16 years ago
I just verified that this applies to Linux as as well (Mozilla 1.0 RC1)

Comment 17

16 years ago
The same problem is with Power Point Presentations. Instead of opening a PDF file 
open a PPS file and voila same problem as described with the PDF file.
(Assignee)

Comment 18

16 years ago
The problem comes from the fact the attachment is open directly into the mail
display frame using a plugin. The work around is to close the mail window and
reopen it, don't need to quit the whole application.

I don't think is a good idea anyway to open inline attachment using plugins when
available! Attachment should always be open into a different window or application.

mscott, any idea how I can force to use a new window when opening an attachment?

Comment 19

16 years ago
try making sure plugins aren't allowed in mail window docshells. I thought
someone recently added that to the UI but I can't find it. Look for the word
plugins in messenger\base...
(Assignee)

Comment 20

16 years ago
I am the one who have a patch to disable pluging support in message display. But
in that case, it's about forcing plugins to open a new window when opening an
attachment, that's different!

Comment 21

16 years ago
*** Bug 141691 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

16 years ago
same append if you open a tiff attachment which get openend using the QuickTime
plugin.

Comment 23

16 years ago
*** Bug 142996 has been marked as a duplicate of this bug. ***

Comment 24

16 years ago
*** Bug 143217 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 25

16 years ago
reassign to mscott who have a solution...
Assignee: ducarroz → mscott
Status: ASSIGNED → NEW
Summary: Mail message character coding wrong after view of pdf file. → Attachment displayed by plugin should not open in the message display frame.
(Assignee)

Comment 26

16 years ago
*** Bug 144124 has been marked as a duplicate of this bug. ***

Comment 27

16 years ago
*** Bug 76416 has been marked as a duplicate of this bug. ***

Comment 28

16 years ago
This bug is about full-page plugins (like ones ending in .SWF or .PDF) displayed
in the mail content area after clicking "Open" on the attachment. Embedded
plugins in an HTML page is another story.

attempting to nominate and adding tracking

I attached a patch to bug 76416 that sort of works:
http://bugzilla.mozilla.org/attachment.cgi?id=84576&action=view
It has the problem that an extra window appears for helper application
attachments like EXE's but browser handeled content is okay.
Keywords: mozilla1.0, nsbeta1
Whiteboard: [PL RTM]

Comment 29

16 years ago
Peter L. wrote:  "This bug is about full-page plugins (like ones ending in .SWF
or .PDF) displayed in the mail content area after clicking "Open" on the
attachment."

Then bug 76416 should not be marked as a duplicate of this bug as it deals with
LINKS to PDF documents in e-mail messages rather than attachments.  If the
underlying problem for this bug would also apply to that one, perhaps the
summary needs to be changed to reflect that both attachments and links are affected.

Comment 30

16 years ago
*** Bug 76416 has been marked as a duplicate of this bug. ***

Comment 31

16 years ago
*** Bug 148750 has been marked as a duplicate of this bug. ***

Comment 32

16 years ago
Discussed in Mail News bug meeting.  Decided to keep the minus on this bug. 
Also removing redundant nsbeta1 descriptor.
Keywords: nsbeta1

Comment 33

16 years ago
*** Bug 148761 has been marked as a duplicate of this bug. ***

Comment 34

16 years ago
*** Bug 155549 has been marked as a duplicate of this bug. ***

Comment 35

16 years ago
Updating summary a bit (although it's already too long). Many duplicates, I
think you must reconsider nsbeta1 (my opinion only).
Summary: Attachment displayed by plugin should not open in the message display frame. → Attachment displayed by plugin should not open in the message display frame (and codepage is affected).

Comment 36

16 years ago
*** Bug 152254 has been marked as a duplicate of this bug. ***

Comment 37

16 years ago
As you can see from the voters and comments, this is an important bug for
international users, but a very minor one for english-only users...

Someone "sufficiently empowered" should change OS to All, since there are many
sightings of this bug on Windows NT/2000, Linux etc.

Comment 38

16 years ago
OS->All, per comment #37. Wondering if east asian users are also seeing this (I
mean the wrong codepage issue).
OS: Windows 98 → All

Comment 39

16 years ago
*** Bug 158397 has been marked as a duplicate of this bug. ***

Comment 40

16 years ago
*** Bug 157090 has been marked as a duplicate of this bug. ***

Comment 41

15 years ago
I don't think this can be directly an Acrobat plug-in issue, because none of the
PDF problems (including the impossibility of saving a PDF file from certain
password-protected sites) exist in Netscape 4.79, and I am using exactly the
same plug-ins in that and in Mozilla.

All the problems are still there in Build No. 2002072508 (trunk).

Comment 42

15 years ago
*** Bug 161262 has been marked as a duplicate of this bug. ***

Comment 43

15 years ago
nominate nsbeta1
Keywords: nsbeta1- → nsbeta1

Comment 44

15 years ago
*** Bug 161521 has been marked as a duplicate of this bug. ***

Comment 45

15 years ago

*** This bug has been marked as a duplicate of 11744 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 46

15 years ago
I edited a wrong bug, sorry.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Assignee)

Comment 47

15 years ago
I have a solution for that problem, but I don't know if it will be accepted...
I'll post the patch later.
(Assignee)

Comment 48

15 years ago
Created attachment 94649 [details] [diff] [review]
Proposed fix, v1

I added a new attribute in nsIDocShell to allow to display plugin in full page
mode: allowFullPagePlugins. This new attribute is independent of the existing
attribute for allowing plugin in general (so far works only for embedded
plugin).

I have alse fixed a crash in nsPluginViewer due to the fact mNextStream is not
initialized to null. We crash in the case we created and destroy right away the
plugin viewer.

Comment 49

15 years ago
Created attachment 94692 [details] [diff] [review]
patch v.2

Good catch in nsPluginViewer.cpp!

I don't think we need to introduce a new attribute to a docshell just to inform
the docshell itself that this is a message pane. There must be a way to
determine this from within the docshell, although I am not sure how. The patch
follows this approach. Someone who knows docshell well please tell if just
querrying for the name is sufficient.

Another thing we need to do is not to throw the OpenFile dialog but rather try
to launch plugin if it is available in a separate browser window in a full-page
mode, like we do with images.
(Assignee)

Comment 50

15 years ago
I like this solution! we still need to make sure it will work too when
displaying message in a stand alone window.

If we want to be able to open the pluging in a new window, I thing we need to
work on the docshell side.

Comment 51

15 years ago
This is still not the right solution. All the action should happen in newly
created docshell, not in the message pane one. Somewhere in the code which opens
attachments we should recognize the fact that this content type is displayable
by a plugin and create a new window. I am not familiar with the mail code and
could not find the right place quickly, but I guess this should not be very
difficult.

The approach above can be considered as an interim solution, and stand alone
message window uses the same internal name "messagepane" so the patch will work.

mscott, if you need any help from the plugin team please bug me, I will be happy
to do so.
Target Milestone: mozilla1.0 → M3

Comment 52

15 years ago
*** Bug 163438 has been marked as a duplicate of this bug. ***

Comment 53

15 years ago
*** Bug 153482 has been marked as a duplicate of this bug. ***

Comment 54

15 years ago
*** Bug 165406 has been marked as a duplicate of this bug. ***

Comment 55

15 years ago
*** Bug 162608 has been marked as a duplicate of this bug. ***

Comment 56

15 years ago
*** Bug 165659 has been marked as a duplicate of this bug. ***
*** Bug 164379 has been marked as a duplicate of this bug. ***

Comment 58

15 years ago
*** Bug 169621 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [PL RTM] → [PL RTM][adt2]
Target Milestone: M3 → mozilla1.3alpha

Updated

15 years ago
Blocks: 157673

Comment 59

15 years ago
*** Bug 173701 has been marked as a duplicate of this bug. ***

Comment 60

15 years ago
reassigning to ducarroz.
Assignee: mscott → ducarroz
Status: REOPENED → NEW

Comment 61

15 years ago
*** Bug 174575 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 62

15 years ago
av, I disapprove your last comment. We load the attachment URL using the current
message display docShell (see
http://lxr.mozilla.org/seamonkey/source/mailnews/imap/src/nsImapService.cpp#677).
Then, we are asked if we can handle this kind of content-type, we always says NO
(see nsMsgWindow::IsPreferred at
http://lxr.mozilla.org/seamonkey/source/mailnews/base/src/nsMsgWindow.cpp). This
architecture works fine with any content-type (like image/jpeg, text/plain)
except when a plugin is able to handle it! In my understanding, the code for
handling plugings in nsDocumentOpenInfo::DispatchContent(...) doesn't do the
right thing!
(Assignee)

Comment 63

15 years ago
I can reproduce the same problem if the message body contains a link to a
document viewable by a plugin (PDF, Quick Time movie, etc...) and the user click
on it. Therefore changing the code that open attachment will not solve that issue.

Comment 64

15 years ago
That's actually the situation that has bitten me most of the time. For me,
attachments are more rare than links to pdf's etc.

Updated

15 years ago
Whiteboard: [PL RTM][adt2] → [PL RTM][adt2][ish1+]
*** Bug 177882 has been marked as a duplicate of this bug. ***

Comment 66

15 years ago
*** Bug 178875 has been marked as a duplicate of this bug. ***

Comment 67

15 years ago
*** Bug 170507 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 68

15 years ago
Created attachment 106059 [details] [diff] [review]
Proposed fix, v3

this fix is based on previous patch, this time it use a timer. I havn't tested
this patch on slow connection (I don't have one :-( ) but on broadband even
with large image (400K), I don't see a difference! same with previous patch.

Mike, do you have couple free cycle to test this patch? would be nice. Thanks
(Assignee)

Updated

15 years ago
Attachment #94692 - Attachment is obsolete: true
(Assignee)

Comment 69

15 years ago
Comment on attachment 106059 [details] [diff] [review]
Proposed fix, v3

this patch does not belong to this bug, please ignore it
Attachment #106059 - Attachment is obsolete: true
(Assignee)

Comment 70

15 years ago
Comment on attachment 94692 [details] [diff] [review]
patch v.2

R=ducarroz
Attachment #94692 - Attachment is obsolete: false
Attachment #94692 - Flags: review+
(Assignee)

Comment 71

15 years ago
Comment on attachment 94692 [details] [diff] [review]
patch v.2

Patrick, can you review this patch. This is a very important fix for mailnews.
Attachment #94692 - Flags: superreview?(beard)

Comment 72

15 years ago
Comment on attachment 94692 [details] [diff] [review]
patch v.2

sr/rs=beard
Attachment #94692 - Flags: superreview?(beard) → superreview+
(Assignee)

Comment 73

15 years ago
Fix checked in. Thanks av for your help.
Status: NEW → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Updated

15 years ago
Blocks: 180372
No longer blocks: 157673
removed nsbeta1
Keywords: nsbeta1+
(Assignee)

Comment 75

15 years ago
some how one of the line of the patch did not make it and caused bug 181576!

Comment 76

15 years ago
*** Bug 182603 has been marked as a duplicate of this bug. ***

Comment 77

15 years ago
*** Bug 183293 has been marked as a duplicate of this bug. ***
*** Bug 183851 has been marked as a duplicate of this bug. ***

Comment 79

15 years ago
*** Bug 184985 has been marked as a duplicate of this bug. ***
*** Bug 185481 has been marked as a duplicate of this bug. ***

Comment 81

15 years ago
*** Bug 187967 has been marked as a duplicate of this bug. ***

Comment 82

15 years ago
The bug is also present in 1.0.1 and 1.0.2 and it seems that the Acrobat Reader Plugin and the Quicktime plugin (maybe others as well) triggers this bad behaviour.

So, has the bug fix not been considered in 1.0.2 or has it to be reopened?

--- Complaints ---
To me it is a severe bug as I expect that my mailreader is capable to display correctly encoded mails. Sad, that this bug is over a year old and still not fixed. A mail client that cannot display mails correctly under all (normal) circumstances... sad.

Comment 83

15 years ago
*** Bug 189448 has been marked as a duplicate of this bug. ***
*** Bug 191733 has been marked as a duplicate of this bug. ***

Comment 85

15 years ago
*** Bug 192106 has been marked as a duplicate of this bug. ***
*** Bug 160061 has been marked as a duplicate of this bug. ***
*** Bug 178432 has been marked as a duplicate of this bug. ***

Comment 88

15 years ago
V fixed
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.