#882 closed defect (wontfix)
Opera: no selection visible in SortableTable
| Reported by: | Owned by: | Tom Trenka | |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | Widgets | Version: | 0.3 |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: |
Description
tests/widget/test_SortableTable.html
Table works fine, and selections are active, but there is no visual feedback (bg does not change to yellow)
Change History (6)
comment:1 Changed 14 years ago by
| Milestone: | → 0.4 |
|---|---|
| Owner: | changed from anonymous to Tom Trenka |
comment:3 Changed 14 years ago by
Dylan-- Thanks, I'll take a look when I have some time (although that should be just pure CSS stuff).
comment:4 Changed 14 years ago by
| severity: | normal → minor |
|---|
Great. This is due to a bug in Opera 9 (as far as I can tell), and a bug report has been submitted. Basically...it looks like node.getAttribute() in Opera 9, if the attribute in question is a common one but non-standard for the element in question (so far "value" and "selected" trigger this behavior), Opera 9 returns the name of the attribute and NOT the value.
I filed a bug report, we'll see what happens but this may have far reaching implications.
Also pushing the priority down on this.
comment:5 Changed 14 years ago by
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
I re-engineered the approach I was taking with the FilteringTable? widget; at this point, the only time the selected attribute is used is when pre-selecting a row within a dataset defined through HTML. Opera 9 will still not preselect this row, but otherwise works as expected.
I'm going to close this as a "won't fix" bug, simply because it would take a rewrite (which in some respects is exactly what FilteringTable? is) to fix it.
Adam--do you have a version/platform for the Opera issues?