Bug 1808197

The following Sources of the specfile are not valid URLs so we cannot automatically build the new version for you.  Please use URLs in your Source declarations if possible.

- seamonkey-find-requires.sh
- seamonkey-mail.desktop
- seamonkey-mail.svg
- seamonkey.sh.in
- seamonkey.desktop

Dmitry,

I have installed seamonkey-2.53.1-1.fc31.x86_64.rpm straight from Koji, I can't believe how much faster it is compared to 2.49.5! Apart from GreaseMonkey not working (gmport will need an update, I guess) and crashing when using CookieKeeper (I will need to learn systemd-coredump to get backtrace), my only other issue is with the GTK3 port.

You see, I can't see the scroll bars on web pages, on my GTK3 theme on the vertical bar it's just a grey area, no button on it. If you get the horizontal one, there's a sliding rectangle because the background is different (so the horizontal one is at least functional). I checked other GTK3 themes and usually both scrollbars have some kind of a rectangle, but there's still a color difference between vertical and horizontal scrollbar, and if the rectangles have a border (which makes them visible even if the color is the same), that border's thickness depends on how much zoom you apply to the page/tab!

Can we have at least this thing reversed to the theme's scollbars, like the GTK2 patches used to do? Please :)

(Or just bring those back, GTK2 SeaMonkey was awesome and tabs looked like tabs ;))

Also, I've tried looking for where this is defined, but the only mentions of scrollbars in suite/themes/classic/ are under communicator/scrollbars.css, but that doesn't look like it's being used here (it has non-theme colors, it has button changing color on mouse hover etc., clearly this is being overridden or doesn't apply to the browser). I wish I knew where to look to tinker with it and propose a patch, but I'm clueless, this project is really overwhelming when looking at it for the first time.

(In reply to Leszek Matok from comment #2)
> GreaseMonkey not working (gmport will need an update, I guess) and crashing
> when using CookieKeeper

Probably you need to install some new versions, intended to work with SM-2.53+ (or FF56+). Please, report if this will not help, to report issues upstream.

> my only other issue is with the GTK3 port.
> 
> You see, I can't see the scroll bars on web pages, on my GTK3 theme on the
> vertical bar it's just a grey area, no button on it. If you get the
> horizontal one, there's a sliding rectangle because the background is
> different (so the horizontal one is at least functional). I checked other
> GTK3 themes and usually both scrollbars have some kind of a rectangle, but
> there's still a color difference between vertical and horizontal scrollbar,
> and if the rectangles have a border (which makes them visible even if the
> color is the same), that border's thickness depends on how much zoom you
> apply to the page/tab!

Do you mean that you don't use "standard" Classic or Modern theme, and the themes you use depend on the GTK3 theme chosen?

> Can we have at least this thing reversed to the theme's scollbars, like the
> GTK2 patches used to do? Please :)

Hmm, what patches are you talking about? (That was in 2.49.5 rpm?)

> (Or just bring those back, GTK2 SeaMonkey was awesome and tabs looked like
> tabs ;))

Sorry, GTK2 died here.

> I wish I knew where to look to
> tinker with it and propose a patch, but I'm clueless, this project is really
> overwhelming when looking at it for the first time.

First of all, what happens on a clean profile?

Could you provide here an url to problem SM theme(s) you are tested, accompanied with the correspond gtk3 themes' list? Then I and/or upstream could try to reproduce.

The new SM-2.53 release accompanies a lot of changes. That way the issues with non-standard theme usage are expected. Let's try to fix them.

From https://www.seamonkey-project.org/releases/seamonkey2.53.1/

> Full theme add-ons may need changes because of user interface and internal changes.
> If you find any problem with themes, contact the theme author. Before reporting
> a problem with the user interface please make sure to recreate it with either
> the Classic or Modern theme.

If it is the case, then:
> I wish I knew where to look to
> tinker with it and propose a patch, but I'm clueless, this project is really
> overwhelming when looking at it for the first time.

Try to consider the changes in, say, Modern theme from 2.49.5 (or even 2.49.1) to 2.53.1, and then apply such changes to your specific theme.

FEDORA-EPEL-2020-9d9cd4aeef has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9d9cd4aeef

FEDORA-2020-fbc034e6c3 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fbc034e6c3

FEDORA-2020-fea1a7fde2 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-fea1a7fde2

I have tried to compile srpm by myself (F31, rpmbuild command) but it failed with an error

configure: error: installation or configuration problem: C compiler cannot create executables.
...
DEBUG: /usr/bin/ld: cannot find -lgcc_s

Missing lib is in /usr/lib/gcc/x86_64-redhat-linux/9/libgcc_s.so (it comes from gcc package)

Where is /usr/lib64/libgcc_s.so.1 from libgcc

The same problem with stdc++

(In reply to Dmitry Butskoy from comment #3)

> Probably you need to install some new versions, intended to work with
> SM-2.53+ (or FF56+).
Yes, GreaseMonkey will surely need a new version, but the other one actually crashes the browser, an extension shouldn't be able to do that (as opposed to plugins). But forget about those, I only mentioned them as a confirmation that even for a hardcore SM user like myself, everything works with only minor annoyances, so a really, really good release, other than the scrollbar issue :)

> Do you mean that you don't use "standard" Classic or Modern theme, and the
> themes you use depend on the GTK3 theme chosen?
It's all SeaMonkey Classic theme (I even said I was looking under suite/themes/classic, but didn't make it clear, sorry). Yes, the theme tries to use "system" colors from the GTK3 theme in some way. The scrollbars are different when switching between GTK3 themes, but no matter which GTK3 theme I test: 1. there's no actual scrollbar button from the GTK3 theme, just a plain rectangle between the GTK3 theme's actual arrow buttons, 2. in dark themes the rectangle is invisible on the vertical bar and 3. All themes have a color difference between the vertical (more broken) and horizontal (less broken) scrollbar.

> Hmm, what patches are you talking about? (That was in 2.49.5 rpm?)
Yes, the ones from 2.49.5 and earlier - those used to revert scrollbars to actual GTK (2 in that case), as far as I understand. Would be sweet to just get that part back for GTK3 version. I think a big part of SeaMonkey users are "conservative" people that want their browsers to behave and look like all other applications in the system, so this wouldn't be controversial to anyone interested.

> First of all, what happens on a clean profile?
Clean profile (I just ran from another user, rm -rf .mozilla; seamonkey) is exactly the same. Start page has vertical scrollbar that's invisible on dark themes, opening something that has horizontal scrollbar (like an image) shows the horizontal scrollbar has different colors.

> Could you provide here an url to problem SM theme(s) you are tested,
> accompanied with the correspond gtk3 themes' list? Then I and/or upstream
> could try to reproduce.
My GTK3 theme is my own - https://github.com/Lamieur/Darklooks/ but you don't need to play with it - ALL dark themes give similar experience. I checked like 15 other themes that I have installed (several Mint-*, Unity, Traditional-OK-Test, DeLorean, Smoothly-Black - basically gnome-themes-extras + mate-theme-extras). Lighter skins usually have black border around the rectangle (button), so you can tell where it is, even if it's the same color as the background. For dark themes, even if they technically have a border (like Mint-Y-Dark, BlackMATE, DeLorean Dark, Adapta-Nokto-Eta from adapta-gtk-theme), it's invisible to my eyes / on my display.

And have I mentioned the issue where switching to a tab with a 240% zoomed page makes the scrollbars huge? :) (If I wanted huge UI elements, there's a DPI system setting. Zooming the page is just that - you don't get huge scrollbars when zooming in in Evince/Atril/etc. - that's baseline UX)

Thanks for your consideration.

And for free giggles:

Double-click to select: https://www.youtube.com/watch?v=dQw4w9WgXcQ

Now middle-click on a tab that you want to close.

This will in fact close that tab. BUT the active tab (or last active tab if you middle-click on the currently active tab) opens the url.

Rickrolling is always funny, until you lose a form you've been filling out for the last half hour ;)

(In reply to Paweł from comment #8)
> I have tried to compile srpm by myself (F31, rpmbuild command) but it failed
> with an error
Some local misconfiguraton. Email me directly output of your rpmbuild (both stdout and stderr together), I'll try guess the reason.

(In reply to Leszek Matok from comment #9)
> 1. there's no actual scrollbar button from the GTK3 theme, just a
> plain rectangle between the GTK3 theme's actual arrow buttons

Yep. Kinda "no bug, just a feature" :)

It seems that after trying to provide scrollbar top/bottom buttons in bug #1269145, such a rectangle has appeared.

> 2. in dark themes the rectangle is invisible on the vertical bar

Nope for me, just "hard to see" (on CentOS-7). Since there is no proper button.

> 3. All themes have a color difference between the vertical (more broken) and
> horizontal (less broken) scrollbar.

Cannot reproduce (under CentOS-7). Just different sizes on some themes, but colors are the same.

> Yes, the ones from 2.49.5 and earlier - those used to revert scrollbars to
> actual GTK (2 in that case), as far as I understand. Would be sweet to just
> get that part back for GTK3 version.

Then we lose scrollbar top/bottom buttons...

> 
> And have I mentioned the issue where switching to a tab with a 240% zoomed
> page makes the scrollbars huge? :)

What theme? If some standard (not third party), then could you provide a proper test case (on a clean profile, theme name, and detailed steps to reproduce).

> Double-click to select: https://www.youtube.com/watch?v=dQw4w9WgXcQ
>
> Now middle-click on a tab that you want to close.
>
> This will in fact close that tab. BUT the active tab (or last active tab if you
> middle-click on the currently active tab) opens the url.

Is it somehow youtube-related? Anyway, a detailed test case could be fine.

Leszek,

Could you please test the rectangle issues with new package:
https://koji.fedoraproject.org/koji/taskinfo?taskID=42121873
https://kojipkgs.fedoraproject.org//work/tasks/1873/42121873/seamonkey-2.53.1-1.fc31.1.x86_64.rpm

It looks like something was changed since 2.49.5 time, and the problem gtk3 patch no more needed.

Interested as much themes as possible. (Note, that some themes might not have scrollbar top/bottom buttons by design -- in such a case it is not an SM issue, when all the desktop applications behave the same way).

(In reply to Dmitry Butskoy from comment #13)

> Could you please test the rectangle issues with new package:

Yes, this helps tremendously, for all the themes I've tested! There are now decorations similar to those of the theme [1] (buttons, rounded sliders etc., not just a blank rectangle) and vertical and horizontal bars are now the same. I'm happy.

(I found two GTK3 themes that had a different issue when zooming, but that can be blamed on particular GTK3 theme itself since all others work as expected now.)

Thanks for your effort, you have no idea how much this helps :)

[1] Similar, not identical, but this is probably workable on the theme level (scaling/sizing of decorations and such, I will tinker with my theme to see if I can make it perfect). I'm already happy!


> Is it somehow youtube-related? Anyway, a detailed test case could be fine.

Not specific to any webpage, that was just a rickroll attempt (destroyed by Bugzilla's auto-linker, but you can double-click on the right of the link to select it as text). The point was to have any full URL selected with the mouse, then middle-clicking a tab.

In SeaMonkey 2.53.1, middle-click on the tab closes it. But it seemingly doesn't stop the middle-click signal, which still hits the next tab to become active. If you have a full URL copied in PRIMARY, middle-click on one tab closes this tab, but then... opens the URL in the next active tab (or current tab if you're closing another tab).

As you remember, some time ago middle-clicking in the page was changed so it requires full URL (with http:// or https://) to work as "paste and go" from the PRIMARY selection (clipboard). This limited misclicks with garbage in the buffer, and now drastically lowers this bug's severity.

seamonkey-2.53.1-1.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fbc034e6c3

Ha, actually that one is not just a regression, but a comeback of a... 19 year old bug! https://bugzilla.mozilla.org/show_bug.cgi?id=107147 - back then the solution was to disable middle-click tab closing with middlemouse.contentLoadURL set [1] - even though people argued it should mean close regardless (and I tend to agree).

I wasn't able to find a newer manifestation of this bug in bugzilla, so I don't know if this change (to bring back middle-click to close tab) was an upstream change but still unreported, or is this part of Fedora patches. Either way it's nice, just a small bug left in the implementation.

[1] still the default for a new profile - which I fully approve of course :)

seamonkey-2.53.1-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-fea1a7fde2

seamonkey-2.53.1-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9d9cd4aeef

(In reply to Leszek Matok from comment #14)
> In SeaMonkey 2.53.1, middle-click on the tab closes it. But it seemingly
> doesn't stop the middle-click signal, which still hits the next tab to
> become active. If you have a full URL copied in PRIMARY, middle-click on one
> tab closes this tab, but then... opens the URL in the next active tab (or
> current tab if you're closing another tab).

No any specific changes seen for such a behaviour. Looks like side effect of the changes in another parts of the code.

Currently, Firefox just set "middlemouse.contentLoadURL" to false since FF-57 (after a years long discussion in its bug 366945). For FF-56 based SM-2.53, the old prefs is still there. Probably setting the prefs to false looks like a reasonable solution.

There is some related SM bug https://bugzilla.mozilla.org/show_bug.cgi?id=1558596 , it is initially for SM-2.57, but the change is ported to 2.53 now.

You can discuss there further.

FEDORA-EPEL-2020-4fdca9429c has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4fdca9429c

seamonkey-2.53.1-2.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5e09dc8487

seamonkey-2.53.1-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4fdca9429c

seamonkey-2.53.1-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-b00f3fbb69

seamonkey-2.53.1-2.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f4d5eaa149

seamonkey-2.53.1-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

seamonkey-2.53.1-2.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.

seamonkey-2.53.1-2.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.

FEDORA-EPEL-2020-c513b3c1ca has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c513b3c1ca

FEDORA-EPEL-2020-722463ecb6 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-722463ecb6

seamonkey-2.53.1-3.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c513b3c1ca

seamonkey-2.53.1-3.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-722463ecb6

FEDORA-EPEL-2020-3041108f43 has been pushed to the Fedora EPEL 8 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3041108f43

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2020-3041108f43 has been pushed to the Fedora EPEL 8 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-EPEL-2020-c513b3c1ca has been pushed to the Fedora EPEL 7 stable repository.
If problem still persists, please make note of it in this bug report.