Hi, With firefox 45.1.1, in my Cauldron VM, when I right-click and choose "Open Containing Folder" (in the Library, for example), firefox hangs and I must kill the process. I have that bug in both Plasma and LXDE (the only two I tested, so the problem is likely to affect all DE). I also have the problem with a new firefox profile. I have not that bug with Mga5 firefox 45.1.1 when testing the pkg from updates_testing in my Mga5 VM. Best regards, Nico.
Source RPM: (none) => firefox
Maybe another Gtk+3 3.20 issue?
CC: (none) => doktor5000, thierry.vignaud
(In reply to Nicolas Salguero from comment #0) Well, we cannot rule that without testing first in gnome. (In reply to David Walser from comment #1) The thing is, our gtk+3.20 fixes came from FC. But they're now at ff 47.0 and the codebase has changed, which means we cannot apply their current gtk3.20 patch as it. Worse, bits of that work has been merged in 46.0 & 47.0, so we would have to understand which bits needs to be resurected... Sadly, I don't see any gtk3.20 work done on ff 45ESR... I wonder if we don't have to buy the bullet and update nss/nspr/firefox every 6 months...
(In reply to Thierry Vignaud from comment #2) > I wonder if we don't have to buy the bullet and update nss/nspr/firefox > every 6 months... I guess you meant every 6 weeks. The alternative would be to stick to GTK+2 for yet another release if Firefox 45 upstream is not ready for the move.
(In reply to Thierry Vignaud from comment #2) > (In reply to Nicolas Salguero from comment #0) > Well, we cannot rule that without testing first in gnome. The problem does not occur in MATE, Cinnamon and GNOME. The problem also occurs in Xfce, LXQt, IceWM and Openbox. The problem partially occurs in Enlightenment (nothing opens but firefox can be closed properly after that).
(In reply to Rémi Verschelde from comment #3) > (In reply to Thierry Vignaud from comment #2) > > I wonder if we don't have to buy the bullet and update nss/nspr/firefox > > every 6 months... > > I guess you meant every 6 weeks. The alternative would be to stick to GTK+2 > for yet another release if Firefox 45 upstream is not ready for the move. Indeed, and no switching to the milestone releases is not a viable option for Mageia 6. We'll probably just have to build it with Gtk+2, unless RHEL has switched to Gtk+3 and has the patches we need.
Assigning to all packagers collectively, because there is no maintainer for this package. @ Thierry and all Is there agreement now on building it with Gtk+2 again, or does this need further discussion?
CC: (none) => marja11Assignee: bugsquad => pkg-bugs
Well since it works fine under Gnome/mate/cinnamon, rebuilding ff wit gtk+2 is not the right solution. This will likely affect other gtk+3 apps... So gtk+3.0 and/or those other desktops must be fixed
Source RPM: firefox => gtk+3.0, firefoxCC: (none) => olav
Hi, Contrary to what I said, the problem also occurs with Mga5 (tested with ff 45.2.0). To trigger the problem, I only needed to add task-mate to my Mga5 VM (I had not the problem in my first tests because I only had LXDE). So, it seems that the bug is not with Gtk2 vs. Gtk3 but, maybe, with something like this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=266600 (Open containing folder function does nothing (KDE)). Best regards, Nico.
Blocks: (none) => 18654
(In reply to Nicolas Salguero from comment #8) > Hi, > > Contrary to what I said, the problem also occurs with Mga5 (tested with ff > 45.2.0). > > To trigger the problem, I only needed to add task-mate to my Mga5 VM (I had > not the problem in my first tests because I only had LXDE). > > So, it seems that the bug is not with Gtk2 vs. Gtk3 but, maybe, with > something like this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=266600 > (Open containing folder function does nothing (KDE)). > Adjusting this report accordingly.
Source RPM: gtk+3.0, firefox => firefoxSee Also: (none) => https://bugzilla.mozilla.org/show_bug.cgi?id=266600Whiteboard: (none) => MGA5TOO
Given that the mozilla bug has been open for ten years with no sign of improvement I don't think we should delay the security update for it, if this is the sole issue.
CC: (none) => eeeemail
As I thought, the problem really is with DBUS org.freedesktop.FileManager1 (https://www.freedesktop.org/wiki/Specifications/file-manager-interface/) which is not implemented by all file managers and which is the first method used by firefox to try to open the containing folder. So, firefox hangs until it gets a timeout from DBUS and, then, uses XDG method to open the containing folder when the system has, at least, one file manager implementing the specification and the default file manager for firefox does not implement the specification. A workaround is provided here: http://pifuge.com/ubuntu/VshF-change-file-manager-used-by-firefox-on-lubuntu: """ create ~/.local/share/dbus-1/services/org.freedesktop.FileManager1.service and set its exec-line to /usr/bin/false (just copy /usr/share/dbus-1/services/org.freedesktop.FileManager1.service there and change it). """ In fact, the "just copy /usr/share/dbus-1/services/org.freedesktop.FileManager1.service" may need to be adjust if the file does not exist but, for example, the file "/usr/share/dbus-1/services/org.mate.freedesktop.FileManager1.service" exists.
I omit to say I successfully tested the workaround with my Mga5 and Cauldron VM.
Blocks: 18654 => (none)
And thus is not related to gtk3
CC: (none) => fri
Operating System: Mageia 8 KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.76.0 Qt Version: 5.15.2 Kernel Version: 5.9.12-desktop-1.mga8 OS Type: 64-bit Processors: 4 × Intel® Core™ i5-6600K CPU @ 3.50GHz Memory: 15.6 Gio of RAM Graphics Processor: GeForce GTX 1660 Ti/PCIe/SSE2 $ urpmq -i firefox firefox-78.5.0-2.mga8.src.rpm Hamburger menu => Library => Downloads => Open Containing Folder : This opens Dolphin in Plasma, Files in Gnome, Nemo in Cinnamon. This should be closed? Remark upstream reference is stall since 5 years.
CC: (none) => ouaurelien
I think that problem does not occur anymore with current version.
Resolution: (none) => OLDStatus: NEW => RESOLVED