[patch] [ccla] Odd issue with selection and scroll moving.

[Jared Jurkiewicz]

This came in from a co-worker of mine. He's using a simple HTML store to render in an HTML defined table into grid. When he does selection, though, then jumps to the last row, the grid renders oddly (and shows the rows he selected previously.

I checked the HTMLStore and it is returning the proper fetch information for what was requested, so I have to assume the grid is somehow keeping old rows around/not clearing the buffer.

I also reproduced this using ItemFileReadStore?. I think it occurs when you're jumping to a place where it's not a multiple of a page.

Testcase coming.

Reproduction steps:

1.Open page in browser

2.Using Ctrl-Click, select the first 4 rows in the grid in order

3.Click the 'Last' button.

You'll see the grid jump to the last row, but with the first 4 rows visible also (see the screen capture).

Strangely, if you click 'Last', then 'First', BEFORE selecting any rows, the problem doesn't occur.

[Jared Jurkiewicz]

Testcase that fails.

[Jared Jurkiewicz]

Fails in FF2, IE 7, Google Chrome 1.0, and FF3, but not Safari 3.2 (windows, haven't tried mac).

[haysmark]

If you use the tab key and the keyboard to execute this test case, there is no problem.

As far as the mouse goes, it's not so much about ctrl clicking rows, it's the dashed focus box. Just clicking a single cell so the dashed box appears will cause this test case to fail. On the other hand, if you ctrl click several rows, then click the scroll bar to make the dashed box go away, the test case passes.

Here is an entry point for this behavior in Grid's _FocusManager:

this._connects.push(dojo.connect(this.grid,"_onFetchComplete", this, "_delayedCellFocus"));

If you modify the test case to use a local dojo instead of CDN, you can comment this line out of _FocusManager and the test case will pass.

Here is the use case for this code: when a user selects a cell (dashed border, not just purple background) and uses is using the keyboard to scroll down a grid, the user eventually runs into unpaged cells. onFetchComplete asynchronously clobbers these cells, so the user loses the focus box. _delayedCellFocus is designed to restore focus to wherever the user previously was.

The assumption is that whenever there is a cell focused (dashed border), then the user is using the keyboard to navigate inside the grid. The cell correctly loses focus when you tab away or click the scroll bar, but the cell does *not* lose focus when you click away.

Fixing the grid's blur behavior to always remove focus, like the tab key does now, will resolve this ticket.

[haysmark]

Fixes #9347. A grid cell should receive focus after a dojo.data fetch completes only if the grid already has focus.

[haysmark]

I attached a potential fix for review and testing. It prevents the grid from stealing focus if the user has intentionally clicked away.

[Jared Jurkiewicz]

(In [19809]) Commmitting in a minor update to grid. fixes #9347