Bug 1367257 (SM2.49-GTK3)

Switch Linux builds to GTK3 with SeaMonkey 2.49

NEW
Unassigned

Status

2 years ago
11 months ago

People

(Reporter: rsx11m.pub, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug, {meta})

SeaMonkey 2.49 Branch
All
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
For Linux, it is planned to make SM 2.48 the last official build based on GTK2; This meta bug tracks GTK3 bugs that affect 2.49.x.

Note that individual distributions may still decide in their own build config to stick with GTK2 if they consider GTK3 builds not being mature enough in their environment.

> Bug 1267982 - Context menus have no border (Linux, Gtk3)
> Bug 1269145 - Scrollbar buttons missing (GTK3)
> Bug 1323301 - Ctrl keys do not work properly when using gtk3
> Bug 1331208 - menulist-button is not visible in Classic (Default) theme under gtk3
> Bug 1334679 - GTK3 menus do not display Adwaita theme arrows or ticks

Some of these bugs depend on the installed GTK3 version and/or the desktop theme used.

Comment 1

2 years ago
Following applicable to KDE Plasma, KDE3 and TDE and possibly other non-Gnome users:

depends on wontfix bug 1269274 
[GTK+ 3.18] UI text sizes no longer inherited from Linux system

Upstream wontfix: Recent change breaks HiDPI setup based on calculated or forced DPI
https://bugzilla.gnome.org/show_bug.cgi?id=757142
Depends on: 1269274
Build config defaults to gtk3 so no change needed here.
(Reporter)

Comment 3

2 years ago
Well, yeah - I know, not in a literal but functional sense... ;-)
Depends on: 1398973
Is bug 1267982 still a problem in 2.49.2? Stated in the bug that it works fine in ESR52.
Flags: needinfo?(rsx11m.pub)
Do we still need to care about bug 1334679?
(Reporter)

Comment 6

a year ago
Both bug 1267982 (context menu borders) and bug 1334679 (submenu arrows) still apply for me using KDE4 with the 2.49.2 Linux x86_64 build1, thus the answer is yes afaict.
Flags: needinfo?(rsx11m.pub)
(Reporter)

Updated

a year ago
Depends on: 1437960
As rsx11m reported, I can confirm that this bug depends on (ultimately) Bug 1269172 - Behaviors transposed for {Click on Scrollbar} and {Shift+click on Scrollbar}. It appears by testing that from SM 2.49.1 onwards, clicking anywhere in the scrollbar moves the pages directly there, not one page further any more.

Confirmed also for Firefox 58.0.2 and Thunderbird 52.6.0. Posted it there. Testing in which versions there the error starts and posting it there...

Looks like a GTK3 issue.

This bug makes scrolling through long contents in Linux in FF/TB/SM in any window/iframe/form very difficult.
This bug does not depend anymore on Bug 1269172 - Behaviors transposed for {Click on Scrollbar} and {Shift+click on Scrollbar}.

Bug 1269172 - Behaviors transposed for {Click on Scrollbar} and {Shift+click on Scrollbar} is not a bug, it is a feature :-| and is now resolved as fixed.

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.

That problem has been solved.

Now for the remaining ones of this bug...
You need to log in before you can comment on or make changes to this bug.