Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: 0.4
-
Fix Version/s: 0.5
-
Component/s: Image Reorderer, Layout Reorderer, Reorderer
-
Labels:None
-
Similar Issues:
Description
A great many bugs and inconsistencies, as well as performance issues, are caused by our use of the standard JQuery UI "ui.droppable" drop manager. These can only be decisively resolved by implementing a complete replacement for its drop model, which is more suited to the use case of reordering.
In outline, the issues arise because of the "razor edged" drop target detection in ui.droppable - a drop target is only recognised if the mouse pointer is definitely within the bounds of the DOM element nominated as a "drop target". However, for the case of reordering, a more "soft-edged" approach is appropriate - there are many cases (e.g.FLUID-1125, FLUID-1127, FLUID-148) where the appropriate UI response is to map the drop target to the "geometrically nearest" position to the mouse cursor, rather than to either assume there is no target, or revert to the last target, which are the only two options available with the "razor edge" distance model.
Also, several performance problems are traceable to ui.droppable - the "prepareOffsets" method is extremely expensive and is currently tied to the dragStart point of the lifecycle. It would be preferable to be able to compute the relevant DOM dimensions in user idle time after the drag proper has started. Finally, our use of the ui.droppable manager is awkward since the "left/right" logic required to spot previous/after drop targets has to be done by a raw mouse listener on a parallel lifecycle to the main drop notification. It would be preferable and more efficient to have this factored back behind a single, tractable interface, as well as to eliminate as much as we can of in-memory garbage created during a drag cycle.
dev-iteration42
In outline, the issues arise because of the "razor edged" drop target detection in ui.droppable - a drop target is only recognised if the mouse pointer is definitely within the bounds of the DOM element nominated as a "drop target". However, for the case of reordering, a more "soft-edged" approach is appropriate - there are many cases (e.g.
Also, several performance problems are traceable to ui.droppable - the "prepareOffsets" method is extremely expensive and is currently tied to the dragStart point of the lifecycle. It would be preferable to be able to compute the relevant DOM dimensions in user idle time after the drag proper has started. Finally, our use of the ui.droppable manager is awkward since the "left/right" logic required to spot previous/after drop targets has to be done by a raw mouse listener on a parallel lifecycle to the main drop notification. It would be preferable and more efficient to have this factored back behind a single, tractable interface, as well as to eliminate as much as we can of in-memory garbage created during a drag cycle.
dev-iteration42
Issue Links
- is depended on by
-
FLUID-33
Fix the up/down calculations in the Reorderer to handle a range of spatial positioning options.
-
-
FLUID-1062
Reorderer-Vertical List and IE6: drops sometimes fail
-
-
FLUID-1135
"Begin drag" operation in the Reorderer is too slow
-
Activity
Antranig Basman
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue is depended on by |
Antranig Basman
made changes -
Antranig Basman
made changes -
| Priority | Major [ 3 ] | Critical [ 2 ] |
Antranig Basman
made changes -
| Link |
This issue is depended on by |
Antranig Basman
made changes -
| Assignee | Antranig Basman [ antranig ] |
Michelle D'Souza
made changes -
| Description |
A great many bugs and inconsistencies, as well as performance issues, are caused by our use of the standard JQuery UI "ui.droppable" drop manager. These can only be decisively resolved by implementing a complete replacement for its drop model, which is more suited to the use case of reordering. In outline, the issues arise because of the "razor edged" drop target detection in ui.droppable - a drop target is only recognised if the mouse pointer is definitely within the bounds of the DOM element nominated as a "drop target". However, for the case of reordering, a more "soft-edged" approach is appropriate - there are many cases (e.g. Also, several performance problems are traceable to ui.droppable - the "prepareOffsets" method is extremely expensive and is currently tied to the dragStart point of the lifecycle. It would be preferable to be able to compute the relevant DOM dimensions in user idle time after the drag proper has started. Finally, our use of the ui.droppable manager is awkward since the "left/right" logic required to spot previous/after drop targets has to be done by a raw mouse listener on a parallel lifecycle to the main drop notification. It would be preferable and more efficient to have this factored back behind a single, tractable interface, as well as to eliminate as much as we can of in-memory garbage created during a drag cycle. |
A great many bugs and inconsistencies, as well as performance issues, are caused by our use of the standard JQuery UI "ui.droppable" drop manager. These can only be decisively resolved by implementing a complete replacement for its drop model, which is more suited to the use case of reordering. In outline, the issues arise because of the "razor edged" drop target detection in ui.droppable - a drop target is only recognised if the mouse pointer is definitely within the bounds of the DOM element nominated as a "drop target". However, for the case of reordering, a more "soft-edged" approach is appropriate - there are many cases (e.g. Also, several performance problems are traceable to ui.droppable - the "prepareOffsets" method is extremely expensive and is currently tied to the dragStart point of the lifecycle. It would be preferable to be able to compute the relevant DOM dimensions in user idle time after the drag proper has started. Finally, our use of the ui.droppable manager is awkward since the "left/right" logic required to spot previous/after drop targets has to be done by a raw mouse listener on a parallel lifecycle to the main drop notification. It would be preferable and more efficient to have this factored back behind a single, tractable interface, as well as to eliminate as much as we can of in-memory garbage created during a drag cycle. dev-iteration42 |
Michelle D'Souza
made changes -
| Priority | Critical [ 2 ] | Blocker [ 1 ] |
Antranig Basman
made changes -
| Resolution | Fixed [ 1 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
Justin Obara
made changes -
| Workflow | jira [ 11180 ] | Fluid [ 15082 ] |
Justin Obara
made changes -
| Workflow | Fluid [ 15082 ] | jira [ 18771 ] |
Justin Obara
made changes -
| Workflow | jira [ 18771 ] | Fluid [ 26443 ] |
Michelle D'Souza
made changes -
| Status | Resolved [ 5 ] | Closed [ 6 ] |
