Addressing Bugs in Flex

One of my primary functions as a Product Manager is to interact with the Flex community to make sure that the current product is meeting its needs and find out things we can be doing in the future to meet those needs even better. As we’ve moved Flex towards open source we’ve introduced additional infrastructure to help facilitate these kinds of interactions, most importantly the public bugbase. This has been a great mechanism for everyone to let us know what problems they’re facing as well as keep folks informed of what fixes are becoming available. I think it’s worked pretty well, but there are certainly some things that can be improved.

One difficulty for the community is finding a way to let Flex management know that the resolution of a bug is unsatisfactory. E.g., you cannot currently vote on deferred bugs, or if a bug is marked Not a Bug you have little recourse to have the bug re-opened. We do have plans to make sure you can vote on deferred bugs (in fact the implementation is waiting on a staging server, due to release timing we need to wait a little). We also need to implement some queries that will allow us to find bugs that have been commented on after their latest status change, which may indicate the need to revisit.You may recognize why I bring this up, Doug McCune had a pretty strongly-worded criticism on the behavior of the Panel class when its borderStyle was set to a non-default value. I think there are a few reasons why this ended up being frustrating and want to explore that a little.From the Adobe side, our attitude was that we never intended the behavior to work. However, this was not called out in Flex 2, so folks began to take advantage of untested behavior. When we formalized the lack of support in Flex 3 (and removed some hacks that we didn’t like), folks who were using what we considered unsupported behavior ran into issues. We marked the issue as Not a Bug and explained that we didn’t support those additional borderStyles. This may be fair enough if we’re working on something new right? The problem was that regardless of our own internal understanding of whether the behavior was supported, the fact of the matter was that it used to work and therefore reasonable people were relying on the behavior. What we internally might have considered a bug (Panel not rejecting unsupported styles) had become a feature for developers. We made a mistake in failing to recognize that the same bug was being filed multiple times by different people and therefore it was a behavior that multiple folks cared about having back. Folks might have understood (grudgingly) if we had marked the bug as Will Not Fix (because we’re mean, or out of time, or whatever). The Not a Bug status was being taken as an insult. So we needed to reconsider.We are at a point in Flex 3 where we do not consider fixes lightly and generally are now trying to avoid checking in more code. We admittedly only considered evaluating this situation because of the number of folks who seemed to make a statement on it (a bug that doesn’t affect a large number of people has very little chance of being addressed in the 3.0.0 release at this point). We also looked at what the fix would actually be. If we could have put a fix entirely in PanelSkin we probably would have posted the code on Doug’s blog, said “use this new skin” and been done with it. However we found that we did need to make a change in the Panel class which meant that a workaround was much harder for developers. After evaluating the risk of hurting other code we decided to check the fix in. So there you go, PanelSkin will support some of the non-default borderStyles now (and we’ll have to decide if this is now behavior that we need to support forever).So what recourse do you have if you think we’re dropping the ball on other issues? I mentioned a few things above about having voting on deferred issues and better querying that the management team can use to make sure we are paying attention to the community. Additionally when the open source infrastructure is live we will have a development list that can occasionally be used to make sure that the SDK developers are aware of an issue where it seems like it may be lost in the bug system. The final option of course is to contact a Product Manager (like me). My job is about making sure we’re doing the right thing. If you think things are messed up, let’s discuss (mchotin AT adobe DOT com).

9 Responses to Addressing Bugs in Flex

  1. Ben says:

    I have to say, its things like this that reinforce why I am an Adobe Flex developer, rather than a .NET/Java/[misc tech] developer. Can anyone imagine MS responding (at all, much less this quickly) to a blog post that basically cusses out their SDK team? Granted, all parties involved realize that Doug’s language is simply a result of his passion and carries no ill will, but I still can’t see most big corporations taking feedback seriously that comes in that format. This is awesome. Thank you Doug and thank you Flex Team, you’ve just reminded me (again) that I’ve made a great career choice.

  2. Doug McCune says:

    Matt,Please accept my “I Love You” teddy bear.🙂 Thanks for being so awesome (that goes to the whole team).Doug

  3. One issue I am running into in numerous Flex apps and widgets is navigateToURL(“url”,”_blank”)It is always caught by pop-up blockers in Firefox. This is not the case with the AS2.0 _getURLWhile there is a work-a-round using ExternalInterface it does NOT always work. One example is when you do not have control of the hosting environment and all Flash objects are embedded without allowScriptAccess=”always”. fact, while looking for work-a-rounds I stumbled upon this thread which mentioned it’d already been created as a bug. I was excited! Then read that it’d been deferred., I laughed my arse off when I discovered it had been my very own bug report. *lol*Of ALL the things I’d love Flex 3.0 to fix. This has got to be my #1. For a web development platform, something as simple as link in new browser should NOT require any work-a-rounds.

  4. I personally question this commitment to addressing bugs in the public bug database.The reason for my distrust is that I’ve had direct involvement with you (Matt) when trying to get a bug of mine re-opened. It was initially shut down because my steps to reproduce mentioned the RFC-2606 “” domain, and was quickly shut down again (by yourself) because the example code I posted compiled fine in Flex Builder (local security domain), which was completely outside the scope of my bug.Long story short, a bug with detailed steps to reproduce, sample code, and a developer willing to help troubleshoot the problem was shut down and ignored. This puts external bug reporters in the position where they need to kick and scream (in the case of Doug, to a wide audience) in order to get their reports dealt with. I’m at the point where I’m not really willing to do that any more.

  5. FYI, since the Flex 3 release, now the panel is worse than it was before. perhaps we should be careful not to try to please everybody all of the time.

  6. Matt says:

    Hi Harry,Have you filed a bug on the behavior change that you’ve seen?

  7. I just logged it here:’ve been spending 2 days on this now, and this bug is the highlight of the Flex release for me. I think I just discovered that it can be worked around by adding layout=vertical to the panel.

  8. I really appreciate the public bug database and your transparency on this. I wish I had somewhere to report when my brain gives a runtime error.

  9. Chico says:

    I’m a long time Actionscript developer (since 1.0 from Macromedia), and that was the main reason for me to choose Flex as the main technology on one of my recent projects, and guess what? I’m giving up on Flex. Flex is a good idea at all, but it’s too buggy. Everytime i try to extend something, make use of events or just make an item renderer look different i end up having to work-around things.The show event is the one that gets worse on my nerves, why when this fires up none of the children inside the object that dispatched it are accessible, as you might imagine, when a canvas containing a textinput shows up, the textinput has to be there, but why it’s not? i ended up discovering that there’s no way to know when all instances are accessible using events, the only way i found to do that is implementing a timer to check when everything’s up. Now you imagine for every component i must use some internal instances when it shows up i have to implement a timer to do that, that’s simply ridiculous.private function tick(evt:TimerEvent):void{if(instance1 && instance2 && instance3){doSomething();;, tick);}}P.S. the same thing happens with creationComplete, added, and addedToStage events