1269172 - Behaviors transposed for {Click on Scrollbar} and {Shift+click on Scrollbar}

Status: NEW

(SeaMonkey :: General, defect)

Description

[Rainer Bielefeld]

Steps how to reproduce  NOT reproducible REPRODUCIBLE with  English SeaMonkey 2.43a1  (X11; Linux x86_64; rv:46.0)  Gecko/20100101 Firefox/46.0 Build 20160109003001  (Classic Default Theme) on VirtualBox Ubuntu 14.04 LTS

1. Launch Browser
2. Open Page <https://en.wikipedia.org/wiki/United_States>
   » Page with lots of contents opens, small scroll slider at top
     of scroll bar.
3. <shift+click> on middle of vertical scroll bar.
   Expected: Scrolls to middle of page contents, scroll slider stops
             at mouse click target point on scrollbar
   Actual: Scroll slider moves  down only 10 mm or so
4. <click> on middle of vertical scroll bar.
   Expected: Scroll slider moves  down only 10 mm or so 
   Actual: Scrolls to middle of page contents, scroll slider stops
           at mouse click target point on scrollbar

a) So <click> and <shift+click> are transposed.
b) All the same with Modern Theme
c) I never saw that with WIN
d) This problem has been taken form "Bug 1269145 - Scrollbar buttons 
   missing" due to <https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines#Open_a_new_bug_report_for_each_issue!>
e) I wonder whether this problem also affects Thunderbird.

@[e-mail]
I think you are able to confirm this one for SeaMonkey and Firefox?

Comment 1

[Felix Miata]

Reproduced/Confirmed on 
openSUSE Tumbleweed KDE3 and Fedora 24 KDE Plasma 5 on
Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 SeaMonkey/2.43; Build ID: 20160428142305 
openSUSE 42.1 KDE3 on
Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0; Build ID: 20160421124000

Comment 3

[Felix Miata]

