Opened 14 years ago

Closed 14 years ago

#5316 closed defect (fixed)

Grid / subgrid focus shifts

Reported by: guest Owned by: benschell
Priority: high Milestone: 1.1
Component: DojoX Grid Version: 1.0
Keywords: grid focus Cc:
Blocked By: Blocking:


When using a Grid with subgrids, (as in the subgrid test,) the focus model breaks between the subgrid row and the row of the same index in the parent Grid.

The behavior is visible in the test URL referenced below by expanding the second and third rows ("Cheapy" and "Luxuria") and hovering over the subgrid rows which appear. While the example isn't dramatic, you will see that the first row in the parent grid ("Ageragia") receives and loses focus along with the subgrid row.

The issue is magnified in cases where a given subgrid contains a greater number of rows and even more so should the parent grid have rows outside the viewable area. In simple point, if you're viewing a subgrid belonging to grid row 100 and hover over the first subgrid row, the parent Grid jumps to it's first row... which makes a usability angel cry and makes me sad.

This issue sounds similar in nature to that of #5314, where "widgets in widgets" damage each other. (I think there are issues beyond just focus, but have not experimented enough to document them coherently.)

For additional information or should an additional example be required, see Jo-jo in #dojo.

Reference URL:

Attachments (1)

5316.patch (1.5 KB) - added by benschell 14 years ago.
Fixes both row- and column-selection

Download all attachments as: .zip

Change History (13)

comment:1 in reply to:  description ; Changed 14 years ago by guest

Replying to guest:

After posting this ticket, I'm not certain that my scalability / order of magnitude example is strictly Grid's fault. (The bit about jumping to the parent row when further down the lazy-load area.) Were it the case, the example cited would jump when focusing a subgrid row further down the parent; but it does not.

I'll endeavor to make a reasonably sane example tomorrow to see if I can reproduce it as explained. It may well be my methodology and / or the fact that I'm programmatically generating everything. (djConfig="parseOnLoad: false")


comment:2 in reply to:  1 Changed 14 years ago by guest

Replying to guest:

Having diddled the test_subgrid.html page a bit, I've come to the conclusion that the order of magnitude issue must be introduced by another aspect of the system it appears on, as the parent row jumping issue cannot be reproduced in a simple proof-of-concept test.

It's quite likely to be the widget's jammed into the subgrid rows. (Yes, that would be widgets, in widgets, in widgets.)

However, the simple focus display issue as described initially still stands.


comment:3 Changed 14 years ago by benschell

Owner: changed from sorvell to benschell

I'm taking a stab at a whole bunch of Grid bugs. Re-assigning.

comment:4 Changed 14 years ago by benschell

Status: newassigned

To simplify the explanation of this bug: If a grid has grids as children, clicking on a row in the subgrid will NOT cause the correct row in the outer grid to become selected. More specifically, the row index of the inner grid is the index of the outer grid that will become selected.

In the given test page, selecting the single row in any of the generated subgrids results in the first row of the outer grid being selected, since there is only one row in any of the given sub-grids.

I've attached a patch that corrects this behavior. I store the current view on the row node when creating the individual rows. Then, when attempting to find the current row from the event target, on a potential match (specifically, on a node that has a rowIndex), I make sure that the view attached to the node matches the current view.

comment:5 Changed 14 years ago by guest

With this patch the row selection is fixed . But , the column focus handler is still linked to the parent row columns. If the focus is on the nth column in any row of the subgrid , the nth column of the parent grid in the same row is also in focus.

comment:6 Changed 14 years ago by benschell

Understood. When the event is fired, the event has a cell attribute which indicates which cell in the current Grid (the one that is handling the fired event) is clicked on. If a subgrid cell is clicked on, that cell property is set correctly on the first event (the one fired/handled by the subgrid), but is set incorrectly on the outer parent grid.

New patch uploaded which fixes this. While finding the parent cell in the grid, ensures that that cell's row/div belongs to the current Grid's view (much like in the fix for row-handling).

Changed 14 years ago by benschell

Attachment: 5316.patch added

Fixes both row- and column-selection

comment:7 Changed 14 years ago by Jared Jurkiewicz

Resolution: fixed
Status: assignedclosed

(In [12515]) Fix to grid selection from Ben Schell. fixes #5316 !strict

comment:8 Changed 14 years ago by Jared Jurkiewicz

Tested this using test_grid_subgrid.html.

Test selections of child grid rows passed in:

IE 6


Safari B3

comment:9 Changed 14 years ago by Jared Jurkiewicz

(In [12519]) Putting the check back in. It needs to test because there are cases where view is undefined. refs #5316 !strict

comment:10 Changed 14 years ago by dylan

Milestone: 1.1

comment:11 Changed 14 years ago by sjmiles

Resolution: fixed
Status: closedreopened

In [12515], attaching the view object to the node causes Grid to leak memory on IE.

We will have to look at this and try to solve it another way.

comment:12 Changed 14 years ago by sorvell

Resolution: fixed
Status: reopenedclosed

(In [12791]) !strict fixes #5316 This slight patch avoids the IE6 memory leak introduced in [12515] by using the same logic but storing the id of the grid view on the node rather than a reference to the view itself.

Note: See TracTickets for help on using tickets.