Bug 42499 – [GTK] Scroll events on <select> elements should cycle content, not scroll page

• Status: UNCONFIRMED
• Component: WebKitGTK

[Reinout van Schouwen]

In GTK comboboxes, default behavior is to cycle the option items on scroll events when the mouse cursor is over them.
The comboboxes used to render <select> elements, however, ignore scroll events and the page is scrolled instead.

[Sergio Villar Senin]

This not only happens in comboboxes but in general in any content with a scrollbar. It's quite easy to see this for example in the bugzilla advanced search page https://bugs.webkit.org/query.cgi?format=advanced.

When trying to go through the list of components with the mouse wheel the whole page is scrolled. Raising severity.

[Martin Robinson]

With the latest stable the behavior for me is:
1. If the select box is not at the maximum/minimum scroll extent, the box is scrolled.
2. If the select box is at the maximum/minimum scroll extent the page is scrolled if the wheel event scroll the page if it continues in the direction of the extent of the scrollable content.

This is consistent with how iframes work and how other WebKit browser operate. Are you seeing a different behavior?

[Sergio Villar Senin]

(In reply to comment #2)
> With the latest stable the behavior for me is:
> 1. If the select box is not at the maximum/minimum scroll extent, the box is scrolled.
> 2. If the select box is at the maximum/minimum scroll extent the page is scrolled if the wheel event scroll the page if it continues in the direction of the extent of the scrollable content.

That will be the desired behaviour indeed.
 
> This is consistent with how iframes work and how other WebKit browser operate. Are you seeing a different behavior?

Completely different. I'm using trunk, and what I see is the following. When I scroll over a select box, the widget is scrolled a bit in the right direction bug after that the whole webView is scrolled as if I was not scrolling over the select widget.

After some research, looks like the problem here is that the GdkEvent we get comes with deltaX and deltaY equal to 0 most of the times. That's the reason why our handlers ignore the scroll event and it is finally managed by the scrolled window. Will try to check why those events do not come with the proper delta values.

Maybe a regression in gtk...

[Sergio Villar Senin]

Interestingly I cannot reproduce this with MiniBrowser so it seems it's a WK1-only issue