Opened 10 years ago

Closed 8 years ago

#9756 closed defect (fixed)

Grid can't scroll right using the scrollbar arrows

Reported by: Bryan Forbes Owned by: Becky Gibson
Priority: high Milestone: 1.4
Component: DojoX Grid Version: 1.3.2
Keywords: a11y Cc: Bryan Forbes
Blocked By: Blocking:


If you try to click the right arrow on the bottom scrollbar, the scrolling gets reset to the very left.

Attachments (1)

9756.patch (7.2 KB) - added by Becky Gibson 10 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 10 years ago by Graham Collinson

Looks like the focusmanager receives a blur and then a focus event whenever the bottom scrollbar is clicked on. The focus event causes the last selected column to be scrolled into view.

Changed 10 years ago by Becky Gibson

Attachment: 9756.patch added

comment:2 Changed 10 years ago by Becky Gibson

Created a patch that no longer sets actual focus on the header cells but instead uses aria-activedescendant. The browser will now tell the screen reader which cell is "active" so the screen reader will speak the contents. I suspect this breaks the grid keyboard tests - will look into that. With activedescendant I have to set and remove the focus class on the header cell manually so there may still be some bugs to ferret out. Also, even with this fix the first click of the scroll bar doesn't work, you have to click it again to actually scroll. I'm looking into that.

comment:3 Changed 10 years ago by Graham Collinson

The remaining issue for the first click appears to be down to the following code in doscroll in _View.js:

this.scrollboxNode.scrollLeft = isLtr ?

this.scrollboxNode.clientWidth - this.scrollboxNode.scrollWidth : this.scrollboxNode.scrollWidth - this.scrollboxNode.clientWidth;

comment:4 Changed 10 years ago by Becky Gibson

(In [20105]) fixes #9802 refs #9756 Use aria-activedescendant to identify the column headers to a screen reader rather than setting focus to the column header. This does have some side effects with current screen readers. With JAWS 10 the column headers are spoken only the first time they are traversed. If you shift tab back to the column headers they are not spoken. Both Firefox and JAWS are being updated to better support the use of aria grid roles and aria-activedescendant so this should be fixed in future releases of those products. Also no longer puts tabindex=-1 on the ViewHeaderNode? as that inappropriately adds it to the accessibility hierarchy. Combined with the previous change, since focus is no longer going into the header nodes, the onblur handler for this viewheadernode is no longer needed to clear the focus border. !strict

comment:5 Changed 10 years ago by Becky Gibson

Resolution: fixed
Status: newclosed

I created #10065 for the remaining (minor) scrolling issue in Firefox. Closing as fixed.

comment:6 Changed 9 years ago by robwaite

Resolution: fixed
Status: closedreopened

There are a few tickets that seem related to this one. I switched to 1.4 a few days ago from 1.2.2 and started seeing this behavior. I can see changeset 20105 is included in 1.4.

My grid sadly is buried within quite a bit of complexity so I cannot give a quick test page to show it. It however acts just like mentioned in 9722. If I have my headers set to "display:none;"... the behavior shows up. If I click to scroll down... it alternates between scrolling as I would expect whereas the next click will send it right back to the top. If I set my headers to be visible... the behavior goes away.

For anyone who is having similar troubles... I just went into dojox.grid._FocusManager and commented the six lines that say "this._connects.push(..." in the constructor out. My guess is that now I won't get aria type support or something along those lines... but at the moment... breaking focus and tab functionality is much better than broken scrolling (which is key for our application).

comment:7 Changed 9 years ago by Adam Peller

Keywords: a11y added

comment:8 Changed 9 years ago by Becky Gibson

since #9722 was opened before the change was made to fix this ticket, I suspect it is not a dup.

comment:9 Changed 9 years ago by robwaite

I wouldn't expect anyone to work on this since I don't have a test case for ya... but when I was trying to sort out the cause... I found a line that caused it in my test case.

In the _FocusManager... there is a function "doFocus". Within that method... there is a conditional call to "this.focusHeader()". My test case was to open my app and simply click the bottom arrow of the vertical scrollbar. It would unconditionally happen (at least the way my code is written). If I commented this line out... that test sequence stopped reproducing the error. However... if I started hitting "tab", the error would show again (probably since there are other calls to "focusHeader()" elsewhere.

Just figured this might help someone pinpoint the issue... however... since I am lacking a test page that demonstrates it... my feelings won't be hurt : )

comment:10 Changed 8 years ago by evan

Not reproduced in trunk for 1.6.

Need to close this.

comment:11 Changed 8 years ago by Adam Peller

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.