flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [1/2] git commit: [flex-sdk] [refs/heads/develop] - FLEX-33505: NumericStepper not updating on 'change'
Date Tue, 14 May 2013 16:55:27 GMT

On 5/14/13 9:33 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:

> Alex,
> I wasn't being negative at all. I meant literally what I said (keep in
> mind I'm not a native speaker): if you're going to test each commit
> and try to single handedly figure if it will survive every use case,
> you're going to have no time left to actually contribute new code and
> do PMC stuff.
Erik, all I do is scroll through the diff in a few seconds, and if something
catches my eye then I will stop and take a look.  Over many years in the
code, certain things like the word "commit" and "addEventListener" and
"stage" make me pay attention.

I have the luxury and privilege to spend all day on Flex.  I'm trying to
spend most of my time on new stuff like FlexJS because it is fun and
exciting, but I feel like there is still enough activity in the existing
Flex SDK to warrant spending time to make sure we don't inject issues that
prevent folks from switching to Apache Flex.  And I see it as my role to
tackle the nasty regressions like that ADG cursor issue that you looked at
earlier today that are just going to take too much of volunteer time.
> It was my understanding that a bug is considered fixed if it doesn't
> break prior tests and fixes the issue at hand. Am I wrong?
I think as a volunteer you are welcome to use your definition, but
unfortunately, even 30,000 mustella tests are not an exhaustive check of the
current code and don't pick up performance and memory leak issues, so that's
why I keep quickly scanning commits.  To me, if I spend a few seconds to
catch something before it goes out, it is the right use of my time.
> EdB
> On Tue, May 14, 2013 at 6:28 PM, Alex Harui <aharui@adobe.com> wrote:
>> Hi Erik,
>> I really appreciate the time and effort you are taking to fix bugs, but I do
>> try to review as every commit to make sure we don't introduce new issues.  I
>> sure hope someone is reviewing my commits.  I am not trying to find a
>> different or better way.  To me, this is similar to happening to see a
>> missing null check or a code path that can cause a memory leak.  And, I'm
>> trying to educate all committers on the past practices and philosophies of
>> the SDK development, although just because we used to do something a certain
>> way doesn't mean we still should.
>> I understand your time is limited and you are all volunteers.  If you don't
>> have any more time to spend on this issue, I will take the time to test to
>> see if there is a new and undesirable behavior with bound validators and
>> report back.
>> And thanks for at least taking the time to run mustella!
>> -Alex
>> On 5/14/13 9:16 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
>>> Alex,
>>> If you're going to check every commit and figure out a different way
>>> to do it, you're going to burn yourself out long before you get to
>>> finish FlexJS, man!
>>> I added the a change event handler to the Spark control and changed
>>> the change handler on the MX control. Mustella tests (240 something)
>>> for NumericStepper and the check-in tests all pass. I thought that
>>> meant that I didn't break existing functionality. Since the test case
>>> with this bug and some I wrote myself now function as intended, I
>>> figure I have done my due diligence and that my fix fixes the bug. I'm
>>> sure there are other (better!?) ways to do this, but this is what I've
>>> got.
>>> EdB
>>> On Tue, May 14, 2013 at 5:37 PM, Alex Harui <aharui@adobe.com> wrote:
>>>> Erik,
>>>> Thanks for looking into these issues.  I'm wondering if this is the right
>>>> fix, though.  I haven't actually pulled your changes, so I'm just looking
>>>> at
>>>> the diff.
>>>> It appears that this commit switches from a change event on enter to a
>>>> change event on every keystroke in the TextInput portion of the
>>>> NumericStepper.  If I didn't read it right, then ignore the rest of this
>>>> email.  My concerns are that this will trigger databinding on every
>>>> keystroke, and will trigger validators on every keystroke as well, which
>>>> could cause invalid results temporarily since many numbers may be out of
>>>> range as you type.  For example, if you wanted to enter "-1" the validator
>>>> may trigger as soon as you type '-'.
>>>> In reading the two bugs, it makes me think that something else is broken
>>>> regarding FLEX-33505.  As soon as the user clicked on something to dismiss
>>>> the popup, focus should have been lost which should have triggered a
>>>> FOCUS_OUT which should have caused the NS to commit its text.  The other
>>>> bug
>>>> also implies that NS is not handling FOCUS_OUT correctly, so maybe there
>>>> a fix needed in FOCUS_OUT handling.
>>>> I believe there are several places in the Flex SDK where a CHANGE event is
>>>> not dispatched from the component until you lose focus or hit ENTER so that
>>>> binding and validators don't fire so often.
>>>> If my understanding is correct, can you revisit this fix?
>>>> On 5/14/13 2:22 AM, "Erik de Bruin" <erik@ixsoftware.nl> wrote:
>>>>> Nice!
>>>>> EdB
>>>>> On Tue, May 14, 2013 at 11:15 AM, Justin Mclean
>>>>> <justin@classsoftware.com> wrote:
>>>>>> HI,
>>>>>> Actually not that one but I've probably fixed that myself :-)
>>>>>> Justin
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message