Flash relative URL redirection does not work correctly

VERIFIED FIXED in Future

Status

()

Core
Plug-ins
P3
major
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: bugzilla, Assigned: av (gone))

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [HAVE FIX][NEED CODE REVIEW][nsbeta3+], URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.

Comment 1

18 years ago
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

18 years ago
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.

Comment 3

18 years ago
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().

Comment 4

18 years ago
*** Bug 42039 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
adding 4xp, flash and nsbeta3 keywords
Keywords: 4xp, flash, nsbeta3

Comment 6

18 years ago
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.
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future

Comment 7

18 years ago
Created attachment 12563 [details] [diff] [review]
proposed fix - uses doc url rather than plugin content url to create absolute url

Comment 8

18 years ago
removing nsbeta3 status from whiteboard per last comment
adding patch keyword
Keywords: patch
Whiteboard: [nsbeta3-]

Updated

18 years ago
OS: Linux → All
(Reporter)

Updated

18 years ago
Hardware: PC → All

Comment 9

18 years ago
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.

Comment 10

18 years ago
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]

Comment 12

18 years ago
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+]
(Assignee)

Comment 14

18 years ago
r=av, as per our conversation Sean is going to get this in.

Comment 16

18 years ago
patch checked in
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 17

18 years ago
verified on windows/linux/mac builds that this is working fine now. 
(build:2000090606m18)

Comment 18

18 years ago
*** 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.