(In reply to rsx11m from https://bugzilla.mozilla.org/show_bug.cgi?id=1437960#c5)
> Shift+click seems to be the advised workaround for now.

ui.scrollToClick;0 is another, but something needs to be done to change the behavior to be inherited from the DE.

Comment 4

[Johannes Leushuis]

Confirmed for Firefox 58.0.2, Thunderbird 52.6.0 and Seamonkey 2.49.2, which is out now.

In Lubuntu/LXDE, Kubuntu/Plasma and Xubuntu/XFCE, 64-bits.

Scrolling in e.g. the File Manager in Lubuntu, PCManFM, works normal: clicking anywhere in the scrollbar (also with shift, ctrl) moves one page at a time, so it is a Mozilla issue.

Many users switch to open source operating systems like Linux, given the privacy issues with Microsoft, Apple. However, as soon as the user scrolls through long documents in e.g. Wikipedia and doesn't know the workaround to switch Click and Shift-Click, the bug causes the user to switch from Mozilla to e.g. Opera.

Since the bug probably affects Mozilla's Firefox, Thunderbird and Seamonkey (at least since 2.43) in Linux already for two years, this bug needs to be resolved quickly.

Is it that somewhere in the code Shift-click and Click have been interchanged and should be interchanged again?

Comment 5

[Johannes Leushuis]

Switching from Windows to Linux because of privacy issues with Microsoft, Apple; now using 64-bits, 1TB, 4GB RAM, 50Mbps, Lubuntu (like minimal approach), testing http://ftp.mozilla.org/pub/seamonkey/releases/: 

after unpacking, one has to test in terminal with ./seamonkey  -new-instance

(when double clicking seamonkey, why do we get a choice between execute or execute in terminal? If we want to see output we would open a terminal first. Other discussion)
(why isn't . in $PATH as in Windows? Other discussion)
(why do we have to give the option -new-instance? If we want to start a window or tab in another installed seamonkey, we should give a command line option, not here. Other discussion)
(in short, double clicking some installed version of SM should just work)

To run 32-bits versions on 64-bits machines one has to follow the instructions at https://askubuntu.com/questions/698185/is-there-a-way-to-make-32-bit-mozilla-seamonkey-work-in-a-64-bit-xubuntu-14-04#698231
(why can't the machine figure this out by itself? Other discussion)

2.40/linux-i686/en-US/: scrollbar works normal
2.46/linux-i686/en-US/: scrollbar works normal
2.48/linux-i686/en-US/: scrollbar works normal
2.48b1/linux-i686/en-US/: scrollbar works normal
2.48b1/linux-x86_64/en-US/: scrollbar works normal

To run versions 2.49.1 and higher I found it helps to give
sudo apt instal gtk3.0
sudo apt install gtk3.0.0:i386
(why not automatically?)

2.49.1/linux-i686/en-US/: scrollbar works different (clicking scrollbar advances to absolute position, not one page, making scrolling through large pages difficult for people who don't know the interchange of click and shift-click)
2.49.1/linux-x86_64/en-US/: scrollbar works different
2.49.2/linux-i686/en-US/: scrollbar works different
2.49.2/linux-x86_64/en-US/: scrollbar works different

@Rainer, are you sure this error occurred already two years ago in 2.43?

Since the release notes of 2.49.1 say

    SeaMonkey now uses gtk3 on Linux. If you experience a problem because of this please file a bug and link it to 
    Switch Linux builds to GTK3 with SeaMonkey 2.49 (Bug 1367257). Pleae try another OS theme first. Some of them are buggy 
    and cause problems with SeaMonkey, Thunderbird and Firefox. 

Switching through Start <- Preferences <- Customise Look and Feel to OS theme Breeze-Dark, things remain same
Looks like the interchanged behaviour is caused by this GTK3 issue.
I'll post it there.
Rsx11m had foresight and posted there that that bug depends on this bug.
FF and TB are also affected, I'll check where and post it there also.
Can this bug be solved?

Han

Comment 6

[Johannes Leushuis]

It is not a bug, it is a feature :-|

At https://support.mozilla.org/en-US/questions/1125603 it says that now, if one left clicks the vertical scroll bar area, the contents advances right to the position where the mouse has clicked. If one right clicks the contents advances one page at a time.

But if one adds to ~/.config/gtk-3.0/settings.ini the line [Settings] gtk-primary-button-warps-slider = false , then left click advances the contents one page at a time again.

According to https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-primary-button-warps-slider , then *middle*-click advances the page right to the position where the mouse has clicked.

This is since GTK+3 version 3.6.

Which version one has installed can be found out with

dpkg -l libgtk*

It appears true for me.

Problem solved.

Comment 7

[Felix Miata]

(In reply to Johannes Leushuis from comment #6)
> It is not a bug, it is a feature :-|

Mis-feature in any DE except possibly Gnome. The default scrollbar behavior should be to automatically observe the DE's scrollbar behavior (and appearance), not any arbitrary one of any individual application's own.
 
> Problem solved.

Not "solved" on any of my installations except by setting 'ui.scrollToClick;0'

'gtk-primary-button-warps-slider = false' has yet to work in any of my many installations (of which none Gnome) and profiles, all of which have libgtk much newer than 3.6.

Comment 8

[Johannes Leushuis]

I found http://kb.mozillazine.org/Ui.scrollToClick which shows that the cross-platform preference ui.scrollToClick is indeed comparable to the application-wide or system GTK+3 preference gtk-primary-button-warps-slider.

As https://atkdinosaurus.wordpress.com/2016/07/24/restore-the-vertical-scroll-bar-functionality-in-firefox-linux/ points out, going to about:config page and creating the preference ui.scrollToClick and setting it to 0 solves the problem also indeed. Cross-platform of course since manually setting preferences overrides everything, including the ~/.config/gtk-3.0/settings.ini settings.

This raises the question what should have precedence when starting up a Mozilla application, the cross-platform preferences (of which ui.scrollToClick is not set by default in some file any more since a couple of years), or the application-wide GTK+3 settings (of which gtk-primary-button-warps-slider is not set by default in a file either).

I found Bug 803633 - [Linux gtk] Honor scrollbar preference of system, where Honor has the imperative tense.

But there is a bug in that bug report and there is perhaps a solution so that standard scroll bar behaviour comes back.

@Felix: To be sure, you said that gtk-primary-button-warps-slider = false didn't work for you. In about:config, did you reset the preference ui.scrollToClick to default and closed Seamonkey so that the manual preference is forgotten, before you added to ~/.config/gtk-3.0/settings.ini the line gtk-primary-button-warps-slider=false ?

Comment 9

[Felix Miata]

(In reply to Johannes Leushuis from comment #8)
> @Felix: To be sure, you said that gtk-primary-button-warps-slider = false
> didn't work for you. In about:config, did you reset the preference
> ui.scrollToClick to default and closed Seamonkey so that the manual
> preference is forgotten, before you added to ~/.config/gtk-3.0/settings.ini
> the line gtk-primary-button-warps-slider=false ?

Last I tested was too long ago to remember. I have lots of PCs and profiles. I tested now using XFCE on Debian Jessie, TDE on Debian Stretch, and KDE3 on openSUSE 42.3. Putting 'gtk-primary-button-warps-slider = false' in a global settings file /usr/local/etc/gtk-3.0/settings.ini or /usr/local/gtk-3.0/settings.ini is what failed. Putting it in ~/.config/gtk-3.0/settings.ini or /etc/gtk-3.0/settings.ini works.

Comment 10

[Johannes Leushuis]

The general bug/query what the order of precedence should be of cross-platform, system and user scrollbar settings, is posted as Bug 1444223 - Honour cross-platform AND system AND user scrollbar preferences. The proposal should mean in default configuration a return to standard scroll bar behaviour. Please share your opinion there.