Flex/Flash/Actionscript

Calling bullshit on a “resolved” Flex bug

When Flex 3 was first released in beta you may have noticed a bug having to do with the Panel component when you set borderStyle to anything other than “default” (which funny enough, isn’t even a code-hinted option in Flex Builder). The issue was that the Flex 3 SDK laid out the Panel contents on top of the title bar, so the content ended up overlaid on the title and it would generally look like total crap. Basically if you had a Flex application that used the solid (or inset or outset) borderStyle on Panel to style your application, suddenly when you upgraded to Flex 3 your app looked really bad. Since Alert and TitleWindow extend Panel this affects those components too. You may have seen things in your app that looked like this:

firefoxscreensnapz026.jpg

Yeah, that sucks.

So I figured this was one of those bugs that would get reported quickly (it did) and fixed quickly (it did not and will not). There are 4 duplicate reports of this issue in Adobe’s bug tracking system, the first one was reported June 13, 2007. Here are the 4 issue reports:

They’re all the same thing, and they each have example screenshots or SWF files that show how bad the resulting bug looks.

The bugs have all been marked as Not a Bug. And this is the explanation for this resolution:

After some back and forth discussion, Glenn and I have decided that Panel will no longer support any borderStyle besides “default”. The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.

Panel will support other borderStyles when using the backwards compatibility flag. In addition, it will be possible to use a combination of explicit heights/widths and absolute positioning to replicate most of the old behavior for alternate borderStyles.

PanelSkin’s implementation of alternate borderStyles will be mostly working, but won’t layout the header and control bar in the correct locations, nor will it size the Panel to be large enough. We need to document these issues.

In the release notes there will be a line that reads:

Release Note: Panel only officially supports the “default” borderStyle. If you use an unsupported borderStyle, use padding values or absolute positioning to place your content in the correct place.

I call bullshit. This is not an acceptable resolution.

Why bullshit? Let me count the ways.

  1. You should never be able to make a Panel that has the content overlaid on top of the title bar. That is fundamentally against the definition of what a Panel is. A Panel has a title bar ABOVE the content area. ALWAYS. If the content area overlaps on top of the title bar then something is wrong. If the answer is that Panel will not layout the contents correctly unless the borderStyle is default, then you should not be able to set it to anything other than default (which is not a good resolution either, but at least it wouldn’t produce such crappy looking Panels).
  2. This worked very well before, was there ever a single person who complained that the Panel didn’t lay out its contents correctly? It did exactly what it was supposed to do, which is to lay out the content below the title bar.
  3. The default Panel skin gets old quickly, and we want to change up the look of the Panel. Used to be that you could just set borderStyle to solid and make some nice looking Panels that didn’t have that same opaque content area with semi-transparent border look. Now those decent looking Panels you styled in your old app are harder to make.
  4. I don’t buy the argument that “The reason is that in order to support the other borderStyles, we would have to put in the hacks that were in Panel back in. This would make it more difficult to skin Panel using graphical skins.” I guess the issue is with graphical skins as opposed to programmatic skins. PanelSkin returns border metrics that are used to layout the Panel’s contents (ie place them below the title bar by checking the headerHeight of the Panel). That code seems kinda hacky to me already, it means that the layout of the children in Panel is determined by a programmatic skin. But if PanelSkin is returning the border metrics used in Panel to layout the children then it could easily do so for the other border styles too. This would at least solve the problem when using the default PanelSkin (which must be the bulk of what people do). Maybe I don’t understand the issue with graphical skins, but let’s say you’re using some graphical skin to skin Panel, when would you ever want your Panel to have the content area overlap the title bar? Never. I just don’t get it.
  5. The “solution” for people that want to use the “unsupported” border styles is to set the paddingTop style to be the same or greater than your headerHeight, which will force the content to be placed below the header. But wtf kind of solution is that? We have headerHeight for a reason, and that reason is so the content gets placed below headerHeight pixels from the top. This just sounds like an answer of “well, you can hack your way around it, so that’s good enough.”

So basically I’m just bitching, because this bug will likely just stay “resolved” and be released in Flex 3 when it ships with a little release note to warn people to not do what they will invariably try to do. I don’t know if there is a formal thing I should do to try to get someone at Adobe to reconsider, the bug was filed 4 times and all are marked resolved. I assume if I submit a new one it will be marked as a duplicate and resolved. Sigh.

Oh, and Flex for Dummies will have a sentence similar to this:

