Consider the root directory of a website with the following layout: +-- index.html +--+ flash/ +-- movie.swf +--+ user/ +-- index.html Now consider that the file index.html embeds the file flash/movie.swf. In turn, the file flash/movie.swf issues a redirect to the relative URL user/index.html. In all other browsers, the movie redirection yields a URL like `user/index.html'. In Mozilla (build id 200080113), the movie redirection will yield a URL like `flash/user/index.html'. You can go to http://www.themusicchannel.nl to see the problem. The site will load a flash movie and attempt to redirect to `http://www.themusichannel.nl/user/index.php3'. Instead, under Mozilla, it redirects to `http://www.themusicchannel.nl/flash/user/index.php3', which yields a "File not found" error.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is failing because the plugin content is in a different directory than the page in which it is embedded. In nsObjectFrame.cpp, nsPluginInstanceOwner::GetURL() calculates the absolute URL of a GetURL() request (since the request might be a relative URL). It determines the baseURL by calling mOwner->GetFullURL(baseURL). That returns the baseURL of the plugin content rather than the baseURL of the page the plugin is embedded in. It does seem that absolute URL of a relative URL should be calculated from the baseURL of the html page rather than the URL of the plugin content.
Maybe nsPluginInstanceOwner::GetURL() should use logic similar to that which was added to nsPluginHostImpl::NewPluginURLStream() to calculate an absolute url for a plugin stream using the document url. Or the logic should be moved out of NewPluginURLStream() into nsPluginHostImpl::GetURL() and nsPluginHostImpl::PostURL(). Or nsPluginHostImpl should get a new method which does the resolution and it should be called from both GetURL() and PostURL().
*** Bug 42039 has been marked as a duplicate of this bug. ***
adding 4xp, flash and nsbeta3 keywords
Keywords: 4xp, flash, nsbeta3
Denying approval for beta3: not critical for release. We'll get back to it when we have time. Sean, if you have a fix please attach the patch and clear the [nsbeta3-] from the status whiteboard and we will re-assess. Thanks.
Target Milestone: --- → Future
Created attachment 12563 [details] [diff] [review] proposed fix - uses doc url rather than plugin content url to create absolute url
removing nsbeta3 status from whiteboard per last comment adding patch keyword
This is a problem with relative URLS in general and has nothing to do with plugins. My home page http://www.enteract.com/~egstern has a link <a href="baby.html"> Here are drawings by my children </a> which is supposed to give full url http://www.enteract.com/~egstern/baby.html but when I click on it it instead is trying to find url http://www.enteract.com/baby.html which is not found.
Eric, you should file a separate bug for that (or see if there is a dupe of it). This bug (47840) is in plugin specific code and has nothing to do with html links. The attached patch fixes the problem stated in the summary.
Let's review Sean's patch and take it if we think it's low-risk and solves the problem. This issue could break lots of sites that use Flash and would be a major headache for Flash developers; we'd be forcing them to reorganize their content directory structures if they wanted to support Netscape 6. Flash is one of the three most widely-used plug-ins on the web. Marking [HAVE FIX][NEED CODE REVIEW].
Whiteboard: [HAVE FIX][NEED CODE REVIEW]
Adding nsbeta3+ to status field.
Whiteboard: [HAVE FIX][NEED CODE REVIEW] → [HAVE FIX][NEED CODE REVIEW]nsbeta3+
Correcting nsbeta3+ to [nsbeta3+].
Whiteboard: [HAVE FIX][NEED CODE REVIEW]nsbeta3+ → [HAVE FIX][NEED CODE REVIEW][nsbeta3+]
r=av, as per our conversation Sean is going to get this in.
patch checked in
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
verified on windows/linux/mac builds that this is working fine now. (build:2000090606m18)
*** Bug 52127 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.