with mozilla 20010417 I read a mail (no html) with a link to a pdf file in it. when i click on that link, the acrobat plugin is loaded and the file showed in the mail text window other links are shown in a browser window

I experienced this problem as well on Build 2001050104 on Mac OS 9.1.

Marking NEW.

Just verified with 2001073103 The bug still exists. And worse. While the plugin shows the pdf-file in the mail-window below the headers, it is impossible to use the menu bar. Menus do not pop up. Only solution is to change too another mail.

*** Bug 95655 has been marked as a duplicate of this bug. ***

*** Bug 109208 has been marked as a duplicate of this bug. ***

This is still the behavior on build 2001110803 Win32 Nightly

*** Bug 110197 has been marked as a duplicate of this bug. ***

platform/OS should be All/All ... same under MacOS...

build 2001112013 Had a mail with an pdf-attachment. Kontext-Menu-> open -> opened via acroread-plugin in mail-text-area. No way back to the original text, than selecting a different mail and then back to the mail with the attachment. Maybe-workaround: remove plugin, use acroread as helper-application. Should be a way to go back to original text...

*** Bug 117677 has been marked as a duplicate of this bug. ***

*** Bug 118095 has been marked as a duplicate of this bug. ***

this makes it difficult to read PDF's sent as attachments, nominating nsbeta1

*** Bug 131209 has been marked as a duplicate of this bug. ***

Discussed at Mail News bug meeting with Engineering, QA Mktng and PjM. Decided to minus this bug.

In the 2002032203 build, a PDF attachment that is rightclicked and then "opened" downloads, but NO PDF file appears either in the mail window or in a browser window. No Borwser window appears (if there is none open). Even worse, Mozilla then hangs! It is quite unresponsive to anything and must be killed from the Task Manager.

Wondered if this bug could be looked at for machV as its a definate usuability problem that would effect many office workers, a main target of machV

*** Bug 145753 has been marked as a duplicate of this bug. ***

This happens at other times like in AIM windows too, see: http://bugzilla.mozilla.org/show_bug.cgi?id=4693 -->peterl, taking bug in hope of coming up with a fix

This happens at other times like in AIM windows too, see: http://bugzilla.mozilla.org/show_bug.cgi?id=4693 -->peterl, taking bug in hope of coming up with a fix

-->mine

sorry, that last bug URL should be to Bugscape: http://bugscape.mcom.com/show_bug.cgi?id=4693 Joe has posted a patch there to set the base target on the document in the AIM chat window to be "_blank". I think I may have a similar solution coming up for mail.

I set the target on the load group to open in a new window before the DocShell opens the URL. This causes us to always open any kind of attachment in a new window but does not accidentally cause 2 windows for the current working cases. This patch is to mail/news so can someone more familiar with that code can tell me if this is the right thing to do.

getting into the 1.0 milestone

We need to get this reviewed and super reviewed before this can be approved. Can you make sure that someone in mail reviews this. After that, please add the adt1.0.0 back to the keywords. It'll be great to have this fixed.

qa:trix

how does this affect clicking on links to mail folders or newsgroups inside mail messages?

Comment on attachment 84576 [details] [diff] [review] patch to set _blank target on loadgroups needs work: fails the case if we are opening a helper application like an attached EXE. We get an extra browser window then. :(

Hm...strange. With the patch, the links to mail folers inside message will appear in a new window. Without the patch, nothing happens and I get an error: The link to imap://peterlub@peterl.mcom.com/Drafts was blocked by the security manager. Remote content may not link to local content.

This is on the trunk? I thought Karen just verified that this worked on the trunk. Argh.

re-assign back to mail/news since I think the fix might be in that module.

I applied this patch to the trunk - for imap, at least, it has no effect. the pdf doc still loads in the message pane, but links to imap folders load correctly without loading a browser window. Has all the testing been done with local/pop messages?

the imap part of the patch only affects loading an attached mime part, so it wouldn't have any effect on clicking on a link inside an imap message.

With that patch, I get an extra window when clicking on attachments that are EXE's or something else handled by helper applications.

this is a dup of 110729, which Scott has been looking into. *** This bug has been marked as a duplicate of 110729 ***

Wait a minute -- bug 110729 seems to address the problem of ATTACHMENTS in e-mail messages. The summary of this bug is dealing with LINKS to certain documents in e-mail messages. The circumstances under which I've found this bug were not attachments at all.

reopen. that bug deals with attachments, this one with links

this has to be fixed by whatever is done to fix bug 110729 - the approach taken in the proposed fix for this bug will not work w/o breaking lots of other things. You can't fix just the attachment case w/o fixing the link case. For example, if I save a .txt attachment from a mail message with the above patch, it opens a blank browser window! re-resolving. I'll go add a comment to the other bug to make sure that clicking on a pdf link is also tested. *** This bug has been marked as a duplicate of 110729 ***

*** Bug 153227 has been marked as a duplicate of this bug. ***

verified dup

*** Bug 160839 has been marked as a duplicate of this bug. ***