I want to start off with a quick recap of the current status of the bug I wrote about a few days ago. The Flex 3 Panel bug that resulted in the content of a Panel overlapping the title bar of the Panel has been fixed. The fix will be in the final Flex 3 release. The bug report that shows this status is here: Issue 11279, which is now marked as a resolved bug. I want to point out that I was told (with proof) that Adobe recently started re-investigating this bug on their own about a week before I posted my rant (although that was never exlained in the bug database).
I also want to take a second to address what was seen as me being an asshole with what Matt Chotin called my “strongly worded criticism.” 🙂 I also received another email from a Flex team member with a similar sentiment letting me know that I may have been a bit harsh and that I need to remember that the engineers working on the framework are good guys trying to do the best job they can for us (the customers). I’ve met Matt personally a few times, and I deeply respect him and all the Adobe engineers working on Flex. I didn’t mean my little rant to come off as a personal attack on anyone, although I realize that since I was targeting a very specific bug that that means it falls under the responsibility of a few individuals. My harshness was a result of frustration and a misunderstanding of Adobe’s perspective, there was never meant to be any direct blame placed on individual engineers. And so with that, here’s my olive branch:
Dear Flex team, I love you all. Your work is greatly appreciated. You make it possible for me and many other people to do work that we love. You’ve delivered a fantastic product and the overall intelligence of the team shows through in the great code base of the Flex SDK. Keep doing your jobs. Even though I may criticize, I mean it with love and respect.
OK, everyone feeling all warm and fuzzy inside? Cool, let’s all get back to work.
Matt Chotin addresses what to do if you run into similar issues like this Panel bug, where you don’t feel the Flex team addressed the issue adequately. He mentions that you will be able to vote on closed bugs in the future, so once that is in place you can still vote on a bug even if it has been marked as NAB, and the Flex team will be able to see which ones have the most community involvement. Until then your options seem to be leaving comments on the closed bug (which in this case meant 4 or 5 independent bug reports of the same issue) and emailing the Flex team, which I think means email Matt, since I can imagine that they don’t want all the engineers dealing with trivial requests from the community all day long.
That said, I’m not sure if I had dealt with the bug differently (ie simply posted a comment and emailed Matt) that it would have gotten fixed so immediately. While I understand that internally Adobe was re-investigating this bug, my hunch is that without the public bitching there would not have been a fix committed for the final Flex 3 release (feel free to correct me if I’m wrong). A single comment on a bug report and an email to Matt likely would have gotten it on the radar (although it already was), but I’m guessing we wouldn’t have seen such immediate action. So perhaps I should have phrased my previous post in a better way, and simply called attention to the bug to try to get others to comment on it so they would reopen. But I think there is certainly a place for publicly posting issues like this, since it’s an effective way to rally the troops and clearly articulate the issue (what was I going to do, write a 2,000 word comment in the bug database?). So in the future I’ll try to be a tiny bit more diplomatic with how I write posts like that.
So thank you Adobe for the quick action in response to this issue.
We love you too Doug and do appreciate the passion that you and others bring to the Flex community!
Sometimes we only get stuff done by being jerky…
That said, it’s important to make-up and let by-gones be by-gones. As well as affirm one’s overall satisfaction. I think you’ve done that.
I think the result is overall positive. Matt Chotin’s response actually raised the respect I have for Adobe’s Flex team. While I think that if I had written the same on my blog, it would have accomplished little, it is comforting to know that those representative voices (those with recognition) in the community are heard when they vocalize. Because often, you guys will be representative of the community as a whole – even if you’re not elected and handed an uber-sweet retirement package like Congress.
However, the fact that Adobe/Matt Chotin responded is very assuring to me. It shows that they are neither elitists nor are they so distant from the community as to be inaddressable.
I also was over-joyed to hear that they realized some of the errors in how they were handling bug management. Because mistakes will always be made. How you handle those mistakes is often more important. And realizing one’s mistakes is the first step to remediate them. So now, Adobe/Matt Chotin have stated “We’re learning!”
That’s just great, excellent even…cause we’re learning too. And it is very comforting to know that the Adobe development environment has not falling into stagnation as the likes of big companies such as Microsoft, IBM, etc.
It also gives me hopes that those things that frustrate me will at some point be resolved. 🙂
? Koombaya ?
Happy endings are the best.
Alright, let’s roll up our sleeves, work to do…what’s the *next* bug pissing everyone off. Let’s get on it.
While the language did sting a bit on the original Panel posting, I probably agree with ‘Jason the Saj’. The harsh language got our attention and other people’s attention to speak their opinion. The cussing was backed by a lot of supportive arguments as to why this should be fixed. We have a lot of bugs come in and our team isn’t that big, so, sometimes stuff falls through and we need to hear about them.
So, thanks for your passion Doug…And for the Teddy Bear. The Panel bug has been checked in and the bug is officially “Fixed”.
Totally dig that teddy bear.
The original post didn’t seem that harsh to me. Must have been the use of the word ‘bullshit’.
Group hugs all round.
I think you’re right – if you’d just commented the bug it probably wouldn’t have got changed.
But this is the way open development works – if the community (by voting, by going on about it,…) decides something really needs fixing the dev. team perk up and take note.
And this is good.
As Matt says, there will be more formal ways to address this going forward, which is even better 🙂
I just found that Panel skinning was working just fine in Flex 3 Beta 3 is now broken in the Flex 3 release today. The content overlaps the header of the panel. Does anybody know what’s going on?
I just found a workaround: In Flex 3 release, if you have a borderskin with a scale9 defined, you must set padding-top to the same number as scaleGridTop property of the embeded scale9 image.
This is an important change to be aware of when going from beta to the release build of Flex in regards to the panel content overlap issue.
Harry, is there a workaround if I want to scale my content to the top, right, bottom, left bounds of my scale9 grid, not just the top? I tried setting all the padding properties with no success.
I just used a Canvas as the content of the Panel, and put the original content inside the canvas. Then, I just set the canvas’ left, bottom, right, and bottom properties to match the scale nine dimensions. There’s probably a more convenient and automatic workaround along this direction, but it worked in a pinch for me.
The padding-{left,right,bottom} all work the same as padding-top for scale9’ing it.
But now I just found another problem. If you extend a panel, the padding-* styles become impotent. In other words, if you create an mxml like this:
then, instantiate that panel from another component, the blue box will overlay the panel title, regardless of whether or not there’s a padding-top. but if you use the same code by pasting it directly into another component, it works fine.
it seems like adobe made some drastic changes between the last beta and the release, and they didn’t have time to test every aspect of it. now, i’m spending my time dealing with this problem that they introduced instead of moving forward building my flex application, which was working fine before somebody pressured adobe into making a risky change at the last minute.
now, i gotta find a way to extend the panel so that its children won’t overlap the title when the extended panel is extended with children. or i’ll instruct all the flex developers to put a canvas with left,right,top,bottom tags into every instance of panel. this is ugly. what other options do i have?
This bug is still available on Flex 3. I have changed the skin of the Panel by using Flash Component’s toolkit, then imported into Flex by using Flex Import Skin wizard. Then I placed the datagrid inside this panel content. I also set the datagrid’s width and height to 100%. Now the datagrid overlapped the panel content.
One more things about this bug. When adding the Control Bar, the control bar background does not appear. I thought I was wrong when changing the skin, but it’s still happen even I used the original skin template.
Wow!
I’ve finally just read this and i can’t believe it!
Your previous article was beautiful… Supporting the community.. yet you were silenced..
Bugs made the Flex 3 release, causing developers pain around the world, and your quoted in this article praising the Team that did this…
IMO, they deserved strong worded criticism.
@Bjorn- I don’t think I was “silenced” at all. In fact, the opposite. Matt Chotin responded with a post of his own giving us all a look into the Flex team’s bug management strategy and explaining things from his point of view. And the bug got fixed (as far as I know) before the final release of Flex 3. I’m sure there are still many other bugs in the final Flex 3 release (I know I’ve already run into a bunch). But in this instance I bitched about a bug, Adobe responded both with an explanatory blog post and with a source code bug fix, and then I posted a followup to let people know and to thank the Flex team for being open and having the conversation.
They didn’t send a bag of money or dudes with baseball bats to break my legs.
Check this out..
http://bugs.adobe.com/jira/browse/SDK-14806
Adobe supplied the same reasoning again;
From the contrast of your posts.. “Calling bullshit on a “resolved” Flex bug” to “OK, everyone feeling all warm and fuzzy inside” I thought the Flex’s Lil John had been intimidated into submission…
@Bjorn: Aha, that’s kinda funny. That’s actually a different bug that the one I posted. That one has to do specifically with using image assets for the skins and a scale-nine grid. The saddest part about this bug is that according to a commenter, the code specifically produced by the official Adobe Flex component kit for Flash doesn’t work. Woops. Anyway, I had no idea that this was also a bug in the Panel skin stuff, since I rarely use scale-nine image assets as my Panel skins.
“Flex’s Lil John had been intimidated into submission”
Ha, I love it. Fuck that. But I do think it’s important for everyone to get along. In my view, I said some pissy things, they responded, corrected the problem, so I was happy and gave them a teddy bear. Isn’t that the way the world is supposed to work?
If only this other scale-nine panel bug affected me I would’ve had a whole other blog post I could’ve written. 🙂
no worries champ.. good to know your still on our side ; )
This bug has been a pain for me, but I found a workaround that works for me, I have been using some themes from scalenine and was getting the panel border overlay problem, then I opened the css file found the declaration for the Panel and changed it to PanelSkin and this seemed to fix it.
1. Find the declaration for the panel in the css file
2. Change it to PanelSkin instead of Panel.
hope this helps someone else
Adobe just released Flex SDK 3.1 and it has lots of bug fixes. This Panel bug (which I filed) is still marked as open, and it is scheduled for fix in Flex SDK 3.2. Perhaps I could have got it fixed faster. My first mistake was not having a blog, and my second mistake was not posting an entry that includes “Calling bullshit” with a link to the bug. 🙂
It is interesting to see all the activity that has happened in the comments of this bug:
https://bugs.adobe.com/jira/browse/SDK-14806
Deepa is awesome for dealing with this bug/controversy in stride. I know that Flex 4 will have a killer solution because these kinds of components will be rewritten from the ground up, and extend SkinnableComponent, with a completely different paradigm for skinning. I’m looking forward to this!