|
|
|
[
Permlink
| « Hide
]
P T Withington - 20/Jun/07 01:13 PM
To verify
In swf, you don't always get each error reported as a 403. Something you get a warning,
WARNING: featured_bg_edit.png (loaded).returnData: featured_bg_edit.png (loaded) already loaded In dhtml, no errors or warnings are generated. Hmm, I wonder if this broke when the dataprovider stuff went in. I can reproduce the test case, I am looking at it now.
Note: There are the following cases, which really go through 24 different code paths. The tests in test/lfc/data cover
only the normal load cases. We need to add regression tests to the suite to cover the error and timeout cases as well. SWF SOLO PROXIED data load normal data load error data load timeout media load normal media load error media load timeout DHTML SOLO PROXIED data load normal data load error data load timeout media load normal media load error media load timeout Here is the bug, in proxied mode: The LPS server returns an "eror" swf, which instead of containing an image asset, contains
a call to "returnData" with an error message as it's data. The LzMediaLoader receives this 'error' swf, but doesn't know it's an error, so calls returnData which marks the resource as loaded. The error swf itself calls back to returnData as well, but some code changed since LPS 3.x, and it ignores the second call to returnData, which would normally fire the onerror event. I have a patch, am testing it now. Note that in SOLO mode, we really don't get any indication of a failure to load; the loadMovie just returns, regardless of any HTTP error from the server. So the best we can do in that case is timeout :-( r6975 | hqm | 2007-10-23 16:05:36 -0400 (Tue, 23 Oct 2007) | 54 lines
Changed paths: M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/swf/LzLoadQueue.as M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/swf/LzLoader.lzs Change 20071023-hqm-8 by hqm@IBM-2E06404CB67 on 2007-10-23 12:09:47 EDT in /cygdrive/c/users/hqm/openlaszlo/trunk/WEB-INF/lps/lfc for http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc Summary: fix to report errors in media loading New Features: Bugs Fixed: Technical Reviewer: max QA Reviewer: pbr Doc Reviewer: Documentation: Release Notes: Details: In the case of a server media error, the media loader calls returnData twice, once when the image swf is loaded (normal path), and the error swf itself calls returnData. That second call was being ignored by returnData because it ignored any loader which was marked as loaded. This fix adds a check for non-null data, and if so, returns it. Tests: test/lfc/data/testhttpdata.lzx test/lfc/data/alldata.lzx This should report an error immediately in proxied mode <canvas width="100%" height="80%" debug="true"> <debug fontsize="12"/> <view resource="http://www.javawen.info/try/news_bg.png" onload="Debug.write('onload', this)" ontimeout="Debug.write('ontimeout', this)" onerror="Debug.write('onerror', this)" /> </canvas> The testcase doesn't work in 3.x. Did it ever work? Is this a regression or a new feature?
Whenever this line was added to LzLoader , probably is what broke it
// Check if returnData has already been called on this // object. This can happen if a serverless data load timed out in // the LFC, but eventually returned something via the // LoadVars.sendAndLoad() callback. if (loadobj.loaded) { if ($debug) { Debug.warn("%w.returnData: %w already loaded", this, loadobj); } return; } I tried svn blame but this must go back to when things were in perforce... Correct testcase in original description, see below (missing "/"):
<canvas debug="true"> <view resource="http://www.javawen.info/try/bg.jpg"/> <view resource="http://www.javawen.info/try/border.png"/> <view resource="http://www.javawen.info/try/featured_bg.png"/> <view resource="http://www.javawen.info/try/featured_bg_edit.png"/> <view resource="http://www.javawen.info/try/news_bg.png"/> </canvas> <canvas width="100%" height="80%" debug="true">
<debug fontsize="12"/> <view resource="http://www.javawen.info/try/news_bg.png" onload="Debug.write('onload', this)" ontimeout="Debug.write('ontimeout', this)" onerror="Debug.write('onerror', this)" /> </canvas> (local wafflecone build r7136 - cranberry RC)
This doesn't appear to be the correct behavior described in the bug. I would think that the error should be in both swf and dhtml. Also the warnings, are these ok? I get the same behavior on XP/FF, XP/IE6 and OS X/FF. I get the following error in swf (expected) onload «MovieClip#0| global» ERROR: data source error for http://www.javawen.info/try/news_bg.png: HTTP Status code: 403:Forbidden onerror «lz.view#2» I get the following when I run it in dhtml: DEBUG: Source warnings enabledWARNING: testing:0: Test source warning onload «Window(0)#0| global» onerror «lz.view#1» I get the following compiler warnings in dhtml and swf: 4099.lzx:8:3: attribute "onload" not allowed at this point; ignored 4099.lzx:8:3: attribute "ontimeout" not allowed at this point; ignored 4099.lzx:8:3: attribute "onerror" not allowed at this point; ignored 4099.lzx:8:3: found an unknown attribute named "onload" on element view, check the spelling of this attribute name The above results are from running the testcase below:
<canvas width="100%" height="80%" debug="true"> <debug fontsize="12"/> <view resource="http://www.javawen.info/try/news_bg.png" onload="Debug.write('onload', this)" ontimeout="Debug.write('ontimeout', this)" onerror="Debug.write('onerror', this)" /> </canvas> There are some changes from trunk that have not been merged to wafflecone which are required in order
to compile view with onload, ontimeout, or onerror attributes <view onload="...." ontimeout=... onerror="..."/> without warnings Basically all the new schema stuff needs to go in for that to work. However, the warnings in the test case are independent of the issue in this bug, which is whether or not
the onerror event is properly sent at runtime when a media load error occurs. (trunk4 local build r7183)
The compiler warnings do not happen in trunk builds. The changes needed to get the compiler warnings to stop are too risky for the wafflecon/cranberry/4.0.7 release. Basically all the new schema stuff needs to go into wafflecone for that to work. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||