Project

General

Profile

Bug #4485

Bug in FWD scrollbar: inconsistent highlighting

Added by Vladimir Tsichevski over 4 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
12/17/2019
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

History

#1 Updated by Vladimir Tsichevski over 4 years ago

A minor bug in FWD scrollbar implementation:

  1. move the mouse pointer to the scrollbar area; the scrollbar is highlighted, as expected (changes its color from blue to orange);
  2. press the left mouse button, nothing visible happens;
  3. without dragging the scrollbar, release the left mouse button;
  4. the scrollbar color changes back to its normal blue, which is not expected, since the mouse is still in the scrollbar area;
  5. now you can press and release the mouse button any times, the scrollbar color does not change, until you move the mouse again.

I think, one of the following behaviors would be more correct:

  1. the scrollbar is highlighted as long as the mouse pointer is in the scrollbar area;
  2. optionally: the scrollbar presentation is different while dragged.

#2 Updated by Greg Shah over 4 years ago

It is a requirement that we must be compatible with the Windows scrollbar behavior.

It sounds like you are describing behavior for the material theme, which has no Windows look and feel counterpart. But the core behavior is really driven by the shared implementation. This sets the event processing, which from your description does seem wrong.

Hynek/Eugenie/Stanislav/Ovidiu: What are your thoughts?

#3 Updated by Stanislav Lomany over 4 years ago

It's good to know 1. what themes are affected 2. is web/gui affected 3. "normal"/browse scrollbars.

#4 Updated by Ovidiu Maxiniuc over 4 years ago

The solution is to analyse more in depth the mouse gestures when handing the scrollbars. There are 3 states (and probably one colour for each in Material theme)
  • normal state: no mouse over - I guess this should be fine;
  • mouse hover: mouse inside bounds, but not pressed; - again this should be fine
  • scrolls locked (grabbed while button is down): once the user clicks on the scrollbar, the mouse CAN leave the bar's area but the move (on the direction of the scrolls) events are intercepted and the bars's value changes accordingly.

Probably it's just a bug. I am thinking that the press/release event is not properly handled in ScrollBarGuiImpl class and its controller.
If the Material theme designer agrees, I would go for a lighter blue colour for mouse hover state (when mouse is inside bounds but not pressed).

#5 Updated by Greg Shah over 4 years ago

If the Material theme designer agrees,

I thought that was you. :)

I would go for a lighter blue colour for mouse hover state (when mouse is inside bounds but not pressed).

It seems quite reasonable. Do we need new hooks for the theme API?

Also available in: Atom PDF