WARNING: If you set a Panel’s borderStyle style to anything other than default then you must also set the paddingTop style to at least be as many pixels high as your title bar. The default implementation of Panel with borderStyle set to anything other than default sucks.

Standard

31 thoughts on “Calling bullshit on a “resolved” Flex bug”

  1. Tom S. says:

    I agree completely. It took me a long time to find the “not a bug” issue response in labs, and it isn’t a solution. My initial reaction was: “Why are two people making a decision like that, when it obviously affects a lot of development made in the previous two betas?” I understand that betas are subject to change, but this one is ridiculous. I thought I had screwed up my code for quite a while.

  2. ethan says:

    I agree-this is a dumb solution. Wondering, since the flex framework will be open after release couldn’t the community override the adobe decision and fix it correctly?

  3. This pissed me off too at first and thought it was shitty decision making.

    Soon I realized though that the default borderStyle on a panel is the same as solid, which is was I needed, so I’m not complaining as much as others.

  4. @Ryan- the default border style for Panel draws a semi-transparent border with rounded top corners, square bottom corners, and a white, 100% opaque content area which is inlaid about 5 or 10 pixels from each edge of the Panel. That’s not the same as the solid border style, which draws a solid border and renders the entire area of the Panel (ie header background and content area) the same alpha and color (still allowing you to set the headerColors if you want). All containers support the solid borderStyle, and since they all basically use the same default halo border skin, if you use the solid borderStyle for any containers they all look the same. Panel can still draw the solid borderStyle but it just fucks up the layout of the children, basically rendering it useless.

  5. Ahh I see. I was just using borderStyle=solid (and borderThickness) to display a 2 pixel border around the Panel. When switching from Flex 2 to Flex 3 I had to remove borderStyle in order for the Panel to not look fucked up.

    Apparently you can still use borderStyle if you enabled backwards compatibility mode, but why bother using Flex 3 if you’re going to do that..

    Found this here:
    http://labs.adobe.com/wiki/index.php/Flex_3:Backwards_Compatibility_Flag

  6. You clearly do not understand what “Not a Bug” means. Like all the other perfectly legitimate bugs which have been marked as NAB, it means that Adobe is either unwilling to fix the problem, or that they’re unwilling to accept external feedback. But it would be rude to say that directly. Hence, NAB was born.

    We should count ourselves lucky though. Only 11% of externally reported bugs have been marked NAB, so if you keep trying it might slip through.

    😉

  11. supertodda says:

    I had a similar problem between flex 2 and flex 3 when I tried to compile my flex 2 code in 3. Turns out they decided to get rid of Tables, so they put a warning on if you used a table (apparently they want you to use the new layout constraint stuff). Honestly, what am I supposed to think now… if I can’t use tables, and I cant used borderstyle on panels, what can’t I use when flex 4 comes out and there a “better”, more “cool” way of doing things (ways which I cannot anticipate). I’m all for progress, but by simply dismissing some of these legacy issues, Adobe is saying to their current customer base: “we don’t respect you and your time is worth nothing.”

    my bug post:
    http://bugs.adobe.com/jira/browse/SDK-12941

    The response to my last comment is classic:
    me: “What about long term? Flex/AS 3,4 and beyond?”
    them: “Closing…”

    I think more people should voice their opinions on these issues.

  12. supertodda says:

    I should point out that they did take the warnings off using tables, so there was a partial victory, however, I do not know if tables can be used long term.

  13. supertodda: Apologies for the blunt “Closing…” comment. To answer your question about the future of Grid, the answer is not known. In Flex 3, we were going to deprecate the container because it was heavyweight and should have been replaced by the Advanced Constraints feature of Moxie. However, from customer input, we found some use cases were not covered. Plus, Advanced Constraints just weren’t ready to be released (see Deepa’s blog regarding our decision to get rid of Advanced Constraints: http://iamdeepa.com/blog/?p=17) so the deprecation warnings were removed leaving Grid in this next release. In the future, Grid may still go away. I don’t think a specific decision has been made. If enough customers have arguments for keeping Grid around, they should make them known by filing and voting on bugs.

    Just FYI – when we want to deprecate a component, warnings are added to the compiler, but, for that release, you can still use the container. Ideally, this gives you enough time to rework your code for the following release when the container might not exist anymore.

    As for the Panel bug, the heart of Doug’s posting, we hear you and are revisiting this issue even though there is not a lot of time left in this release. In the future, I recommend people add comments in bugs they don’t agree with. We often revisit bugs especially if there is a long trail of comments and customers disagreeing with a decision. I fought for the Panel bug to get fixed a while back, but I didn’t get much support. If I had more customer feedback, this might have gotten fixed earlier. Even if you just vote for a bug, this feedback is helpful when deciding which bugs to fix.

    By the way, for Christopher who had to compile with Flex 2 instead of 3 to get around the Panel complications, the Panel change does support the backwards compatibility flag. If you compile in Flex 3 with the -compatibility-version=2.0.1 argument, you get the old 2.0.1 behavior. I’m not sure if this compiler flag gets much press.

    By the way, this isn’t an official Adobe response, just my opinion. 🙂

  14. @Joan- thanks for the update, I see the bug re-opened in the issue tracker. I’m going to update this post tonight given some of the new information I learned, which also includes the fact that Adobe began working on this bug again before this latest bitching and moaning of mine. In the future I’ll try to stay on the constructive side of the criticism 🙂

  16. Pingback: dougmccune.com » Blog Archive » Followup about Flex Panel bug

  17. After spending 2 full days making my flex 2 app looking half decent when compiled in plain flex 3 (who would want to use that compatibility flag), i feel like I should add my rant to it.

    flex team, I love you too,(for real) but please, get the containers style together, the whole panel skin and border is… a mess, it has a great potential and flexibility with good ideas, that just needs to be streamlined.

    Panels and border types are the raw material of all flex ui designer. and yet that part is probably the most obscure part of flex at the moment.

    I really believe the panel styling (through borders types or anything) deserve much more than a “hack” to make them half “working” or backward compatible. As a Flex lover, I was really hopping to see them evolve into a strong and flexible styling base for ui designers.

  18. Pingback: ScaleNine Blog » Blog Archive » ScaleNine Themes and Flex 3

  19. I found this post after I got screwed by the change of behavior in the public Flex 3 release.

    The Panel skinning implementation is inconsistent with the semantics of what the terms “border”, “fill”, “padding”, and “content” really mean. The current implementation confuses “border” with padding, and it confuses “content” with “component chrome”.

    In general though, I love the simplicity of the Flex framework. Nice job.

  20. In Flex 3 public release, you cannot extend Panel in mxml and add children to it when using a custom borderskin. Panel with a borderSkin is as worthless as a canvas with a background image. Nothing I do will get the children of a panel to appear in the panel. I wish I had Flex Beta 3 back, and I wish Adobe never released Flex 3.

  21. FYI – I just logged this here:
    https://bugs.adobe.com/jira/browse/FB-12157

    This bug is different than the one on this blog post because it does not involve borderStyle; it is a new bug that involves borderSkin, which is a much worse bug because borderSkin supersedes the abilities of borderStyle. Also, this bug only started happening after the bug on this blog post was committed to being fixed.

  22. Pingback: dougmccune.com » Blog Archive » My 360|Flex Survey Results - did I offend you?

  23. david says:

    package
    {
    import flash.display.DisplayObject;

    import mx.containers.Canvas;
    import mx.containers.TitleWindow;

    public class CTitleWindow extends TitleWindow
    {
    var canvas:Canvas=new Canvas();
    public function D8TitleWindow()
    {
    canvas.x=20;
    canvas.y=30;
    super.addChild(canvas);
    }
    public override function addChild(child:DisplayObject):DisplayObject
    {
    return canvas.addChild(child);
    }
    }
    }

  26. san says:

    very serious bug.. the response by adobe is definitely bs.. i just upgraded my flex builder and when i recompiled it with the new SDK i see all the UI had just gone whack.. I am using the compatibility flag approach for now, but I really hate doing it this way.. They should seriously reconsider this one again..

    P.S. all the skins on scalenine including Yahoo!’s skin has stopped working because of this too :/

  28. AHHHhh, well I had a bitch of a time trying to find a solution for this. I’m very new to flex and was doing skinning using flash cs3 with some css and noticed this bug on flex3. I kept thinking that I must be doing something wrong even though I used a bunch of templates from scalenine and other places and they still did the same thing and then after googling a little bit I found your post.

  30. Two updates and still buggered. It’s bizarre as the Title Window works perfectly fine when you apply a graphical skin surely a TW is an extended Panel with a close button, so why does one work and not the other…

Comments are closed.