377018 - Several scroll events in GTK interface not handled

Status: NEW

(Thunderbird :: OS Integration, defect)

Description

[Mathias Brodala]

User-Agent:       Opera/9.10 (X11; Linux i686; U; de)
Build Identifier: Version 1.5.0.10 (20070329)

There are several places in the GTK interface where TB does not react to scroll events but where it would be expected.

For example the View dropdown left to the Search box and every tab in the whole application (the settings dialog, for example) do not allow scrolling through the available elements. This makes additional clicks necessary which decreases usability.

Please consider implementing those events. Since 

Reproducible: Always

Steps to Reproduce:
1. Fire up the Settings dialog, for example
2. Try to scroll over the main categories
3. Try to scroll over the tabs in the View category
Actual Results:  
Nothing happens.

Expected Results:  
The active tab should be changed depending on the scroll direction.

Comment 1

[Wayne Mery (:wsmwk)]

Is this seen in current beta?
http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

Comment 2

[Mathias Brodala]

(In reply to comment #1)
> Is this seen in current beta?
> http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

I will check as soon as I am back to my computer in March.

Comment 3

[Mathias Brodala]

(In reply to comment #1)
> Is this seen in current beta?
> http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

Yes, nothing has changed. Neither tabs nor select boxes do anything while scrolling over them.

Comment 4

[Ludovic Hirlimann [:Usul]]

Andreas can you confirm ?

Comment 5

[Andreas Nilsson (:andreasn)]

Yup, hovering tabs and using the scroll wheel on the mouse don't switch between the tabs. This works in gedit and nautilus it seems. Same with the dropdown.

Comment 6

[Lukas Pirl]

This makes me sad as well from time to time (feels like being back on Windows, eh?).

Since I am not into GTK and all that, I cannot judge if this is global or per-input thing but here are a few more frequently used inputs where handling the scroll-events would be an improvement:

* selecting the sender identity when composing an email
* everywhere in Lightning: all drop-down menus and spin edits

Comment 7

[Mathias Brodala]

The tabs in the setting dialog actually react to scroll events by now. But I agree, that basically every select field should also do this.