[#LPP-4462] When running a SOLO SWF in an HTML file located in a different directory than the SWF, data requests are made relative to SWF, not HTML file

OpenLaszlo

When running a SOLO SWF in an HTML file located in a different directory than the SWF, data requests are made relative to SWF, not HTML file

Created: 08/Aug/07 06:20 PM Updated: 10/Aug/07 03:35 PM

Component/s:

Laszlo Foundation Classes (LFC)

Affects Version/s:

3.4, 4.0.5WaffleCone

Fix Version/s:

4.0.5WaffleCone, 3.4

Time Tracking:

Not Specified

File Attachments:

loadtest.zip (103 kb)

Severity:	Minor
Runtime:	N/A
Fix in hand:	False

Description

« Hide

When a wrapper HTML file is located in a separate directory than the SWF that it loads, any http requests should be made relative to the HTML file, not the SWF. In this test case, the data request is actually made relative to the SWF file's location, while other requests, e.g. setSource("img.jpg"), are made relative to the HTML file.

In my test case, the HTML file is located in the directory above the .lzx/.swf file:
<embed src="loadtest/loadtest.lzx.swf" ...

When the SWF is embedded in this HTML file, the data path must be relative to the SWF file:
dsTestData.setSrc("testdata.xml");

And the JPG request must be relative to the HTML file:
img.setSource("loadtest/img.jpg");

Both requests should be relative to the HTML file.

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

kathryn aaker - 08/Aug/07 06:20 PM

A test case as described in the bug report

[ Permlink | « Hide ]

Henry Minsky - 09/Aug/07 08:46 PM

The SOLO data loading path eventually calls LzBrowser.toAbsoluteURL on its arg, which resolves relative to
LzBrowser.getLoadURL, which is effectively the directory in which the app's .swf file resides.

The SOLO media loading path does not do this, and the load ends up being issued by the browser relative to
the wrapper page.

We can either make the SOLO load coerce to absolute URL using the same call

1) LzLoadQueue.loadMovieProxiedOrDirect = function (loadobj) {
    var reqstr;
    if ( !loadobj.proxied ) {
        reqstr = LzBrowser.toAbsoluteURL(loadobj.reqobj.url, false);

or else,

2) remove the toAbsoluteURL call in the LzLoadQueue.loadXMLDirect method:

  // reqstr = _root.LzBrowser.toAbsoluteURL( url, loadobj.secure );
would become
reqstr = url;

But in this case we would also need to compute the absolute media load URL which is sent
in the proxied case as properly relative to the HTML wrapper location, rather than using toAbsoluteURL

LzLoadQueue.loadMovieProxiedOrDirect = function (loadobj) {
    var reqstr;
    if ( !loadobj.proxied ) {
        reqstr = LzBrowser.toAbsoluteURL(loadobj.reqobj.url, false);
        Debug.write("LzLoadQueue.loadMovieProxiedOrDirect reqstr=", reqstr);
    } else {

        delete loadobj.proxied;
        reqstr = _root.LzBrowser.getBaseURL( loadobj.secure,
                                                 loadobj.secureport ).toString();
        //fix up URL
        var url = loadobj.reqobj.url;
        if ( url != null) {
            // [2005 03 10] we don't try to munge URLs to HTTPS anymore,
            // the user specifies the URL protocol explicitly if they want https.
  >>>>> loadobj.reqobj.url = _root.LzBrowser.toAbsoluteURL(url, false);
        }

[ Show » ]

Henry Minsky - 09/Aug/07 08:46 PM The SOLO data loading path eventually calls LzBrowser.toAbsoluteURL on its arg, which resolves relative to LzBrowser.getLoadURL, which is effectively the directory in which the app's .swf file resides. The SOLO media loading path does not do this, and the load ends up being issued by the browser relative to the wrapper page. We can either make the SOLO load coerce to absolute URL using the same call 1) LzLoadQueue.loadMovieProxiedOrDirect = function (loadobj) { var reqstr; if ( !loadobj.proxied ) { reqstr = LzBrowser.toAbsoluteURL(loadobj.reqobj.url, false); or else, 2) remove the toAbsoluteURL call in the LzLoadQueue.loadXMLDirect method: // reqstr = _root.LzBrowser.toAbsoluteURL( url, loadobj.secure ); would become reqstr = url; But in this case we would also need to compute the absolute media load URL which is sent in the proxied case as properly relative to the HTML wrapper location, rather than using toAbsoluteURL LzLoadQueue.loadMovieProxiedOrDirect = function (loadobj) { var reqstr; if ( !loadobj.proxied ) { reqstr = LzBrowser.toAbsoluteURL(loadobj.reqobj.url, false); Debug.write("LzLoadQueue.loadMovieProxiedOrDirect reqstr=", reqstr); } else { delete loadobj.proxied; reqstr = _root.LzBrowser.getBaseURL( loadobj.secure, loadobj.secureport ).toString(); //fix up URL var url = loadobj.reqobj.url; if ( url != null) { // [2005 03 10] we don't try to munge URLs to HTTPS anymore, // the user specifies the URL protocol explicitly if they want https. >>>>> loadobj.reqobj.url = _root.LzBrowser.toAbsoluteURL(url, false); }

[ Permlink | « Hide ]

Max Carlson - 10/Aug/07 03:35 PM

Fixed in 5999 for wafflecone, 5996 in 3.4