Open Bug 102054 Opened 23 years ago Updated 2 years ago

boxes with same ordinal isn't ordered correctly when dynamically changed

Categories

(Core :: XUL, defect, P4)

defect

Tracking

()

Future

People

(Reporter: sicking, Unassigned)

References

()

Details

When ordinal is dynamically changed boxes with the same ordinal isn't ordered in content order. Steps to reproduce: 1. go to the supplied url 2. set ordinal 1 for all buttons 3. repeatedly set the ordinal to 1 for the fist button Actual results: Once all boxes has ordinal 1, setting it to 1 (again) will move the button to last position. Expected results: When all buttons has ordinal 1 they should always be ordered in content order (which is 1 2 4 3 in the testcase)
This issue was discussed prior to landing the ordinal stuff, so see the discussion at the end of bug 93519. To summarize, this behavior would be nice to have, but could potentially complicate and slow-down the box sorting code, so I am not sure if it is worth it.
Status: NEW → ASSIGNED
OS: Windows 98 → All
Priority: -- → P4
Hardware: PC → All
Target Milestone: --- → Future
so what should we do with this, IMHO we should either change the spec or try to fix this bug
the tradeoff is that instead of (potentially?) complicating and slowing down the box sorting code, the application developer has to iterate and rearrange dom nodes from javascript to guarantee correct display order, after updating ordinals. i'm sure that's even slower. and it makes ordinals less useful.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: hewitt → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.