[
https://issues.apache.org/jira/browse/FLEX-34119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Chira updated FLEX-34119:
-------------------------------
Description:
*Steps to reproduce A*:
# Run the unit test called HierarchicalCollectionViewCursor_FLEX_34119_Test in
the "FLEX-34119" branch against the HierarchicalCollectionViewCursor class in
the develop branch. You should see lots of "Bookmark no longer valid" errors.
*Steps to reproduce B*:
# Run the attached AIR project. (Avoid debug mode unless you want to press F8
MANY times). It will take around 10s.
The unit test (HierarchicalCollectionViewCursorTest.as) shows many of the ways
in which HierarchicalCollectionViewCursor's state can make ListCollectionView
fail through a seek() operation on ListCollectionViewCursor by allowing a
CursorError to be thrown from ListCollectionView.getBookmarkIndex() (I say
'allowing' because it could easily prevent it).
The (long) trace output (viewable in debug mode) shows all the configurations
of the collection-view that I constructed which cause the RTE.
*Notations in trace output*:
* [SEL] - the currently selected item by the HierarchicalCollectionViewCursor
(cursor.current).
* [INS] - the newly inserted item, which caused the RTE
* [REPL] - the item which, when replaced, causes the RTE (notice there's only
one such instance - when the (selected) second stage is replaced with another
item).
*NOTES*:
* for us this has caused numerous, apparently mysterious bugs within
AdvancedDataGrids which boiled down to one or other of these configurations.
* The reproduceCursorErrorWithDisableAutoUpdate() test shows that the error can
also be thrown by not allowing the HierarchicalCollectionView (and, implicitly,
the HierarchicalCollectionViewCursor) to know about changes in the underlying
collections (by using disableAutoUpdate() in conjunction with refresh() and
enableAutoUpdate()). We were using these methods to optimise expensive updates
in the collections shown in the AdvancedDataGrids, without realising they had a
knock-on effect on the HierarchicalCollectionView used by the grids. This part
of the error-generation scenario is controlled by the programmers, of course,
but it might be worth documenting, so that others can avoid these issues.
* I found one bug report which hints at these problems, but it doesn't seem to
have kept its attachment: FLEX-33054. The last comment shows the exact part of
the code which calls seek(), thus generating the RTE.
*The RTE that's usually thrown*:
Main Thread (Suspended: Error: Bookmark no longer valid.)
mx.collections::HierarchicalCollectionViewCursor/collectionChangeHandler
flash.events::EventDispatcher/dispatchEventFunction [no source]
flash.events::EventDispatcher/dispatchEvent [no source]
mx.collections::HierarchicalCollectionView/nestedCollectionChangeHandler
flash.events::EventDispatcher/dispatchEventFunction [no source]
flash.events::EventDispatcher/dispatchEvent [no source]
mx.collections::ListCollectionView/dispatchEvent
mx.collections::ListCollectionView/addItemsToView
mx.collections::ListCollectionView/listChangeHandler
flash.events::EventDispatcher/dispatchEventFunction [no source]
flash.events::EventDispatcher/dispatchEvent [no source]
mx.collections::ArrayList/internalDispatchEvent
mx.collections::ArrayList/addItemAt
mx.collections::ListCollectionView/addItemAt
was:
*Steps to reproduce*:
1. Run the attached AIR project. (Avoid debug mode unless you want to press F8
MANY times). It will take around 10s.
The unit test (HierarchicalCollectionViewCursorTest.as) shows many of the ways
in which HierarchicalCollectionViewCursor's state can make ListCollectionView
fail through a seek() operation on ListCollectionViewCursor by allowing a
CursorError to be thrown from ListCollectionView.getBookmarkIndex() (I say
'allowing' because it could easily prevent it).
The (long) trace output shows all the configurations of the collection-view
that I constructed which cause the RTE.
*Notations in trace output*:
* [SEL] - the currently selected item by the HierarchicalCollectionViewCursor
(cursor.current).
* [INS] - the newly inserted item, which caused the RTE
* [REPL] - the item which, when replaced, causes the RTE (notice there's only
one such instance - when the (selected) second stage is replaced with another
item).
*NOTES*:
* for us this has caused numerous, apparently mysterious bugs within
AdvancedDataGrids which boiled down to one or other of these configurations.
* The reproduceCursorErrorWithDisableAutoUpdate() test shows that the error can
also be thrown by not allowing the HierarchicalCollectionView (and, implicitly,
the HierarchicalCollectionViewCursor) to know about changes in the underlying
collections (by using disableAutoUpdate() in conjunction with refresh() and
enableAutoUpdate()). We were using these methods to optimise expensive updates
in the collections shown in the AdvancedDataGrids, without realising they had a
knock-on effect on the HierarchicalCollectionView used by the grids. This part
of the error-generation scenario is controlled by the programmers, of course,
but it might be worth documenting, so that others can avoid these issues.
* I found one bug report which hints at these problems, but it doesn't seem to
have kept its attachment: FLEX-33054. The last comment shows the exact part of
the code which calls seek(), thus generating the RTE.
*The RTE that's usually thrown*:
Main Thread (Suspended: Error: Bookmark no longer valid.)
mx.collections::HierarchicalCollectionViewCursor/collectionChangeHandler
flash.events::EventDispatcher/dispatchEventFunction [no source]
flash.events::EventDispatcher/dispatchEvent [no source]
mx.collections::HierarchicalCollectionView/nestedCollectionChangeHandler
flash.events::EventDispatcher/dispatchEventFunction [no source]
flash.events::EventDispatcher/dispatchEvent [no source]
mx.collections::ListCollectionView/dispatchEvent
mx.collections::ListCollectionView/addItemsToView
mx.collections::ListCollectionView/listChangeHandler
flash.events::EventDispatcher/dispatchEventFunction [no source]
flash.events::EventDispatcher/dispatchEvent [no source]
mx.collections::ArrayList/internalDispatchEvent
mx.collections::ArrayList/addItemAt
mx.collections::ListCollectionView/addItemAt
> mx.collections.HierarchicalCollectionViewCursor causes CursorError RTE from
> ListCollectionView when the underlying collections change
> -------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FLEX-34119
> URL: https://issues.apache.org/jira/browse/FLEX-34119
> Project: Apache Flex
> Issue Type: Bug
> Components: Advanced Data Grid
> Affects Versions: Apache Flex 4.12.1
> Reporter: Mihai Chira
> Assignee: Mihai Chira
> Labels: collections, cursors, easytest
> Fix For: Apache Flex 4.12.0
>
> Attachments: _HierarchicalCollectionViewCursorBug.fxp
>
>
> *Steps to reproduce A*:
> # Run the unit test called HierarchicalCollectionViewCursor_FLEX_34119_Test
> in the "FLEX-34119" branch against the HierarchicalCollectionViewCursor class
> in the develop branch. You should see lots of "Bookmark no longer valid"
> errors.
> *Steps to reproduce B*:
> # Run the attached AIR project. (Avoid debug mode unless you want to press F8
> MANY times). It will take around 10s.
> The unit test (HierarchicalCollectionViewCursorTest.as) shows many of the
> ways in which HierarchicalCollectionViewCursor's state can make
> ListCollectionView fail through a seek() operation on
> ListCollectionViewCursor by allowing a CursorError to be thrown from
> ListCollectionView.getBookmarkIndex() (I say 'allowing' because it could
> easily prevent it).
> The (long) trace output (viewable in debug mode) shows all the configurations
> of the collection-view that I constructed which cause the RTE.
> *Notations in trace output*:
> * [SEL] - the currently selected item by the HierarchicalCollectionViewCursor
> (cursor.current).
> * [INS] - the newly inserted item, which caused the RTE
> * [REPL] - the item which, when replaced, causes the RTE (notice there's only
> one such instance - when the (selected) second stage is replaced with another
> item).
> *NOTES*:
> * for us this has caused numerous, apparently mysterious bugs within
> AdvancedDataGrids which boiled down to one or other of these configurations.
> * The reproduceCursorErrorWithDisableAutoUpdate() test shows that the error
> can also be thrown by not allowing the HierarchicalCollectionView (and,
> implicitly, the HierarchicalCollectionViewCursor) to know about changes in
> the underlying collections (by using disableAutoUpdate() in conjunction with
> refresh() and enableAutoUpdate()). We were using these methods to optimise
> expensive updates in the collections shown in the AdvancedDataGrids, without
> realising they had a knock-on effect on the HierarchicalCollectionView used
> by the grids. This part of the error-generation scenario is controlled by the
> programmers, of course, but it might be worth documenting, so that others can
> avoid these issues.
> * I found one bug report which hints at these problems, but it doesn't seem
> to have kept its attachment: FLEX-33054. The last comment shows the exact
> part of the code which calls seek(), thus generating the RTE.
> *The RTE that's usually thrown*:
> Main Thread (Suspended: Error: Bookmark no longer valid.)
>
> mx.collections::HierarchicalCollectionViewCursor/collectionChangeHandler
>
> flash.events::EventDispatcher/dispatchEventFunction [no source]
> flash.events::EventDispatcher/dispatchEvent [no source]
>
> mx.collections::HierarchicalCollectionView/nestedCollectionChangeHandler
>
> flash.events::EventDispatcher/dispatchEventFunction [no source]
> flash.events::EventDispatcher/dispatchEvent [no source]
> mx.collections::ListCollectionView/dispatchEvent
> mx.collections::ListCollectionView/addItemsToView
> mx.collections::ListCollectionView/listChangeHandler
> flash.events::EventDispatcher/dispatchEventFunction [no source]
> flash.events::EventDispatcher/dispatchEvent [no source]
> mx.collections::ArrayList/internalDispatchEvent
> mx.collections::ArrayList/addItemAt
> mx.collections::ListCollectionView/addItemAt
--
This message was sent by Atlassian JIRA
(v6.2#6252)
