Opened 11 years ago

Closed 10 years ago

#7158 closed defect (fixed)

[patch] [cla] Grid does not scroll horizontally in IE when navigating using keystrokes

Reported by: Joseph Scheuhammer Owned by: Bryan Forbes
Priority: blocker Milestone: 1.3
Component: DojoX Grid Version: 1.1.1
Keywords: a11y Cc: Becky Gibson, davidb
Blocked By: Blocking:

Description

Testing: IE7/IE6/WinXP, .../dojox/grid/tests/test_keyboard.html (nightly 2008-07-11)

  1. Either click on a cell, or tab to it. Selection is shown via a dotted blue border.
  2. Tab or right-arrow to move to the next cell in the row.
  3. Continue moving right until reaching the right edge of the view of the grid.
  4. The next move to the right still selects the next cell in the row, but the scrolling behaviour is (a) shift the view to the left, (b) shift the view back.
  5. The result is that one cannot see the currently selected cell.
  6. Continuing to move further right shows the same jerky shift/reset behaviour.
  7. Ditto for moving back to the left.

For FF2 and FF3, the view scrolls appropriately.

Attachments (4)

HeaderRow.html (11.6 KB) - added by Joseph Scheuhammer 11 years ago.
Tab navigation of header vs. header content
7158.patch (1.0 KB) - added by Joseph Scheuhammer 11 years ago.
7158a.patch (2.1 KB) - added by Joseph Scheuhammer 11 years ago.
7158b.patch (2.0 KB) - added by Joseph Scheuhammer 10 years ago.
For IE7 or earlier, synchronize the <div> containing the header cells with the grid's scrollbox.

Download all attachments as: .zip

Change History (23)

comment:1 Changed 11 years ago by Bryan Forbes

Milestone: tbd1.2

comment:2 Changed 11 years ago by Bryan Forbes

Resolution: fixed
Status: newclosed

This was fixed in [15090].

comment:3 Changed 11 years ago by Joseph Scheuhammer

There is still odd horizontal scrolling with respect to the headers using IE. There are two ways to reproduce:

Testing: IE7/WinXP, .../dojox/grid/tests/test_keyboard.html (nightly 2008-09-03)

  1. TAB to a header.
  2. Right-arrow until the grid starts to scroll to the left (e.g., "Column 8").
  3. Left-arrow once.

The entire row of header cells shifts such that "Column 1" is shown as the left-most column within the scroller "viewport". As a result, the column header cells are no longer vertically aligned with the rest of the grid.

Another way to reproduce:

  1. Navigate to a cell within the grid.
  2. Right-arrow until the grid starts to scroll to the left (e.g., "Column 8").
  3. Shift-TAB to move focus to the column's header.

Again, the header row shifts all the way right and vertical alignment with the rest of the grid is off.

comment:4 Changed 11 years ago by Joseph Scheuhammer

Here is another clue.

  1. Navigate (right-arrow) among the headers until "Column 13" is in view.
  2. At this point, columns 10 through 13 are in full view, with only the right half of "Column 9" in view.
  3. Left-arrow three times. The column headers shift and the header with focus is no longer in view. Nonethelss, the "Column 10" header has focus after the third left-arrow.
  4. Left-arrow one more time, putting focus on "Column 9". "Column 9" comes into view, and the columns headers are now properly vertically aligned with the grid.

Thus, if scrolling is needed to bring a header into view, column headers scroll properly. This suggests the scroller must be updated even if when no scrolling is required. But, that feels like a hack.

comment:5 in reply to:  4 Changed 11 years ago by Joseph Scheuhammer

Resolution: fixed
Status: closedreopened

Replying to clown:

That first step should have been as follows.

Here is another clue.

  1. Navigate (right-arrow) among the headers until "Column 13" has focus.

Also, I forgot to re-open the bug. Doing so now.

comment:6 Changed 11 years ago by Joseph Scheuhammer

The following attachment provides another clue.

It contains two stripped-down versions of the markup for a grid, where there are only the header elements. Note that there is no script in the document.

In the first grid, the headers all are marked with @tabindex=0 to allow tab navigation among them. In IE6/7, as one tabs through the headers and into the clip area, although focus moves to the header element, it does not scroll into view. It does scroll in FF2/3.

In the second gird, the header elements have no @tabindex attribute, but their first child has @tabindex=0. Here, as one tabs through the header content, the headers do scroll in all browsers.

This indicates that the script will have to somehow force scrolling for header elements in IE. I don't know how to specifically do that, but I am investigating how.

Changed 11 years ago by Joseph Scheuhammer

Attachment: HeaderRow.html added

Tab navigation of header vs. header content

comment:7 Changed 11 years ago by Joseph Scheuhammer

