Closed Bug 211451 Opened 23 years ago Closed 20 years ago

Helper application won't run when a browser window open and do when closed.

Categories

(MailNews Core :: Attachments, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: commorancy, Assigned: sspitzer)

References

()

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 When I right-click open on an attachment (just so happens to be an audio/wav associated with /usr/bin/X11/realplay) in the email client with a browser window open, the browser comes forward, the URL changes to imap://... and attempts to open the attachment. 'Running helper ...' appears in the status, but the attachment never opens and the helper never runs. However, if all browser windows are closed with only the mail window open, the standalone open dialog requestor opens (I have always ask checked) and lets me type in the command and click open. The helper does open correctly. If I uncheck 'ask', clicking open downloads the file through download manager which then opens the helper and runs correctly. The browser appears to have trouble opening the helper application where neither the download manager nor the 'ask' requester do. Reproducible: Always Steps to Reproduce: Failure: 1. Open browser window 2. Open email that has attachment 3 [review]. Set audio/wav type to realplayer (wherever it's installed) 4. Make sure 'ask' is set to always from preferences 5. Right-click attachment and click open 6. Browser changes URL and says 'Running Helper ...' but helper never opens ask never pops up. Success: 1. Close browser window so mail client is only the window open. 2. Open email that has same attachment as above 3. Use same settings for audio/wav and same helper 4. Right-click open on attachment 5. 'Ask' requester opens. 6. Click 'Ok' if 'Open it with' area is correct (mine is correctly associated) 7. Helper opens, attachment plays in helper. Actual Results: Failure steps result in failure to open helper or play associated .wav attachment Success steps result in realplayer launching and .wav attachment playing Expected Results: I assume the browser is either trying to play the content through built-in means and is failing or is failing to launch realplayer. I can't exactly tell which. Is there a debug or log to check? Instead, since I already know that download manager and the ask requester both function properly, a browser window should not be reused to attempt to open the attachment. It shouldn't be used for the following reasons: 1) Reuse of windows should be a runtime option setable by the user. 2) Reuse of windows wipes out the current page of the window it chooses and, instead, puts up the imap:// URL. You can most times use 'back' to get back to the previous content (assuming that it is refreshable content and not a 'POST' that can't be cached). 3) Reuse of windows is inconvenient, and in this case, fails to launch the helper. 4) Instead of reusing, it should open a new window or tab instead and then fill that in with the URL. The browser should always open the 'Ask' requester when ask is set no matter what. If ask is not set and a helper is available, it should always use download manager to download the file and then launch the helper on the file using download manager. If ask is off and download manager is off, then this is probably the only time a browser window should be used (and it should be created rather than being reused).
Over to mailnews; sounds like they are doing something weird here... if they just sent the content down to the URIloader, things would "just work".
Assignee: law → sspitzer
Component: File Handling → Attachments
Product: Browser → MailNews
QA Contact: petersen → stephend
By changing the bug report to MailNews, did this alert the appropriate people? Thanks.
Product: MailNews → Core
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.