Closed Bug 284963 Opened 20 years ago Closed 9 years ago

When clicking on a ASX link, Firefox does not return to the refering page from blank page (Windows Media Player)

Categories

(Plugins Graveyard :: Windows Media Player (Microsoft), defect)

Product:
Plugins Graveyard
Component:
Windows Media Player (Microsoft)
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: damo, Unassigned)

References

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.6) Gecko/20050226 Firefox/1.0.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.6) Gecko/20050226 Firefox/1.0.1 This is happening on a site I am developing, which currently requires user/pass to access. I can provide this access on email request. When clicking on a ASX link, Firefox does not return to the referring page. A webpage has a link to http://www.something.com/myvideo.asx, when clicking this link Firefox stays on the ASX page which is a blank page with http://www.something.com/myvideo.asx in the URL box. Media player loads the ASX successfully. Firefox 1.0 handeled this correctly as does IE6. Reproducible: Always Steps to Reproduce: 1.Create a webpage with a link for a valid .asx file 2.Click the link in Firefox 1.0.1 Actual Results: Firefox loads a white blank page with the URL for the ASX file in the address bar Expected Results: Firefox should have retured to the referring page when the ASX link was clicked.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 This can be worked around by disabling the ASX plug-in handler, clicking on an asx file and then accepting the presented option in the open file dialog. It is then added to the file type handler window. Not sure why this should behave differently though...
I agree that does work. As a web developer though this is causing a problem as I try to create sites that work correctly on all browsers.
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/
Problem is still present in version 1.0.6. No changes is problem.
*** Bug 285319 has been marked as a duplicate of this bug. ***
JavaScript Console shows: Security Error: Content at http://foo/bar.asx may not load or link to file:///C:/DOCUME~1/xxx/LOCALS~1/Temp/5ju6232.htm. Workaround: Change ASX from Plugin to "Open with default application" etc in Options -> Downloads -> View & Edit Actions. This is probably Windows only. Mac build doesn't contain ASX in "View & Edit Actions". regression. marking new.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: When clicking on a ASX link, Firefox does not return to the refering page. → When clicking on a ASX link, Firefox does not return to the refering page from blank page (Windows Media Player)
As of version 1.5.0.3 this bug is still evident. I have had emails from a number of people complaining about it. Any chance of a fix in V 2.0?
The Windows Media Plugin (npdsplay.dll) creates a temporary html file with the following content: <html><script>window.history.go(-2);</script></html> Because of the checkloaduri security restriction, that script is not allowed to execute and the browser will not return to the page on which the link was opened.
This problem has been dogging us for a while on our government website. It still exists on Firefox 1.5.0.7. We have been forced to open a new browser window for each ASX file otherwise we are concerned that users will reach a blank page and not know what to do. This is not ideal and we would prefer to keep the user in the existing window. We cannot expect all users to change their preferences for ASX file handling. Fixing this problem is very important to us. Note that the symptoms we experience are identical to those described here: security warning accessing a temporary file in the Javascript console.
(Sorry, filed this comment on a dupe). This bug is still evident in 2.0 I run a large media site (www.radionz.co.nz), and I get complaints about this often. We try to make it simple for people to play these files, and as such cannot recommend they switch to firefox. Yet. But we'd like to. Any chance of a fix in the near future? Thanks.
Same problem exists in Seamonkey. Moving to core.
Assignee: bugs → file-handling
Product: Firefox → Core
QA Contact: ali → ian
Version: unspecified → Trunk
Flags: blocking1.9?
This appears to be a regression caused by the check-in for bug 280664.
Blocks: 280664
Assignee: file-handling → nobody
Component: File Handling → Plug-ins
QA Contact: ian → plugins
I verified by backout that this is indeed triggered by the code checked in to fix bug 280664. So, this leads to the question, is there a way to fix this to work as desired that does not compromise security and does not involve having to modify the Windows Media Player plug-in?
It seems that Opera does not have this issue using the same versions of both the Flash plug-in and Windows Media Player plug-ins. This would seem to imply that either Opera has managed to resolve this issue, or Opera still suffers from the vulnerability that was patched in Mozilla via bug 280664. For what it's worth, I determined that only the nsPluginHostImpl::PostURL part of the patch for bug 280664 needed to be reverted to avoid this issue.
Flags: blocking1.9? → blocking1.9-
One workaround is to force download dialog on the server side by using Content-Disposition header. For example if you are using Apache 2 and module mod_headers is enabled then adding the following code to .htaccess forces download dialog for .asx files. <IfModule mod_mime.c> # Windows Media AddType video/x-ms-asf asf asx AddType audio/x-ms-wma wma AddType audio/x-ms-wax wax AddType video/x-ms-wmv wmv AddType video/x-ms-wvx wvx AddType video/x-ms-wm wm AddType video/x-ms-wmx wmx AddType application/x-ms-wmz wmz AddType application/x-ms-wmd wmd </IfModule> <IfModule mod_headers.c> <Files "*.asx"> SetEnvIf Request_URI "/([^/]*)$" IT=$1 header set Content-Disposition "attachment; filename=\"%{IT}e\" </Files> </IfModule>
Is there a IIS workaround?
I'm just an old timer having fun building my little website. I have the same issue on my site with .wmv files. Implementing the server code above is beyond the scope of my capability. I noticed this post: POST: The Windows Media Plugin (npdsplay.dll) creates a temporary html file with the following content: <html><script>window.history.go(-2);</script></html> Because of the checkloaduri security restriction, that script is not allowed to execute and the browser will not return to the page on which the link was opened. My question: Does this mean there is an incompatibility between WMP and Firefox? This issue does not occur using IE or Opera 9.02 and my instructor is a Mac user and she is unable to reproduce the issue on her end. My next observation: POST: For what it's worth, I determined that only the nsPluginHostImpl::PostURL part of the patch for bug 280664 needed to be reverted to avoid this issue. Me Again: It sure would be great to see this issue resolved on Mozilla Firefox's end. I don't have a lot of traffic to my site but I have received complaints also. (from my friends) My music videos are important to me. I also have a link in my header recommending a Firefox download (Best Viewed in Mozilla Firefox)because it renders my CSS correctly. I'll be watching to see how this issue resolves. Best of luck to you. Thanks, gasquetdwayne My original POST: Posted: 22 Mar 2007 09:52 am Bug 374938 has been added to the database I recently finished three xhtml courses and have completely redone my website. So far I love everything about the way Firefox renders css. I do however have one issue I have been unable to resolve. On my Music Videos page, when you click on a link, not only does Media Player open, the Firefox browser goes to a page with the same URL as the video that the link points to. This results in having to use the back button to return to the Music Videos page. I am not using any target functions/behaviors or any open-window functions/behaviors with these links. I have read some of the support forums and I have been in the Options/Content/Manage File Types dialog boxes. This does not seem to be an issue with IE or MAC browsers. I just finished downloading Firefox 2.0.0.3 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3) but the issue remains. Is this issue happening on your end. You can view my code here: http://www.smartestspecies.com/videos.htm I would really appreciate any assistance in my efforts to resolve this issue.
I'd like to nominate this as a blocker for FF 3.0
Component: Plug-ins → Windows Media Player (Microsoft)
Flags: blocking1.9-
Product: Core → Plugins
QA Contact: plugins → microsoft-wmp
Version: Trunk → unspecified
Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/ If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.