The following patch fixes the problem, but, well, it's a hack. It handles the bug for tweaking the scroller after focus has been put on a column header. That forces realignment of the headers with the rest of the grid.

A better way would be:

  1. calculate the horizontal scroll position of the header element before focus is moved to it.
  2. focus the header.
  3. determine if the position of the header is different than that calculated at step 1.
  4. adjust the relevant parent element as needed to move the header back to where it should be.

Tweaking the scroller does all of the above "for free".

Changed 11 years ago by Joseph Scheuhammer

Attachment: 7158.patch added

comment:8 Changed 11 years ago by Joseph Scheuhammer

Patch file "7158a.patch" is a much less hacky way of solving the problem. The culprit is the DIV element with class 'dojoxGridHeader'. In IE, when focus moves to one of its descendant TH elements, DIV.dojoxGridHeader is scrolled horizontally back to zero. The latest patch looks for that anomaly and scrolls the DIV back to where it should be.

This is not completely satisfactory since it relies on knowing the DOM structure of the grid header, and knowing which element therein is causing the problem. If the header structure ever changes to a different nesting of DIV's, for example, this patch may stop working.

Changed 11 years ago by Joseph Scheuhammer

Attachment: 7158a.patch added

comment:9 Changed 11 years ago by bill

Summary: Grid does not scroll horizontally in IE when navigating using keystrokes[patch] [cla] Grid does not scroll horizontally in IE when navigating using keystrokes

comment:10 Changed 11 years ago by bill

Milestone: 1.21.3

comment:11 Changed 10 years ago by Bryan Forbes

Priority: normalhigh

comment:12 Changed 10 years ago by Jared Jurkiewicz

7158a.patch causes other issues. I just applied it to trunk as a test to see if it was a better fix for the issue noted at the bottom of 7273 and it isn't. In fact, any click on the header resets left scroll. This is a problem because if it always does that you can't ever sort on a header that's outside the viewport of the grid (and as such you have to scroll to get to).

I recommend rethinking that patch.

comment:13 Changed 10 years ago by Joseph Scheuhammer

Noting that this defect does not occur in IE8RC1.

comment:14 Changed 10 years ago by Joseph Scheuhammer

Taking a cue from jaredj, and his patch for #7273, I have revisited my last patch, and modified. The new "7158b.patch" follows.

In IE7 or earlier, this will adjust the <div> that contains the header cells according to the scrollbox associated with the main grid content.

Changed 10 years ago by Joseph Scheuhammer

Attachment: 7158b.patch added

For IE7 or earlier, synchronize the <div> containing the header cells with the grid's scrollbox.

comment:15 Changed 10 years ago by Jared Jurkiewicz

Priority: highhighest

comment:16 Changed 10 years ago by Jared Jurkiewicz

This may be fixed in the latest Grid. I loaded the test in IE, selected a cell, and could arrow right and I saw the header scroll and the grid, and could continue ot see the selected cell.

comment:17 Changed 10 years ago by Jared Jurkiewicz

It doesn't seem perfect(jerky), but it does scroll left/right and I can see the currently selected cell.

comment:18 in reply to:  16 Changed 10 years ago by Joseph Scheuhammer

Replying to jaredj:

This may be fixed in the latest Grid.

Bad behaviour remains. Here's an outline:

IE6/IE7:

  1. Navigate to a cell such that it has focus.
  2. Arrow right to a cell that causes right scrolling, say, column 13.
  3. Shift-Tab to navigate to a header cell.

Result: While the correct header cell has focus, the entire header row is scrolled back to the far left -- header cells 1-5 are visible, but the header cell with focus is not (header 13). The rest of the grid remains scrolled to the position it had before step 3 (aka, the correct position). Visually, the header row is misaligned with the rest of the grid.

FF2/FF3 (both Mac and WinXP):

  1. Navigate to a cell such that it has focus.
  2. Cursor right to a cell that causes right scrolling say column 13.
  3. Shift-Tab to navigate to a header cell.
  4. Arrow left to a header cell to cause left scrolling, say header 3.
  5. Shift-tab away from the header/grid.
  6. Tab back to the header.

Result: Focus is correctly placed on the header in column 13, the header row scrolls right to put header 13 into view, but the grid below does not scroll. A subsequent TAB will put focus on the cell navigated to at step 2 (in column 13), and the grid will then align properly with the header row.

Why column/cell 13? The _FocusManager maintains a record of the last cell that had focus. This is done for situations where the user leaves the grid and then returns -- it conveniently places the user back at the cell the were last on. This is not a bad thing; it just explains why focus goes to something in column 13 in the steps above. If horizontal scrolling worked properly...

comment:19 Changed 10 years ago by Bryan Forbes

Resolution: fixed
Status: reopenedclosed

Fixed in [17023]

Note: See TracTickets for help on using tickets.