Tutorials, extensions, and source files for ActionScript, Flash, and other Adobe products.

 

Did you know? You can log Flash Player bugs!

Posted October 31, 2008 by senocular

If you didn't already know, there is a public Adobe bug base for logging and tracking bugs (and feature requests) for Flash Player. Before I tell you where you can find it, I want to lay down some important guidelines you should follow when logging a bug.
#1. Make sure you have an actual bug and not something that might be caused by user error. I've seen it many times, especially in various online forums; people claim to have discovered a Flash Player bug when in fact they simply weren't doing something right on their end (and often this is security related of which the rules can be a little obscure). If you're not sure, check with someone else first, or post your issue in a forum to see if others can't help.

#2. Search first. Has someone else already discovered the same problem you've run into? That may be the case, and if so you want to be sure you find that issue rather than making a new one of your own. When you find an existing issue, you can vote on that issue increasing its priority. A duplicate issue can only hurt by dividing votes.

#3 Provide clear, detailed, yet concise information. When you log a bug, make sure you clearly identify the issue and all the environments you've tested the issue. The more places you test, the better. If you have access to both Windows and Mac OS, try to replicate the bug on both systems to see if it's system specific. Also, the version of Flash Player this first occurred is a big help; this determines if it's an injection or not. You can get archived versions of the player from adobe's web site. Any other information, though minor (if pertinent), could be useful. Remember, others will be searching the database for your issue if they've run into it to. To make sure you get their votes, include keywords

#4. Provide files. Files are very important for helping us reproduce a bug. And reproducibility is key. If an issue cannot be reproduced, it's likely it can't be fixed. Having a SWF is ok, having the source files for that SWF is better. The simpler, the better. The fewer dependencies, the better. If you're using Flex, try your absolute best to make an ActionScript-only example without using MXML. The Flex framework only gets in the way (unless it's a Flex specific bug, then, well, you'd need it then and you'd be logging under Flex, not Flash Player). The simplicity and reproducibility of a bug is actually very important and makes it much more likely that the bug can be identified and fixed. If you can produce a SWF that clearly identifies an issue that can also clearly identify when the issue has been fixed, bonus points for that.

#5. Include crash logs. If you're experiencing a crash with the Flash Player you may be able to get a Flash Player-specific crash log if you're using a debugger version of the player (available here). On Windows these crash logs, if the player was able to produce one, can be found in [user home]\Local Settings\Temp and will be named something like player_crash_log_(##).mdmp.

#6 Be attentive. You may be asked questions or be requested to provide more information after you've logged a bug. If that's the case, please respond with the necessary information, or at least to say that you cannot provide any more, though that is not ideal ;).

And finally, where can you log Flash Player bugs?
https://bugs.adobe.com/flashplayer/

Note: This replaces what was adobe.com/go/wish for Flash Player

FYI, a lot of what I've just said reiterates what I mentioned in a previously written article, Introducing the Flash Player bug and issue management system. But I do want to stress the importance of simplicity in sample files and the fact that you should avoid using MXML and the Flex framework. If you don't we have to recreate the sample without it which can be a bit of a pain.