47840 - Flash relative URL redirection does not work correctly

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[bugzilla]

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

[Marc Langeveld]

*** This bug has been confirmed by popular vote. ***

Comment 2

[sean echevarria]

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

[sean echevarria]

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

[sean echevarria]

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

Comment 5

[sean echevarria]

adding 4xp, flash and nsbeta3 keywords

Comment 6

[Marc Attinasi]

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.

Comment 7

[sean echevarria]

Attachment: proposed fix - uses doc url rather than plugin content url to create absolute url

Comment 8

[sean echevarria]

removing nsbeta3 status from whiteboard per last comment
adding patch keyword

Comment 9

[Eric G. Stern]

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

[sean echevarria]

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.

Comment 11

[ekrock's old account (dead)]

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].

Comment 12

[karnaze (gone)]

Adding nsbeta3+ to status field.

Comment 13

[ekrock's old account (dead)]

Correcting nsbeta3+ to [nsbeta3+].

Comment 14

[av (gone)]

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

Comment 15

[Brendan Eich [:brendan]]

a=[e-mail]

/be

Comment 16

[sean echevarria]

patch checked in

Comment 17

[shrirang khanzode]

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

Comment 18

[sean echevarria]

*** Bug 52127 has been marked as a duplicate of this bug. ***