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)
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).
Comment 1•23 years ago
|
||
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
| Reporter | ||
Comment 2•23 years ago
|
||
By changing the bug report to MailNews, did this alert the appropriate people?
Thanks.
Updated•21 years ago
|
Product: MailNews → Core
Comment 3•20 years ago
|
||
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/
Comment 4•20 years ago
|
||
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
Updated•18 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•