[NP_FULL] NPP_GetURLNotify() does not resolve relative URLs correctly (for Flash)

VERIFIED FIXED in mozilla1.0



16 years ago
16 years ago


(Reporter: cpeterson, Assigned: Peter Lubczynski)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Workaround in place in Flash 6])


(4 attachments)



16 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!

Comment 1

16 years ago
Created attachment 65851 [details]
Flash movie that tries to load another Flash movie using a relative URL

Comment 2

16 years ago
Created attachment 65852 [details]
HTML page that loads the first Flash movie

Comment 3

16 years ago
Created attachment 65853 [details]
Flash movie that is loaded by the first Flash movie


16 years ago
Ever confirmed: true

Comment 4

16 years ago
Similar to bug 118003, but this if full-page mode with NPN_GetURL()
Assignee: av → peterl
Priority: -- → P2
Hardware: PC → All
Summary: NPP_GetURLNotify() does not resolve relative URLs correctly if Flash plugin is loaded with NP_FULL mode → [NP_FULL] NPP_GetURLNotify() does not resolve relative URLs correctly (for Flash)

Comment 5

16 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.
Depends on: 90256
Keywords: 4xp, mozilla1.0
Whiteboard: [Workaround in place in Flash 6]
Target Milestone: --- → mozilla1.0

Comment 6

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

Comment 7

16 years ago
Created attachment 68619 [details] [diff] [review]
patch to create empty document

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?

Comment 8

16 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.
Attachment #68619 - Flags: review+

Comment 9

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

Forgot: r=av

Comment 10

16 years ago
Patrick, can I get a super review?
Keywords: patch, review
Target Milestone: mozilla1.0 → mozilla0.9.9

Comment 11

16 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?
Attachment #68619 - Flags: superreview+

Comment 12

16 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.
Last Resolved: 16 years ago
Resolution: --- → FIXED


16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 13

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

Comment 14

16 years ago
You need to log in before you can comment on or make changes to this bug.