Community
Participate
Working Groups
We are trying to make pages more consistent with each other. One area where we are all over the map is the selection and cursoring emphasis and behavior. The way one would navigate through the following things hsould be similar: - search results - navigator - outliner - settings categories Talking to McQ, Ken, Simon, Anton, we think we want the following (needs to be drilled into, reviewed for accessibility)... - get rid of checkbox selection - selection should be hittable in full width of row with the mouse/finger - if there are links in the row, you have to click on the link or navigate to the link and hit enter/space to invoke it - multi select should be the normal extended select model (ctrl/shift click) - keyboard users should be able to cursor by row and hit the space bar - cursor emphasis for rows with columns should include a row emphasis (such as our light blue) as well as something that shows you what column in the row (if applicable) would respond to keystroke. For example, the link in the nav should get the dotted line emphasis when its row is highlighted.
I think we could contain most of these changes in the treetable, but it means we have to generalize our keyboard navigation beyond just trees and include tabular pages like git log, etc. But I think there are things that aren't though yet. If one cursors up and down through each row, and spacebar is selection, what if the "current" item in the row is a link? Shouldn't spacebar invoke the link? etc. We need to take a good look at various web gridlike presentations and make sure we have thought this through.
Max just pointed me to this example. It is getting at what we are getting at... http://codetalks.org/source/widgets/grid/grid.sample.html
I am taking this priority in my M2 work items.
Max has some good reference material about keying through lists with "actionable items." It addresses some of the tougher issues regarding the meaning of keystrokes when there are multiple actionable items (links, buttons, etc.) in a gridded presentation. We weren't sure how practical the specs were/if anyone has implemented some of it yet. We'll want to look at other sites for examples, etc. and talk it out before we implement.
Another example (dojo tree grid) http://archive.dojotoolkit.org/nightly/checkout/dojox/grid/tests/test_treegrid.html Note that they don't really do "total row" cursoring, it's more like row highlighting and then the cursor is on the "cell." This lines up kind of nicely with the actionable item concept. Here's how I imagine it working: - you can tab into the list and out of the list. The list is one focusable entity via tab stops. However I don't think we should be showing a highlight for the entire list div. The user thinks of being on a particular row/cell, not a big rectangle around the whole tree. When focus lands on the tree, we show a cursor at current location (much like we show the blue row right now). - cursor up and down moves from row to row. The highlight is on a row. But the cursor is on a focusable cell. In the nav, for example, cursoring up and down highlights the row, but the cursor is on the link. Hitting space or enter would follow the link, and it's clear that this is what happens. - if we had other "actionable cells" besides the link, cursoring right and left would move to those. For example, the chevron menu (if we don't get rid of it). Or think about git log...you'd move horizontally from the commit link to the buttons. Wherever we show cursor, the space/enter will invoke that particular item. - tree adds ctrl+left and ctrl+right expand and collapse but otherwise acts the same. - mouse clicks change the selection (shift click extends the range, ctrl click adds to the selection) - cursoring changes selection (selection follows cursor) unless user is also holding shift or control down
If the checkboxes are going away and multiselection requires Ctrl/Shift, do we have a multiselection story for touch devices?
(In reply to comment #6) > If the checkboxes are going away and multiselection requires Ctrl/Shift, do we > have a multiselection story for touch devices? I've been thinking about this a little, too. I think the real tension with checkboxes is that if the list is largely single select, they just make your life harder: - they make clutter, are ugly - they make single selection too hard, you have to keep deselecting things to move from single select to single select So the "ctrl-click" mode tries to fix that by making it behave single select with user gesture to get to multiselect mode. So it will be important to look at each page and say...what is the intended selection model...some pages are largely single select in practice (sites), others are more container-select (search) and nav is kind of the classic listbox select. We should probably be distinguishing these semantic modes in the API rather than one size fits all. Single select we could lose the checkboxes. Container select you probably always have checkboxes, at least at the parent. And then the list box style select...touch is an issue. For touch devices I can imagine two options (both involving checkboxes). 1 - use css media queries to make the checkboxes appear for touch. Today we style them differently (more hit padding) for smaller screens, but we could instead style them differently (or style them in/out). The cell level navigation doesn't conflict with having checkboxes (or not), so I don't see that we are changing the model if a user is moving between those devices. A non-touch user might use ctrl-click, etc. and when cursoring, the space bar applies to the focused cell, which is probably the nav link (or maybe a command button). If a checkbox is also there, it's a navigable cell, and hitting space would select the row. On a touch device the checkbox is there and the user is touching the actionable items vs. cursoring. 2 - Make multi select mode something explicit, where the user decides they are working with multiples. Where a keyboard user uses "control" key, a touch user checks a "select more than one" box and now we are in a toggling select mode. At that point checkboxes could be an affordance or you could just be toggle selecting by touching in the row.
(In reply to comment #7) > (In reply to comment #6) > > If the checkboxes are going away and multiselection requires Ctrl/Shift, do we > > have a multiselection story for touch devices? > > I've been thinking about this a little, too. > > I think the real tension with checkboxes is that if the list is largely single > select, they just make your life harder: > - they make clutter, are ugly > - they make single selection too hard, you have to keep deselecting things to > move from single select to single select > > So the "ctrl-click" mode tries to fix that by making it behave single select > with user gesture to get to multiselect mode. > > So it will be important to look at each page and say...what is the intended > selection model...some pages are largely single select in practice (sites), > others are more container-select (search) and nav is kind of the classic > listbox select. > > We should probably be distinguishing these semantic modes in the API rather > than one size fits all. Single select we could lose the checkboxes. Container > select you probably always have checkboxes, at least at the parent. And then > the list box style select...touch is an issue. > Yes, leaving check box in the parent level for container mode is a good idea. > For touch devices I can imagine two options (both involving checkboxes). I prefer to the second option. > > 1 - use css media queries to make the checkboxes appear for touch. Today we > style them differently (more hit padding) for smaller screens, but we could > instead style them differently (or style them in/out). The cell level > navigation doesn't conflict with having checkboxes (or not), so I don't see > that we are changing the model if a user is moving between those devices. A > non-touch user might use ctrl-click, etc. and when cursoring, the space bar > applies to the focused cell, which is probably the nav link (or maybe a command > button). If a checkbox is also there, it's a navigable cell, and hitting space > would select the row. On a touch device the checkbox is there and the user is > touching the actionable items vs. cursoring. > > 2 - Make multi select mode something explicit, where the user decides they are > working with multiples. Where a keyboard user uses "control" key, a touch user > checks a "select more than one" box and now we are in a toggling select mode. > At that point checkboxes could be an affordance or you could just be toggle > selecting by touching in the row.
(In reply to comment #0) > We are trying to make pages more consistent with each other. > One area where we are all over the map is the selection and cursoring emphasis > and behavior. The way one would navigate through the following things hsould > be similar: > - search results > - navigator > - outliner > - settings categories > > Talking to McQ, Ken, Simon, Anton, we think we want the following (needs to be > drilled into, reviewed for accessibility)... > > - get rid of checkbox selection > - selection should be hittable in full width of row with the mouse/finger > - if there are links in the row, you have to click on the link or navigate to > the link and hit enter/space to invoke it Not sure if I completely understand this. Are we saying clicking on a link will no longer open it right away? > - multi select should be the normal extended select model (ctrl/shift click) > - keyboard users should be able to cursor by row and hit the space bar > - cursor emphasis for rows with columns should include a row emphasis (such as > our light blue) as well as something that shows you what column in the row (if > applicable) would respond to keystroke. For example, the link in the nav > should get the dotted line emphasis when its row is highlighted.
(In reply to comment #4) > Max has some good reference material about keying through lists with > "actionable items." It addresses some of the tougher issues regarding the > meaning of keystrokes when there are multiple actionable items (links, buttons, > etc.) in a gridded presentation. We weren't sure how practical the specs > were/if anyone has implemented some of it yet. > > We'll want to look at other sites for examples, etc. and talk it out before we > implement. I remember that Max implemented something in his branch to key-bind the action items in navigator. Max, is that code in head now? We should make that part generic into the treeModelIerator.
(In reply to comment #10) > I remember that Max implemented something in his branch to key-bind the action > items in navigator. > Max, is that code in head now? > We should make that part generic into the treeModelIerator. No, the code has not been pushed into master. Susan had some concerns about the generalizability ui-wise of creating keybindings for that of thing if I recall correctly. (And the rest of the patch would likely need some tweaking if the key navigation in this bug is implemented)
(In reply to comment #9) > > - if there are links in the row, you have to click on the link or navigate to > > the link and hit enter/space to invoke it > Not sure if I completely understand this. Are we saying clicking on a link > will no longer open it right away? My punctuation wasn't clear. You have to either "click on the link" or "navigate to the link and hit enter/space". So clicking works the same, but we need a way to cursor to it and hit enter/space. (In reply to comment #11) > (In reply to comment #10) > > I remember that Max implemented something in his branch to key-bind the action > > items in navigator. > > Max, is that code in head now? > > We should make that part generic into the treeModelIerator. > > No, the code has not been pushed into master. Susan had some concerns about the > generalizability ui-wise of creating keybindings for that of thing if I recall > correctly. (And the rest of the patch would likely need some tweaking if the > key navigation in this bug is implemented) My concerns are: - the chevron menu might go away - if it stays, it shouldn't be special. It is just a button and should be cursorable the same way that one should be able to cursor to a link, a button, etc. in a row. So I think we need to define the generic cursor strategy for grids like git log and tree grids like the nav and search results. In my mind they should be the same cursor model except that trees add the ctrl-left and ctrl-right for expand/collapse, but otherwise cursoring to different columns and up and down the rows should work similar.
I know we had several topics since this bug was opened but I would like to summarize from the threads. I would also like to confirm some non-UI design directions. We can talk about this in today's call with Susan and Max. - Cursoring is kind of convenient for key board users, to make current "cursor" selected you need another key stroke. We should also think about using mouse to change the cursor. E.g. how do we change cursor on a row/grid with an href link filled up. - Selection. We need a good selection model/policy. In the grid situation, the tree nav model I used in navigator and search pages needs to be improved to support 2 dimensions. I think any page that consumes the selection model should be easily initialize a selector containing a model tree/list. - Keybinding. Where should we listen to key events? In navigator and search page, I did that in the main pane DIV. we definitely want to change that. - Selector integration If we go with the selector pattern , we may want to demo a typical consumption in a page. E.g. navigator. My guess is to hook up a selector after page is completely loaded.
(In reply to comment #13) > I know we had several topics since this bug was opened but I would like to > summarize from the threads. I would also like to confirm some non-UI design > directions. We can talk about this in today's call with Susan and Max. > > - Cursoring is kind of convenient for key board users, to make current "cursor" > selected you need another key stroke. We should also think about using mouse to > change the cursor. E.g. how do we change cursor on a row/grid with an href link > filled up. > > - Selection. > We need a good selection model/policy. In the grid situation, the tree nav > model I used in navigator and search pages needs to be improved to support 2 > dimensions. > I think any page that consumes the selection model should be easily > initialize a selector containing a model tree/list. > > - Keybinding. > Where should we listen to key events? In navigator and search page, I did > that in the main pane DIV. we definitely want to change that. > > - Selector integration > If we go with the selector pattern , we may want to demo a typical > consumption in a page. E.g. navigator. > My guess is to hook up a selector after page is completely loaded. Had a call with Susan and Max. We think as a start point I will have the selector integration first: - Use navigator as the demo page. - Disable the default tabbing behavior from browser if the main pane gets focus. Currently it brings the focus to the first child DIV of eh main pane .We should disable this and listen to tab event and ask the browser to tab to the next sibling. In the navigator case, the focus should go to "FAQ" at the bottom. - Introduce cell model, if any, in a row. The whole navigation model (treeModelIterater) is a tree where each node represents a row. The .parent and .children property will remain the same as for the "first dimension" cursoring. We will need another property .metaChildren to present a list of navigateable columns. - First dimension cursoring. We will keep the current behavior unchanged for up and down arrows. - We will also keep the space key for selecting current row, no matter there is check box or not. - We will use CTRL+ left or right arrows for collapse/expand. - Second dimension cursoring. We will use right arrow key to cursor on the first column if the current cursor is on a row. E.g. In the navigator page, - CTRL+right to expand a folder - down key to bring you to a file - space key to select it. - space key again to deselect it. - right key to put cursor on the file link(enter key can open it now) - right key again to put cursor on action column. - (enter key to excute the action or just pop up sub actions.) - left key to go back to file link - left key again to put the cursor back to the whole row. - down key to go to the next file row. - If your cursor is on a column, up/down key will just go to previous/next row.
started an email thread with McQ about comment #7, based on some discussion that happened on the call. McQ said: -------- First, distinguish between "click on link text" and "click in bounding area" <= we already have this. Examples: click on file/folder name in navigator versus click on timestamp click on the command text in a popup menu versus click beside it. For tablets: activate == click on link text toggle whether this item is part of the selection == click in bounding area On the desktop, we could either keep the above behavior, support purely the "desktop selection" paradigm (i.e. click == just select this item; shift click == select from last click; control(or command) click == toggle, or come up with some hybrid. Either way, there's no need for checkboxes as long as you are drawing the things that are in the selection different from the things that aren't. Susan responded: ----------------- I disagree with this bullet for tablets: >toggle whether this item is part of the selection == click in bounding area The desktop "extended selection model" came about to support "most of the time you mean change the selection, but sometimes you mean...add to it." I don't think on a tablet we can simply say "you always use toggle because you are on a tablet." Checkboxes are bad right now, not just because they are ugly, but because they assume the wrong selection model (toggle) in many situations. I have to uncheck the thing currently selected if I wanted to change selection from A to B. Consider the current git status staged/unstaged list, where a single select means "show me the diff" and I want to click around easily to look at diffs. But then I might also want to select a bunch and say "stage." This is the model for any master/details type page. Settings page, same thing. Imagine nav with a properties panel. Select and view, but occasionally there is a bulk op requiring multi select. The tablet user still needs a way to get the "add to selection" behavior without having toggle always be the default. For some cases toggle is an appropriate default, but not universally. That is why I think we still need an explicit "change to toggle select mode" on tablets. Some folks use the checkbox to make it clear you are in that mode. There's interesting discussion on this topic if you google it, the most common alternatives I found were: - explicit toggle select mode gets activated by the user - checkboxes appear - some other "you are in toggle mode" affordance appears - a toggling select prompter appears - for the horizontal case, the "move selections from left to right" picker appears (sigh, it seems to be making a comeback to solve this issue) - checkboxes always there, click on item is single and click on checkbox is toggle
Here are some of my opinions after talking to Mcq in person ans showed him the demo in nav and git log page. (In reply to comment #15) > started an email thread with McQ about comment #7, based on some discussion > that happened on the call. > > McQ said: > -------- > First, distinguish between "click on link text" and "click in bounding area" <= > we already have this. Examples: > click on file/folder name in navigator versus click on timestamp Clicking on time stamp is a faster way to move the cursor around. We are not selecting a row yet. But once we get rid of check box(at least for desktop), clicking in bounding area will just select the row and set cursor to the row. If no ctrl or shift key is pressed, we just unselect everything else and move the selection here. So ctrl+click will mean toggle selection and shift+click as range select. Combining with keybindings, where space key always mean toggling selection on the cursor and shift+up&down arrows mean range selection, I think we covered everything a selection model will do. > click on the command text in a popup menu versus click beside it. > > For tablets: > activate == click on link text > toggle whether this item is part of the selection == click in bounding area > On the desktop, we could either keep the above behavior, support purely the > "desktop selection" paradigm (i.e. click == just select this item; shift click > == select from last click; control(or command) click == toggle, or come up with > some hybrid. > > Either way, there's no need for checkboxes as long as you are drawing the > things that are in the selection different from the things that aren't. > > Susan responded: > ----------------- > I disagree with this bullet for tablets: > > >toggle whether this item is part of the selection == click in bounding area > > The desktop "extended selection model" came about to support "most of the time > you mean change the selection, but sometimes you mean...add to it." > I don't think on a tablet we can simply say "you always use toggle because you > are on a tablet." > Checkboxes are bad right now, not just because they are ugly, but because they > assume the wrong selection model (toggle) in many situations. I have to > uncheck the thing currently selected if I wanted to change selection from A to I understand what Susan is saying here, for example: In tablet,how do I move selection to a row if I already have 5 rows selected before? Do I have to toggle 5 times to unselect them? > B. > > Consider the current git status staged/unstaged list, where a single select > means "show me the diff" and I want to click around easily to look at diffs. > But then I might also want to select a bunch and say "stage." This is the > model for any master/details type page. Settings page, same thing. Imagine > nav with a properties panel. Select and view, but occasionally there is a bulk > op requiring multi select. > > The tablet user still needs a way to get the "add to selection" behavior > without having toggle always be the default. > For some cases toggle is an appropriate default, but not universally. > That is why I think we still need an explicit "change to toggle select mode" on > tablets. Some folks use the checkbox to make it clear you are in that mode. > > There's interesting discussion on this topic if you google it, the most common > alternatives I found were: > - explicit toggle select mode gets activated by the user > - checkboxes appear > - some other "you are in toggle mode" affordance appears If we can have an icon appears somewhere in tablet case, simulating CTRL key. I am not saying simulating the key event but just a gesture telling user : your tap means toggling selection instead of moving it. > - a toggling select prompter appears > - for the horizontal case, the "move selections from left to right" picker > appears (sigh, it seems to be making a comeback to solve this issue) > - checkboxes always there, click on item is single and click on checkbox is > toggle
Another thing: If we are going to leave no actions/commands in a row and use section level commands purely on selection, the grid navigation&invocation will be much simpler.
> >I have to > > uncheck the thing currently selected if I wanted to change selection from A to > > I understand what Susan is saying here, for example: > In tablet,how do I move selection to a row if I already have 5 rows selected > before? Do I have to toggle 5 times to unselect them? I talked to McQ about this today, and realized what I was missing in his idea. For the case like git status where there is a single select/default action, and then bulk operations, he assumes there is an "actionable grid item" (link, etc.) that would invoke the default action. So it's back to "click on the actionable item" vs. "click in the rest of it." This would work for the tablet case. click on the change name to see the diff. Click outside the change name to toggle the select for a bulk operation. (In reply to comment #17) > Another thing: > If we are going to leave no actions/commands in a row and use section level > commands purely on selection, the grid navigation&invocation will be much > simpler. I'm not sure they are all going away, but many of them will. For sure the chevrons will, we will have a section-level menu that operates on the multi selections. This will also fix the problem of whether something applies to the adjacent item or selection group. But when a "high use" action only ever applies to a single item in practice, we may want to keep a local command. One example of this kind of command is "Rename." I'm not saying that we would definitely keep rename as an icon (since it's not that common)...but pointing out that there are cases where we may decide to do this. I know some users (jjb) who are adamantly opposed to the ergonomics of having to separately select and then move the mouse to the top for common actions. So the trick here is to ensure we identify the ones that are really common/matter.
put intitial work in : http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=ac67b8bb5b4eb4a7ca7e307c3b9a3a2231c2378d. Now in navigator page, git log page, git status page and search page, you can use mouse + ctrl or shift to multiple select. Use up and down arrows to traverse rows, left and right to traverse grid if there are grids. In iPad, the selection will be always toggling for now. Next steps: 1.Remove the check boxes completely from navigator and provide selection from selection model to selection service. 2.there are some known issues in multiple sections of rows sharing same same model. 3.Replace page check box needs to be reconsidered. 4.Move some actions from row to section header based on the selection.
(In reply to comment #19) > put intitial work in : > http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=ac67b8bb5b4eb4a7ca7e307c3b9a3a2231c2378d. > > Now in navigator page, git log page, git status page and search page, you can > use mouse + ctrl or shift to multiple select. Use up and down arrows to > traverse rows, left and right to traverse grid if there are grids. > In iPad, the selection will be always toggling for now. > > Next steps: > 1.Remove the check boxes completely from navigator and provide selection from > selection model to selection service. cool. > 2.there are some known issues in multiple sections of rows sharing same same > model. I'll work this in bug 377500 > 3.Replace page check box needs to be reconsidered. Libing and I discussed this. We do need a "container select mode" where the parent selects the children, and selecting the children is a toggle. We don't think we need the checkbox affordance for this. An independent issue (that checkboxes sometimes handle) is that when a parent has some but not all children selected, the parent could show a state to indicate this. For now, we think this would be confusing without checkboxes, so our first try will be to not show select state on parent unless all children are selected. > 4.Move some actions from row to section header based on the selection. I'll look at the navigator first, the bug is bug 367458. It will take a little bit of time to get all of this done, because I'll need to make favorites use the explorer model in order to get the selection model and remove the inline actions. I'll take care of it, though.
This is looking really good, Libing! Per discussion I'll append problems I see in here, and when this bug is closed we can start opening new bugs. Some issues I see: - when I first open the nav, the selection model is working well. If I select something, and then select a folder link to drill into the navigator, I get an error: checkBox is null var checked = toggle ? !checkBox.checked : true; explorerNavHandler.js (line 335) - the shift select on chrome and firefox also shows the blue browser select highlight for the nodes in the selection. Kind of weird. I'm not suggesting we fight the browser. I can't think of a good answer, other than not supporting range select, but that seems lame. Can you show this around and see what others think? - the outline dotted box is quite raggedy, especially for multi-line text like git log. I did an experiment and set the git commit node to use display: inline-block This has a much nicer look to it. I'm wondering if we should do this "for free" for clients or if clients should just do this. If we do it for free, we would only do it for clients whose current setting was display: inline We wouldn't want to accidentally make a node visible that wasn't supposed to be (ie, change display: none to display: inline-block)
(In reply to comment #21) > - the outline dotted box is quite raggedy, especially for multi-line text like > git log. I did an experiment and set the git commit node to use > display: inline-block > This has a much nicer look to it. I tried a few experiments and I think the best solution is add display: inline-block to the navlink class. You can't add it to tree iteration cursor or you get some jumping as certain nodes change their vertical space.
I pulled today, downloaded new Orion version, cleaned the cache, cleaned localStorage, reloaded plugins, but still I can't get selection to work. Clicking in various places of navigator selects nothing, the "More" menu is always empty (no access to actions). On FF Ctrl+click add a blue rectangle around the item in navigator but it still does not populate the actions menu. On Chrome I can't even get this rectangle. My FF version is 12.0, Chrome 18.0.1025.168 m. I raised severity, because right now I can't use actions.
(In reply to comment #23) > I pulled today, downloaded new Orion version, cleaned the cache, cleaned > localStorage, reloaded plugins, but still I can't get selection to work. > Clicking in various places of navigator selects nothing, the "More" menu is > always empty (no access to actions). On FF Ctrl+click add a blue rectangle > around the item in navigator but it still does not populate the actions menu. > On Chrome I can't even get this rectangle. My FF version is 12.0, Chrome > 18.0.1025.168 m. > I raised severity, because right now I can't use actions. I was able to reproduce from both FF and chrome. Investigating...
(In reply to comment #24) > (In reply to comment #23) > > I pulled today, downloaded new Orion version, cleaned the cache, cleaned > > localStorage, reloaded plugins, but still I can't get selection to work. > > Clicking in various places of navigator selects nothing, the "More" menu is > > always empty (no access to actions). On FF Ctrl+click add a blue rectangle > > around the item in navigator but it still does not populate the actions menu. > > On Chrome I can't even get this rectangle. My FF version is 12.0, Chrome > > 18.0.1025.168 m. > > I raised severity, because right now I can't use actions. > > I was able to reproduce from both FF and chrome. Investigating... Fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=f3f960793d2542ed840d6969f76ac83d7a4b52c8.
There are some row cursoring/selection behaviors that I think are not standard. Compare to something like windows explorer: 1 - selection always follows cursor if there is no augmentation key 2 - ctrl-arrow will make the cursor and selection independent, with space key being the selection gesture 3- shift-arrow selects a range as you cursor What we have is currently #2, I think we need to support #1 by default and #2 when ctrl key is pressed. (How hard is this?)
(In reply to comment #26) > There are some row cursoring/selection behaviors that I think are not standard. > Compare to something like windows explorer: > > 1 - selection always follows cursor if there is no augmentation key > 2 - ctrl-arrow will make the cursor and selection independent, with space key > being the selection gesture > 3- shift-arrow selects a range as you cursor > > What we have is currently #2, I think we need to support #1 by default and #2 > when ctrl key is pressed. (How hard is this?) Should not be hard. But I would like to proto type a simple work flow to apply to my unit test. Test data: 8 rows of dummy model item in a flat model and selection model built based on that. Test 1: Simulate restoring previous selection + cursor position : row 3,4,5 were selected and cursor was on row 2 before. Test 2 (from the result of test 1): Variation 1: Simulate up key. Expected result: Row 3,4,5 are de-seleted and row 1 is selected. Variation 2: Simulate ctrl + up key. Expected result: Row 3,4,5 are still selected and row 1 is cursored. Test 3(from the result of test 2 variation 2): Simulate space key. Expected result: Row 3,4,5 are still selected and row 1 is selected as well. Test 4(from the result of test 3): Simulate down key. Expected result: Row 1,3,4,5 are deselected and row 2 is selected. Test 5(from the result of test 4): Simulate shift+down key 3 times. Expected result: Row 2,3,4,5 are selected and cursor is on row 5. Test 6(from the result of test 5): Simulate down key. Expected result: Row 2,3,4,5 are deselected and row 6 is selected.
I moved the styling related issues that are not yet fixed to bug 379831.
The selection model now almost covers all the issues addressed. I opened Bug 379971 for API exposure and unit testing after APIs exposure. I am closing this bug now.
