Below is a list of undocumented (at the time of posting) bugs and quirks found in various versions of Flash.
We shall keep updating this article when we come across more peculiarities.
- JSFL performance in AS2 vs. AS3 documents
(Flash CS3 – CS6) If Document Type is AS3, this affects negatively the performance of JSFL. The slow-down is as drastic as x100!. For example an operation that takes 500ms to complete in an AS2 document takes 50000ms if Document type is set to AS3. - Custom Stroke settings affected by AS2 or AS3 Document type
Various custom Stroke settings (Dashed, Ragged, Stippled) look different depending on whether the Document Type is set to AS3 or AS2. Also certain thicknesses and certain types of hatching are impossible to achieve in an AS3 document. - Easing curve not being copied correctly during Copy/Paste Frames
(Flash 8 only) During Copy Frames / Paste Frames operation if there is simple easing applied to the key, the easing curve data is not copied correctly.
The easing number displayed in the simple easing box is the right one, but upon opening the corresponding custom ease curve, it is broken.For example:
- Create a Motion Tween (called Classic in later versions) and give easing of 100 in the first key.
The easing curve looks like this:
[{"x":0,"y":0},{"x":0.3333333333333333,"y":0.6666666666666666},{"x":0.6666666666666667,"y":1},{"x":1,"y":1}] - Select and copy the frames.
Create a new layer and paste them there. The curve in the newly pasted key looks like this:
[{"x":0,"y":0},{"x":0.3333333333333333,"y":0.3333333333333333},{"x":0.6666666666666666,"y":0.6666666666666666},{"x":1,"y":1}]
*If you have EDAP Tools installed, you can see the values of the easing curve in the selected key by using this code:
var timeline = fl.getDocumentDOM().getTimeline(); var frame = timeline.layers[timeline.currentLayer].frames[timeline.currentFrame]; fl.trace( Edapt.utils.JSON.stringify( frame.getCustomEase("all") ) );
- Create a Motion Tween (called Classic in later versions) and give easing of 100 in the first key.
- Inconsistent mouse vs. keyboard behavior while confirming XUL dialogs
If we hit Enter on the keyboard instead of clicking the OK button to confirm a XUL dialog, the dialog is considered confirmed, but skips the execution of the function attached to the OK button.
For example:
Create a XUL dialog with the following content and put the file 'test.xml' in the WindowSWF folder:<?xml version="1.0"?> <dialog id="demo" title="ColorPicker Test"> <textbox id="text" value="3.14"/> <hbox> <button label="OK" oncommand = "test();"/> <button label="Cancel" oncommand = "fl.xmlui.cancel();"/> </hbox> <script> function test(){ fl.trace( "The value: " + fl.xmlui.get( "text" ) ); fl.xmlui.accept(); } </script> </dialog>
Trigger the dialog with the following code:
var settings = fl.getDocumentDOM().xmlPanel( fl.configURI + "WindowSWF/test.xml" ); fl.trace( Edapt.utils.JSON.stringify( settings ) );
If you click the OK button, Output panel will display:
The value: 3.14 {"text":"3.14","dismiss":"accept"}
If you press ENETR on the keyboard however, dialog closes and Output panel displays:
{"text":"3.14","dismiss":"accept"}
We can see that in both cases the dialog is considered to be confirmed, but when done via keyboard input the function test() wasn't called.
- Broken Shape Tweens after a crash due to corrupted cache
Shapes disappearing in the middle of Shape Tween after a crash of Flash / Animate. This affects not only the file involved in the crash, but also backup versions of the same animation which cannot be corrupted by the crash.
The problem is broken cache. Read the full article here. - Invalid bounding box
In certain situations where symbols contain Drawing Objects, after symbol instances have been edited via JSFL, Flash/Animate is unable to correctly report the position of the symbol's bounding box, producing a huge negative number instead.Entering said symbols on Stage (Edit in Place) and deselecting everything by clicking on a blank spot or pressing the Esc key will force Flash/Animate to update its record of the symbol's content and position.
The bug does not manifest itself after the file is closed and reopened.
Keyframe Labels slowing down playback to a crawl
If you, like us, very rarely preview your animation in the Timeline, since Timeline Preview is in most cases laggy, it is safe to turn labels on as they provide very useful visual information.
Labels do not affect SWF Preview in any way, and since SWF Preview is the only reliable way to see your animation as intended, we recommend getting into the habit of hitting [Ctrl+Enter] every time you wish to preview.
Below is the bug report that we submitted to Adobe on 30 Jun 2020.
There has been no acknowledgement of the bug by the Animate team to this day (23 Jul 2020).
To alleviate the issue in v.6 of EDAP Tools we made the convenience of labels optional and disabled by default.
n. tilcheff
June 30 in Bug Discussions
One of our users contacted us yesterday with the observation of some extreme playback sluggishness with Cleaned Up frames.
After some investigation we determined the superficial cause – comment labels that we have been using for years to mark auto-generated keys – are slowing down playback in AA 20.5 ten times or more.
The image below shows the setup:
Here is a video that shows how to reproduce and describes the problem in detail.
It also makes a comparison between the payback in AA 20.5 and AA 15.2
It will be good if this is addressed alongside all other pressing performance issues.
Do you have any thoughts on the "new" (CC2015) motion editor? I find it next-to-impossible to use beyond the simplest ease or presets. Is it buggy, or is it poorly designed – or do I need to learn how to use it properly?