|
BTW, you can tell it's the loss of the mouse-up event because if you leave the mouse button pressed down steadily, then drag the pointer over the repositioned button, and then release the button, the paging action will take place normally.
Actually it was in 2-3-x as well.
I would dearly love to understand just what's triggering this, but curing the symptom is straightforward enough: just add "white-space:nowrap;" to the gbLeftNav and gbRightNav definitions in "gradebook.css".
Fix checked into the 2-4-x branch at revision 32715. I'll re-assign to Lance to merge into the Gradebook trunk. We changed this in a local overlay of gradebook.css for the post-2.4 version and the fix resolves the issue for us.
merged fix into trunk r33720
FIxed in trunk r33720, post-2.4.0 r34254
Resolving this as it's fixed in trunk, 2-4-x and post-2.4.
Lance, your call whether you wish to further merge it into 2-3-x. Tested on OSP Nightly r. 34554. When clicking on the right arrow, the page stays the same as it should and new page loads properly.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Clicking on paging widget right-arrow causes widget to wrap
The cause can't be changes between "enabled and disabled" buttons, since it happens dynamically on a single page. Could it have something to do with the "focus" state?
Here's the class hierarchy of the buttons:
DIV.portletBody > FORM#gbForm > table.gbContainerNav tbody tr TD.gbRightNav > DIV.shorttext > DIV.listNav > INPUT
One thing I notice in the default skin's tool.css is:
.shorttext input{
}
.shorttext input:focus{
border: 1px solid #000;
}
Since the default border around a button in FireFox is 2px, the result is that clicking on a button will make it shrink a bit. I think it's a usability no-no to resize or reposition buttons like that, so it might be good to rethink this. However, removing that bit of CSS doesn't get rid of the bug.