1.09 KB, application/octet-stream
724 bytes, text/html
26.68 KB, application/octet-stream
1.23 KB, patch
av (gone): review+
Patrick C. Beard: superreview+
|Details | Diff | Splinter Review|
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!
Created attachment 65851 [details] Flash movie that tries to load another Flash movie using a relative URL
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)
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
*** Bug 95394 has been marked as a duplicate of this bug. ***
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 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+
Patrick, can I get a super review?
Status: NEW → ASSIGNED
Keywords: patch, review
Target Milestone: mozilla1.0 → mozilla0.9.9
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
Attachment #68619 - Flags: superreview+
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 118715 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.