Bug in Styles

I'm not seeing a reference to an original bug, which the post on 11/23 implies, but in looking at the SimpleEditorWithCSS sample, the issue is with how the operation collects and iterates over the elements having the style applied. Because the example sited is using the same style name as that applied to the second element, a series of merges occur which renders the second element invalid.

Initial State:
<span styleID="a">foo</span><span styleID="b">bar</span><span>moreFooBar</span>
Selection from "oo" of "foo" to "more" and new styleID="b"

"foo" will be split:
<span styleID="a">f</span><span styleID="b">oo</span>...

During operation, normalize will merge "bar" into "oo":
span styleID="a">f</span><span styleID="b">oobar</span>

------
Because the code is iterating over "targets" the "bar" span is still in the list even though it is no longer part of the Text Flow. The solution to this is to check to see if the current target has no parent, indicating that a merge has happened, and in that case skip it. Adding the following code while performing "for each (target in targetList)" of the SimpleEditorPanel to read:

if(target.parent == null)
{
absStart += target.textLength;
continue;
}

No exceptions are thrown and the sample behaves as expected. This code has been updated in Adobe's source and will be posted when made available to the public.

It is important to note that collecting targets prior to execution of an operation can lead to the target becoming invalid. Client code which "pre-determines" targets prior to operating on them, should re-validate them during a looping operation. Alternatively, a client could loop based on text indexes and collect each target individually rather than assembling a list ahead of time.