Chris Peterson [:cpeterson] Reporter
	Description • 23 years ago

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
BuildID:    2002012008

The Flash Player plugin uses NPP_GetURLNotify() to load other files. If a 
Flash .swf movie is loaded from a URL pointing to a .html page (plugin mode 
NP_EMBED), the Flash Player can load other files using relative URLs. However, 
if the Flash .swf movie is loaded with a URL pointing directly to the .swf file 
(plugin mode NP_FULL), then relative URLs do not work. Mozilla seems to forget 
to add the .swf file's current directory when resolving the relative URL. If 
the Flash movie uses an absolute URL, it can load the other files.



Reproducible: Always
Steps to Reproduce:
Here is a real example from Macromedia's Flash QA lab. The 
movie "embedtextmain.swf" tries to load a second movie "loadedembedded.swf" 
from the same directory by just using its filename. If embedtextmain.swf is 
loaded by the HTML file embedtextmain.html in the same directory, then 
NPP_GetURLNotify("loadedembedded.swf") successfully finds and loads the second 
movie. However, if embedtextmain.swf is loaded with a URL the points directly 
to the .swf file, then NPP_GetURLNotify("loadedembedded.swf") fails. I can 
include these test files, if necessary to reproduce the bug.



Actual Results:  Relative URLs do not work in NPP_GetURLNotify() from plugin 
mode NP_FULL.

Expected Results:  Relative URLs should work like they did in Netscape 4, even 
in NP_FULL mode.

Netscape 6.1 and 6.2 on Mac and Windows also have this same problem. 
NPP_GetURLNotify() in Netscape 4.03, 4.78, and 4.79 correctly resolve relative 
URLs using the current directory. Therefore, this is a feature the worked in 
Netscape 4, but is broken in Netscape 6 and Mozilla.

I've added a workaround to the Flash 6 Player so that if the plugin mode is 
NP_FULL, then the Flash 6 Player will manually try to change Flash movie's 
relative URL requests to absolute URLs using the .swf file location before 
passing the URL to NPP_GetURLNotify(). However, Flash 5 movies will still be 
broken in Netscape 6 and Mozilla!

	Peter Lubczynski
	Comment 4 • 23 years ago

Similar to bug 118003, but this if full-page mode with NPN_GetURL()

	Peter Lubczynski
	Comment 5 • 23 years ago

The problem here is that in |nsPluginHostImpl::NewPluginURLStream|, we are not
able to resolve the relative URL. This is done by fetching the document from 
nsIPluginInstanceOwner and then resolving the URL. The problem here is that
full-page plugins don't get a document. :( 

One possible way to solve this is to just fix bug 90256, taking the approach of
creating a synthetic document for full-page plugins. As a side-effect of fixing
that bug, this one should be fixed as well. Marking depends for now.

Maybe a quicker way to fix this would be to add another method to the
nsIPluginInstanceOwner interface that would just directly get the document's
URL. Each implementation (full/embeded) would then be able to do the right thing
and we can get the URL from the channel in nsPluginViewer. 

However, I think it'd be better just to get rid of the second, partially
implemented, nsIPluginInstanceOwner and just have one code path.

	Peter Lubczynski
	Comment 6 • 23 years ago

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

	Peter Lubczynski
	Comment 7 • 23 years ago

Here's a patch that I think can get us by without bug 90256 and without
changing any interfaces. 

Andrei/Patrick, what do you think?

	av (gone)
	Comment 8 • 23 years ago

Comment on attachment 68619 [details] [diff] [review]
patch to create empty document

I think this is OK for now, but we probably should file a new bug on removing
this workaroung after bug 90256 is fixed.

	av (gone)
	Comment 9 • 23 years ago

Comment on attachment 68619 [details] [diff] [review]
patch to create empty document

Forgot: r=av

	Peter Lubczynski
	Comment 10 • 23 years ago

Patrick, can I get a super review?

	Patrick C. Beard
	Comment 11 • 23 years ago

Comment on attachment 68619 [details] [diff] [review]
patch to create empty document

hmm, simple enough. will this document contain a DOM and basic script support?
sr=beard

	Peter Lubczynski
	Comment 12 • 23 years ago

patch in trunk, marking FIXED

The dummy document created isn't hooked up to anything. It would require more
work to make it scriptable from the DOM.

	rubydoo123
	Comment 13 • 22 years ago

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

	shrirang khanzode
	Comment 14 • 22 years ago

.