You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Justin Mclean <ju...@classsoftware.com> on 2014/02/13 02:21:29 UTC
TLF timeout
Hi,
Managed to reproduce a TLF timeout simply. This may be an edge case but I can think of a few case where you have small text fields and could run into this.
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx">
<!-- Slowly slde down to zero to reproduce bug - can happen when about 2 or 3 characters wide -->
<mx:Slider id="vslider" minimum="0" maximum="100" value="100" />
<s:TextArea width="{vslider.value}" text="Apache Flex TLF bug"/>
</s:Application>
While trying to fix In looking I just came across this in StandardFlowComposer.
private function updateCompositionShapes():void
{
for each (var controller:ContainerController in controller)
controller.updateCompositionShapes();
}
Should that be "in _controllerLists"? No idea what a for each (var a in a) would even do.
Thanks,
Justin
Re: TLF timeout
Posted by Alex Harui <ah...@adobe.com>.
Keep looking. I'm pretty sure there is at least one more that has the svn
rev # of when I did put in the fix. Or try searching the logs. I'm
pretty sure it is in the branch we donated. It was pretty invasive and
risky.
-Alex
On 2/12/14 8:50 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>:
>
>> Yup, that scrollbar thing as been around forever. There should be some
>> existing bugs on it.
>
>Like this one:
>https://issues.apache.org/jira/browse/FLEX-33295
>
>Any chance of obtaining that fix you mention in there?
>
>I tried a simple count how many times updateDisplayList is called in
>ScrollerLayput and give up after 3 successive calls - which worked fine
>for RichText and Scroller (all test passed) but seem to break
>DropDownLists.
>
>Justin
Re: TLF timeout
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
:
> Yup, that scrollbar thing as been around forever. There should be some
> existing bugs on it.
Like this one:
https://issues.apache.org/jira/browse/FLEX-33295
Any chance of obtaining that fix you mention in there?
I tried a simple count how many times updateDisplayList is called in ScrollerLayput and give up after 3 successive calls - which worked fine for RichText and Scroller (all test passed) but seem to break DropDownLists.
Justin
Re: TLF timeout
Posted by Alex Harui <ah...@adobe.com>.
Yup, that scrollbar thing as been around forever. There should be some
existing bugs on it.
On 2/12/14 8:27 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> Well, in general, the framework doesn't protect much against bad inputs.
>
>It setting the width to 20-30 that causes the issue not 0, I'd not call
>that a bad input and it can happen at other width and text lengths as
>well it just that this manages to reproduce the issue easily enough.
>
>It turns out it's actually a spark scrollbar issue. It tries to add one
>then other find both don't fit, so removes one and gets caught in an
>endless loop.
>
>Thanks
>Justin
Re: TLF timeout
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Well, in general, the framework doesn't protect much against bad inputs.
It setting the width to 20-30 that causes the issue not 0, I'd not call that a bad input and it can happen at other width and text lengths as well it just that this manages to reproduce the issue easily enough.
It turns out it's actually a spark scrollbar issue. It tries to add one then other find both don't fit, so removes one and gets caught in an endless loop.
Thanks
Justin
Re: TLF timeout
Posted by Alex Harui <ah...@adobe.com>.
Well, in general, the framework doesn't protect much against bad inputs.
Setting TextArea's width to 0 could be considered that, but we usually try
to let width and height be 0 because effects often cause that to happen.
So, it might be worth fixing, maybe just by detecting 0 and not doing
anything.
-Alex
On 2/12/14 5:21 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>Managed to reproduce a TLF timeout simply. This may be an edge case but I
>can think of a few case where you have small text fields and could run
>into this.
>
>
><?xml version="1.0" encoding="utf-8"?>
><s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
> xmlns:s="library://ns.adobe.com/flex/spark"
> xmlns:mx="library://ns.adobe.com/flex/mx">
>
> <!-- Slowly slde down to zero to reproduce bug - can happen when about 2
>or 3 characters wide -->
> <mx:Slider id="vslider" minimum="0" maximum="100" value="100" />
> <s:TextArea width="{vslider.value}" text="Apache Flex TLF bug"/>
></s:Application>
>
>
>While trying to fix In looking I just came across this in
>StandardFlowComposer.
>private function updateCompositionShapes():void
> {
> for each (var controller:ContainerController in controller)
> controller.updateCompositionShapes();
> }
>
>Should that be "in _controllerLists"? No idea what a for each (var a in
>a) would even do.
>
>Thanks,
>Justin
>
>
RE: TLF timeout
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>private function updateCompositionShapes():void
> {
> for each (var controller:ContainerController in controller)
> controller.updateCompositionShapes();
> }
Hmm. That's fun. It will end up doing nothing. Since the scope of controller isn't specified, the compiler will resolve both of those references to the same local variable and hoist it to the top of the function. So, when it gets to the first line of the loop, 'controller' will be undefined and the loop will never execute.
It would, however, work if it were rewritten as:
private function updateCompositionShapes():void {
for each (var controller:ContainerController in this.controller)
controller.updateCompositionShapes();
}
(Assuming controller is actually in the this scope, I didn't look)
Mike