Here it is: http://www.openlaszlo.org/jira/browse/LPP-2131
Let me know if I can help any more. -Antun Antun Karlovac wrote: > This looks like a regression. I can reproduce it almost immediately in > lps-dev, and it's happening in lps-3.1.1. I've built lps-3.0, and I > cannot reproduce it there. > > I have to get a bunch of images together to so that I can put together a > test case. Will do soon. > > -Antun > > Antun Karlovac wrote: >> I can reproduce this very consistently even with a scaled down test >> case that includes nothing but: >> >> - Clipping view. >> - Lazily replicated set of views that load an image. >> - Scrollbar. >> >> I'm pretty sure this was never a problem in the past. I need to get >> some images that I can distribute before I can share this test case. >> >> -Antun >> >> Henry Minsky wrote: >>> Yep it sounds like the media loader is holding onto the two available >>> network connections and not releasing them. Which browser and OS are >>> you using? >>> The media loader has all sorts of logic to try to determine if the >>> image has >>> successfully loaded, but I can imagine some case that it gets >>> confused and thinks that the image has not loaded. In that case >>> though,the timeout is supposed to kick in and free up the connection >>> eventually. It sounds like things may be more wedged than that. >>> >>> >>> >>> >>> >>> On 6/2/06, *Antun Karlovac* <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> wrote: >>> >>> Hi Henry >>> >>> I'm working the issue myself; I have all the code locally. The >>> images >>> are coming from my local box, and I can see the responses come in >>> afterwards. >>> >>> The timeout is set to 5 seconds, so what the comment describes is >>> probably very relevant. Although I think there is another bug here >>> that's actually triggering the timeout (and hence the confusing >>> error >>> message). >>> >>> When quickly slowly scroll through a lazily-replicated list of items >>> that include run-time loaded images, the list works fine. However >>> when >>> you scroll quickly, the lockup happens, and no images load. >>> >>> I'm suspecting this is a media-loading a bug because the >>> lazily-replicated views are useless after this error happens. >>> Also the >>> debugger stops working; I can't eval code. >>> >>> I'm going to try to come up with a simpler test case that I can >>> share. >>> >>> -Antun >>> >>> Henry Minsky wrote: >>> > There's a comment in data/LzLoader: >>> > >>> > LzLoader.prototype.returnData = function ( loadobj , data ){ >>> > // 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; >>> > } >>> > >>> > What resource is the app loading? Is it possible it is getting an >>> error >>> > or timeout? >>> > Can the customer manually try to fetch the URL using wget or a >>> web >>> > browser with tracing on HTTP, and see what response is being >>> returned >>> > from the server? >>> > >>> > >>> > On 6/2/06, *Antun Karlovac* <[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]> >>> > <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>>> wrote: >>> > >>> > I'm seeing a bug in a customer's (SOLO) application where >>> once the >>> > following warning is reported: >>> > >>> > ---- >>> > WARNING: «LzMediaLoader#7| «MediaLoadObj#6| <FILENAME> >>> > (timedout)»».returnData: «MediaLoadObj#6| <FILENAME> >>> (timedout)» >>> > already >>> > loaded >>> > ---- >>> > >>> > When the warning(s) show up, the views that were supposed to >>> display >>> > runtime-loaded resources fail to attach them. All media >>> requests appear >>> > to fail after the error shows up. >>> > >>> > Has anyone got any clues as to what this error means, or >>> where it comes >>> > from? I've searched the source code tree, and that error does >>> not appear >>> > in there. >>> > >>> > Thanks, >>> > >>> > Antun >>> > _______________________________________________ >>> > Laszlo-dev mailing list >>> > [email protected] <mailto:[email protected]> >>> <mailto: [email protected] >>> <mailto:[email protected]>> >>> > http://www.openlaszlo.org/mailman/listinfo/laszlo-dev >>> > >>> > >>> > >>> > >>> > -- >>> > Henry Minsky >>> > Software Architect >>> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>> <mailto:[EMAIL PROTECTED] >>> <mailto:[EMAIL PROTECTED]>> >>> > >>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >>> >> _______________________________________________ >> Laszlo-dev mailing list >> [email protected] >> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
