356342 - range up/down keyboard navigation regression

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[aaronr]

I meant to make sure that this was fixed as part of bug 355619 and I forgot to verify that it was.

In 0.6 (and in XSmiles) PageUp increases the range value and PageDown decreases the range value.  But at some point after 0.6 they got reversed.  Correspondingly, I also think we should have the Up key increase value and Down key decrease value.

Be nice to get this in 0.7, I guess, so that we don't confuse users.

Comment 1

[aaronr]

Attachment: testcase

Comment 2

[aaronr]

Attachment: patch 1

Comment 3

[alexander :surkov (:asurkov)]

Imo that's right fix. But the reason why I did this regression is I was confused by xul:scale behavior. I found the page about keyboard mapping for slider controls (http://java.sun.com/products/jlf/ed1/dg/appendix.htm). But it doesn't mean we should acts like java controls I guess.

I think we need to get option of AaronLev to be 100% sure all we are doing is right (and then we should file bug to xul:scale widget).

Also Java look and feel design guidlines suggest to jumps in left/top direction approximately 20% of the scale on PgUp pressing. I guess it makes sense. At least I guess it looks better than to jump on two step size. Is it ok and can we add this to this bug?

Comment 4

[aaronr]

(In reply to comment #3)
> Imo that's right fix. But the reason why I did this regression is I was
> confused by xul:scale behavior. I found the page about keyboard mapping for
> slider controls (http://java.sun.com/products/jlf/ed1/dg/appendix.htm). But it
> doesn't mean we should acts like java controls I guess.
> 
> I think we need to get option of AaronLev to be 100% sure all we are doing is
> right (and then we should file bug to xul:scale widget).
> 
> Also Java look and feel design guidlines suggest to jumps in left/top direction
> approximately 20% of the scale on PgUp pressing. I guess it makes sense. At
> least I guess it looks better than to jump on two step size. Is it ok and can
> we add this to this bug?
> 

For now I want to get this patch into 0.7 so that we don't change the behavior on the user, especially without a clear cut final answer.  Thanks for the pointer to what Java does.  That is interesting that they are different.  I wonder if they did it for a particular reason?  Windows does it our way and I think when we were going through this before I verified with Javier and Allan that Mac and Linux also behave this way with their native slider widgets.  Though on Linux it probably matters which graphical package you are running.  I guess we should find out why the xul guys made the decision that they did to be thorough.  Should we open a bug to track this?

You are right, I'm beginning to see that that 2*step isn't a big enough jump.  But I'm afraid if we try to figure out the jumping using any kind of computational math we might run into an issue or two and I don't want to hold up 0.7 any more.  So lets do it in a seperate bug.  Or in the same bug where we make a final decision about the slider direction.

Comment 5

[aaronr]

I guess in the end the decision should be based on -> if we were to have vertical sliders (be nice to have at some point) would the largest value be 'up' at the top of the slider, or 'down' on the bottom of the slider.  Might be worth hashing this out with the WebForm guys, too, so that we behave similarly to them if we end up not using a common widget for this.

Comment 6

[aaronr]

checked into trunk

Comment 7

[alexander :surkov (:asurkov)]

I filed new bugs for ally issues those are bug 356499 and bug 356498.

Comment 8

[aaronr]

checked into 1.8.0

Comment 9

[aaronr]

checked into 1.8.0 branch on 2006/10/13

Comment 10

[aaronr]

checked into 1.8 branch on 2006/11/21