Closed Bug 110729 Opened 23 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.3alpha

People

(Reporter: mh, Assigned: bugzilla)

References

Details

(Keywords: intl, Whiteboard: [PL RTM][adt2][ish1+])

Attachments

(2 files, 1 obsolete file)

Proposed fix, v1
4.00 KB, patch
Details | Diff | Splinter Review
patch v.2
1.54 KB, patch
bugzilla
: review+
beard
: superreview+
Details | Diff | Splinter Review 
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.
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.
No, unchecking "Apply default to all messages" does not help. I tried a lot of
combinations, the error stays the same.
*** Bug 113221 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 111567 has been marked as a duplicate of this bug. ***
This might be a similar problem as the mail startup page bug 59787, cc to mscott.
Keywords: intl
fix for bug 112904 was just checked in. Related?
Bug http://bugzilla.mozilla.org/show_bug.cgi?id=112904 is not related.

Checked with build 2001120908 for Windows.


reassigning to ducarroz
Assignee: sspitzer → ducarroz
Target Milestone: --- → mozilla1.2
Status: NEW → ASSIGNED
*** Bug 125258 has been marked as a duplicate of this bug. ***
I have the same problem in Mozilla 0.9.9 on Windows 2000.
Very annoying for everyone using more US-ASCII, I suspect.
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
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
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.)  Thanks!
*** Bug 136337 has been marked as a duplicate of this bug. ***
*** Bug 138293 has been marked as a duplicate of this bug. ***
I just verified that this applies to Linux as as well (Mozilla 1.0 RC1)
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.
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?
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...
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!
*** Bug 141691 has been marked as a duplicate of this bug. ***
same append if you open a tiff attachment which get openend using the QuickTime
plugin.
*** Bug 142996 has been marked as a duplicate of this bug. ***
*** Bug 143217 has been marked as a duplicate of this bug. ***
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.
*** Bug 144124 has been marked as a duplicate of this bug. ***
*** Bug 76416 has been marked as a duplicate of this bug. ***
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]
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.
*** Bug 76416 has been marked as a duplicate of this bug. ***
*** Bug 148750 has been marked as a duplicate of this bug. ***
Discussed in Mail News bug meeting.  Decided to keep the minus on this bug. 
Also removing redundant nsbeta1 descriptor.
Keywords: nsbeta1
*** Bug 148761 has been marked as a duplicate of this bug. ***
*** Bug 155549 has been marked as a duplicate of this bug. ***
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).
*** Bug 152254 has been marked as a duplicate of this bug. ***
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.

OS->All, per comment #37. Wondering if east asian users are also seeing this (I
mean the wrong codepage issue).
OS: Windows 98 → All
*** Bug 158397 has been marked as a duplicate of this bug. ***
*** Bug 157090 has been marked as a duplicate of this bug. ***
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).
*** Bug 161262 has been marked as a duplicate of this bug. ***
nominate nsbeta1
Keywords: nsbeta1- → nsbeta1
*** Bug 161521 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 11744 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
I edited a wrong bug, sorry.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I have a solution for that problem, but I don't know if it will be accepted...
I'll post the patch later.
Attached patch Proposed fix, v1 — — Splinter Review 
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.
Attached patch patch v.2 — — Splinter Review 
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.
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.
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
*** Bug 163438 has been marked as a duplicate of this bug. ***
*** Bug 153482 has been marked as a duplicate of this bug. ***
*** Bug 165406 has been marked as a duplicate of this bug. ***
*** Bug 162608 has been marked as a duplicate of this bug. ***
*** Bug 165659 has been marked as a duplicate of this bug. ***
*** Bug 164379 has been marked as a duplicate of this bug. ***
*** Bug 169621 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [PL RTM] → [PL RTM][adt2]
Target Milestone: M3 → mozilla1.3alpha
Blocks: 157673
*** Bug 173701 has been marked as a duplicate of this bug. ***
reassigning to ducarroz.
Assignee: mscott → ducarroz
Status: REOPENED → NEW
*** Bug 174575 has been marked as a duplicate of this bug. ***
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!
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.
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.
Whiteboard: [PL RTM][adt2] → [PL RTM][adt2][ish1+]
*** Bug 177882 has been marked as a duplicate of this bug. ***
*** Bug 178875 has been marked as a duplicate of this bug. ***
*** Bug 170507 has been marked as a duplicate of this bug. ***
Attached patch Proposed fix, v3 (obsolete) — — Splinter Review 
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
Attachment #94692 - Attachment is obsolete: true
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
Comment on attachment 94692 [details] [diff] [review]
patch v.2

R=ducarroz
Attachment #94692 - Attachment is obsolete: false
Attachment #94692 - Flags: review+
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 on attachment 94692 [details] [diff] [review]
patch v.2

sr/rs=beard
Attachment #94692 - Flags: superreview?(beard) → superreview+
Fix checked in. Thanks av for your help.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Blocks: 180372
No longer blocks: 157673
removed nsbeta1
Keywords: nsbeta1+
some how one of the line of the patch did not make it and caused bug 181576!
*** Bug 182603 has been marked as a duplicate of this bug. ***
*** Bug 183293 has been marked as a duplicate of this bug. ***
*** Bug 183851 has been marked as a duplicate of this bug. ***
*** Bug 184985 has been marked as a duplicate of this bug. ***
*** Bug 185481 has been marked as a duplicate of this bug. ***
*** Bug 187967 has been marked as a duplicate of this bug. ***
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.
*** Bug 189448 has been marked as a duplicate of this bug. ***
*** Bug 191733 has been marked as a duplicate of this bug. ***
*** 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. ***
V fixed
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: