Why does mozilla repo have FF 115.12.0 for 15.4 and 115.11.0 for TW?
All, Devs, Wolfgang, I found a seeming contradiction in Firefox versioning between Leap 15.4 and Tumbleweed in the mozilla repository. The following versions are current: Leap 15.4 - Firefox 115.12.0esr Tumbleweed - Firefox 115.11.0esr Is this just a timing thing where TW will be updated but just hasn't been built yet, or is there a dependency issue causing problems? -- David C. Rankin, J.D.,P.E.
Am Samstag, 13. Juli 2024, 11:36:52 CEST schrieb David C. Rankin:
All, Devs, Wolfgang,
I found a seeming contradiction in Firefox versioning between Leap 15.4 and Tumbleweed in the mozilla repository. The following versions are current:
Leap 15.4 - Firefox 115.12.0esr
Tumbleweed - Firefox 115.11.0esr
Is this just a timing thing where TW will be updated but just hasn't been built yet, or is there a dependency issue causing problems?
It has failed building for Tumbleweed: https://build.opensuse.org/package/show/mozilla/firefox115esr Stephan
On 7/13/24 04:42, Stephan Hemeier via openSUSE Users wrote:
It has failed building for Tumbleweed: https://build.opensuse.org/package/show/mozilla/firefox115esr
Stephan
Thank you Stephan, That explains it --- perfectly :) -- David C. Rankin, J.D.,P.E.
Stephan Hemeier composed on 2024-07-13 11:42 (UTC+0200):
schrieb David C. Rankin:
I found a seeming contradiction in Firefox versioning between Leap 15.4 and Tumbleweed in the mozilla repository. The following versions are current:
Leap 15.4 - Firefox 115.12.0esr
Tumbleweed - Firefox 115.11.0esr
Is this just a timing thing where TW will be updated but just hasn't been built yet, or is there a dependency issue causing problems?
It has failed building for Tumbleweed: https://build.opensuse.org/package/show/mozilla/firefox115esr
Meanwhile, <https://ftp.mozilla.org/pub/firefox/releases/115.13.0esr/linux-x86_64/en-US/firefox-115.13.0esr.tar.bz2> is 5 days old. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Am Samstag, 13. Juli 2024, 12:41:29 CEST schrieb Felix Miata:
Meanwhile, <https://ftp.mozilla.org/pub/firefox/releases/115.13.0esr/linux-x86_64/en-US/firefox-115.13.0esr.tar.bz2> is 5 days old.
Its on the way: https://build.opensuse.org/package/requests/mozilla/firefox115esr
On 7/13/24 6:13 AM, Stephan Hemeier via openSUSE Users wrote:
Am Samstag, 13. Juli 2024, 12:41:29 CEST schrieb Felix Miata:
Meanwhile, <https://ftp.mozilla.org/pub/firefox/releases/115.13.0esr/linux-x86_64/en-US/firefox-115.13.0esr.tar.bz2> is 5 days old.
Its on the way: https://build.opensuse.org/package/requests/mozilla/firefox115esr
Ain't a rolling-release FUN :) -- David C. Rankin, J.D.,P.E.
On 7/13/24 6:13 AM, Stephan Hemeier via openSUSE Users wrote:
Am Samstag, 13. Juli 2024, 12:41:29 CEST schrieb Felix Miata:
Meanwhile, <https://ftp.mozilla.org/pub/firefox/releases/115.13.0esr/linux-x86_64/en-US/firefox-115.13.0esr.tar.bz2> is 5 days old.
Its on the way: https://build.opensuse.org/package/requests/mozilla/firefox115esr
Also Note: I filed: Firefox Bug - no middle-mouse scroll on focused window not raised to top https://bugzilla.mozilla.org/show_bug.cgi?id=1907708 This was filed directly with mozilla as I see the same behavior on 15.4 and TW. This failure of the FF (and TB) windows to scroll unless the window is raised to the top-level just started within the last week or so. Not sure what changed in how mozilla is handling focus placed on the window. However, with focus-follows-mouse, it is abundantly clear the FF window receives focus as the titlebar changes showing it has focus, but the FF window does not process input until raised to the top. I'm not even going to speculate as to the freedesktop cause of the issue.... :) -- David C. Rankin, J.D.,P.E.
On Sat, 13 Jul 2024 16:42:38 -0500 "David C. Rankin" <drankinatty@gmail.com> wrote:
On 7/13/24 6:13 AM, Stephan Hemeier via openSUSE Users wrote:
Am Samstag, 13. Juli 2024, 12:41:29 CEST schrieb Felix Miata:
Meanwhile, <https://ftp.mozilla.org/pub/firefox/releases/115.13.0esr/linux-x86_64/en-US/firefox-115.13.0esr.tar.bz2> is 5 days old.
Its on the way: https://build.opensuse.org/package/requests/mozilla/firefox115esr
Also Note:
I filed:
Firefox Bug - no middle-mouse scroll on focused window not raised to top https://bugzilla.mozilla.org/show_bug.cgi?id=1907708
This was filed directly with mozilla as I see the same behavior on 15.4 and TW. This failure of the FF (and TB) windows to scroll unless the window is raised to the top-level just started within the last week or so. Not sure what changed in how mozilla is handling focus placed on the window. However, with focus-follows-mouse, it is abundantly clear the FF window receives focus as the titlebar changes showing it has focus, but the FF window does not process input until raised to the top.
I'm not even going to speculate as to the freedesktop cause of the issue.... :)
I use FF ESR directly from mozilla and moddle mouse scroll continues to work fine with 115.13.0 just as it did with previous versions. So I suggest your problem is with either openSUSE's build of an old FF ESR or some other openSUSE component (libraries, X?) of your system. So mozilla is the wrong place for your bug report IMHO.
On 7/14/24 5:47 AM, Dave Howorth wrote:
I use FF ESR directly from mozilla and moddle mouse scroll continues to work fine with 115.13.0 just as it did with previous versions. So I suggest your problem is with either openSUSE's build of an old FF ESR or some other openSUSE component (libraries, X?) of your system. So mozilla is the wrong place for your bug report IMHO.
dnh, Let's make sure we are talking apples-to-apples. Are you saying middle-mouse-scroll continues to work fine when the FF/TB window is partially covered by other windows? It is this special case when using the focus-follows-mouse (sloppy focus) that I'm talking about. All other apps continue to respond fine to the middle-mouse-wheel when the windows are partially covered with other windows, it's just FF/TB that are having issues. And the fact this started and effects 15.4 (which hasn't been updated other than FF since before this started) and it occurs on TW points indicates to me this is mozilla. I'm not saying you are wrong, but how do you come to your conclusion if we are talking apples-to-apples? -- David C. Rankin, J.D.,P.E.
On Sun, 14 Jul 2024 18:01:19 -0500 "David C. Rankin" <drankinatty@gmail.com> wrote:
On 7/14/24 5:47 AM, Dave Howorth wrote:
I use FF ESR directly from mozilla and moddle mouse scroll continues to work fine with 115.13.0 just as it did with previous versions. So I suggest your problem is with either openSUSE's build of an old FF ESR or some other openSUSE component (libraries, X?) of your system. So mozilla is the wrong place for your bug report IMHO.
dnh,
who or what is dnh?
Let's make sure we are talking apples-to-apples. Are you saying middle-mouse-scroll continues to work fine when the FF/TB window is partially covered by other windows? It is this special case when using the focus-follows-mouse (sloppy focus) that I'm talking about.
Yes
All other apps continue to respond fine to the middle-mouse-wheel when the windows are partially covered with other windows, it's just FF/TB that are having issues.
And the fact this started and effects 15.4 (which hasn't been updated other than FF since before this started) and it occurs on TW points indicates to me this is mozilla.
I have no idea about your logic here.
I'm not saying you are wrong, but how do you come to your conclusion if we are talking apples-to-apples?
Because I use a mozilla product and it works fine now and previously and is up-to-date. You use an older product produced by openSUSE which has problems. QED.
On 7/14/24 5:47 AM, Dave Howorth wrote:
I use FF ESR directly from mozilla and moddle mouse scroll continues to work fine with 115.13.0 just as it did with previous versions. So I suggest your problem is with either openSUSE's build of an old FF ESR or some other openSUSE component (libraries, X?) of your system. So mozilla is the wrong place for your bug report IMHO.
dnh, One more data point for clean testing. The FF or TB window does not have to be covered. It can be the only window on a given desktop. If I have it focused I can move the mouse off, and then back over FF or TB and it will continue to scroll. However... If I click placing focus on the desktop and then move back over FF or TB, the window shows it gets focus, but middle-mouse-wheel scroll is disabled. I then have to click the FF or TB window again in order to for middle-mouse-wheel scroll to work. Also curious, when FF/TB is in this quasi-focused state, the arrow-keys cannot move or scroll anything -- BUT -- the 'tab' key can move focus between the widgets that make up the FF/TB window. Strange indeed. Can you think of any more tests/diagnostics than can help narrow this down? Old X utilities that may work? -- David C. Rankin, J.D.,P.E.
On 7/14/24 5:47 AM, Dave Howorth wrote:
I use FF ESR directly from mozilla and moddle mouse scroll continues to work fine with 115.13.0 just as it did with previous versions. So I suggest your problem is with either openSUSE's build of an old FF ESR or some other openSUSE component (libraries, X?) of your system. So mozilla is the wrong place for your bug report IMHO.
This seems to be a regression with how the openSUSE mozilla repo builds Firefox and Thunderbird (and of course our friend Gtk). This apparently has a long running history I wasn't aware of until now, see exact issue (2018 - no scroll in Firefox unless window active -> Gtk3 incompatibility with most WM's). https://bugzilla.mozilla.org/show_bug.cgi?id=1359226 Whatever was fixed, seems to have reared its head again in some type of regression. I'm about to try the workaround: export GDK_CORE_DEVICE_EVENTS=1 You don't by chance have that already set on your system do you? I'll let you know if it works, but it also apparently has side effects in Gtk apps. -- David C. Rankin, J.D.,P.E.
On 7/14/24 5:47 AM, Dave Howorth wrote:
I use FF ESR directly from mozilla and moddle mouse scroll continues to work fine with 115.13.0 just as it did with previous versions. So I suggest your problem is with either openSUSE's build of an old FF ESR or some other openSUSE component (libraries, X?) of your system. So mozilla is the wrong place for your bug report IMHO.
Damn! Your sir are correct. This is a problem on Tumbleweed with KDE3. The ugly work-around of 'export GDK_CORE_DEVICE_EVENTS=1' does provide a fix -- but as noted in: Scrolling inactive windows in KDE/KWin with mouse wheel https://bbs.archlinux.org/viewtopic.php?id=239918 there are side effects. I loaded fluxbox and the issue disappears on Tumbleweed. (no export) I booted back into KDE3 in 15.4 and it works without the export. So this is a recent tumbleweed KDE3 issue -- and since it works fine in fluxbox -- there isn't any reason it shouldn't work find in KDE3 on TW either. Oh well. I added all the info to the mozilla bug and let them know it could be closed -- though it would be nice to find exactly what the issue is. I attached the firefox window id to xev and you can see what is happening. You get the EntryEvent Notify, but focus=NO until you click in the window to raise it. Thank you for you comment, that has pointed us in the right direction. -- David C. Rankin, J.D.,P.E.
On Mon, 15 Jul 2024 02:53:45 -0500 "David C. Rankin" <drankinatty@gmail.com> wrote:
On 7/14/24 5:47 AM, Dave Howorth wrote:
I use FF ESR directly from mozilla and moddle mouse scroll continues to work fine with 115.13.0 just as it did with previous versions. So I suggest your problem is with either openSUSE's build of an old FF ESR or some other openSUSE component (libraries, X?) of your system. So mozilla is the wrong place for your bug report IMHO.
Damn!
Your sir are correct. This is a problem on Tumbleweed with KDE3. The ugly work-around of 'export GDK_CORE_DEVICE_EVENTS=1' does provide a fix -- but as noted in:
Scrolling inactive windows in KDE/KWin with mouse wheel https://bbs.archlinux.org/viewtopic.php?id=239918
there are side effects.
I loaded fluxbox and the issue disappears on Tumbleweed. (no export) I booted back into KDE3 in 15.4 and it works without the export. So this is a recent tumbleweed KDE3 issue -- and since it works fine in fluxbox -- there isn't any reason it shouldn't work find in KDE3 on TW either.
Oh well. I added all the info to the mozilla bug and let them know it could be closed -- though it would be nice to find exactly what the issue is. I attached the firefox window id to xev and you can see what is happening. You get the EntryEvent Notify, but focus=NO until you click in the window to raise it.
Thank you for you comment, that has pointed us in the right direction.
No problem, I'm glad you found a solution. FWIW, I don't use KDE (or Gnome either). But you said you had a problem on Leap 15.4 as well?
On 7/15/24 6:44 AM, Dave Howorth wrote:
But you said you had a problem on Leap 15.4 as well?
I did, but I was mistaken (infant Alzheimer's) I've booted back and forth between 15.4 and TW so many times in the past week, it appears I got the releases mixed up. KDE3 and 15.4 with TB and FF continue to accept focus-follows-mouse and mousewheel-scroll without any issue. This points to a very recent KDE3 build issue as my 15.4 and TW come from the same KDE3 repo, but I haven't updated the KDE3 on 15.4 for several months (for just this type reason) On 15.4 KDE3 has NO issues whatsoever (other than then handful of nits we have known for 15 years). So it looks like the recent builds are pulling in a library that hasn't been tweaked to avoid the Gtk GDK_CORE_DEVICE_EVENTS=1 problem. cc: kde3@lists.opensuse.org -- David C. Rankin, J.D.,P.E.
On 2024-07-13 23:42, David C. Rankin wrote:
On 7/13/24 6:13 AM, Stephan Hemeier via openSUSE Users wrote:
Also Note:
I filed:
Firefox Bug - no middle-mouse scroll on focused window not raised to top https://bugzilla.mozilla.org/show_bug.cgi?id=1907708
This was filed directly with mozilla as I see the same behavior on 15.4 and TW. This failure of the FF (and TB) windows to scroll unless the window is raised to the top-level just started within the last week or so. Not sure what changed in how mozilla is handling focus placed on the window. However, with focus-follows-mouse, it is abundantly clear the FF window receives focus as the titlebar changes showing it has focus, but the FF window does not process input until raised to the top.
I'm not even going to speculate as to the freedesktop cause of the issue.... :)
I am on 115.12.0esr, and I was curious to test. When I use the middle mouse scroll, FF window jumps to the top, it gets the focus. Using XFCE and Leap 15.5. Happens the same with a terminal, so this might be the behaviour of the desktop, not of an application. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On Sun, 14 Jul 2024 14:04:20 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2024-07-13 23:42, David C. Rankin wrote:
On 7/13/24 6:13 AM, Stephan Hemeier via openSUSE Users wrote:
Also Note:
I filed:
Firefox Bug - no middle-mouse scroll on focused window not raised to top https://bugzilla.mozilla.org/show_bug.cgi?id=1907708
This was filed directly with mozilla as I see the same behavior on 15.4 and TW. This failure of the FF (and TB) windows to scroll unless the window is raised to the top-level just started within the last week or so. Not sure what changed in how mozilla is handling focus placed on the window. However, with focus-follows-mouse, it is abundantly clear the FF window receives focus as the titlebar changes showing it has focus, but the FF window does not process input until raised to the top.
I'm not even going to speculate as to the freedesktop cause of the issue.... :)
I am on 115.12.0esr, and I was curious to test. When I use the middle mouse scroll, FF window jumps to the top, it gets the focus. Using XFCE and Leap 15.5. Happens the same with a terminal, so this might be the behaviour of the desktop, not of an application.
You're not using 'focus-follows-mouse' so your results will be different.
participants (5)
-
Carlos E. R. -
Dave Howorth -
David C. Rankin -
Felix Miata -
Stephan Hemeier