Closed Bug 110729 Opened 24 years ago Closed 23 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: 23 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: 23 years ago → 23 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: