Bug 18648 - Firefox hangs when trying to click "Open Containing Folder"
Summary: Firefox hangs when trying to click "Open Containing Folder"
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: All Packagers
QA Contact:
URL:
Whiteboard: MGA5TOO
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-07 15:59 CEST by Nicolas Salguero
Modified: 2021-05-31 08:49 CEST (History)
7 users (show)

See Also:
Source RPM: firefox
CVE:
Status comment:


Attachments

Description Nicolas Salguero 2016-06-07 15:59:33 CEST
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.
Nicolas Salguero 2016-06-07 15:59:54 CEST

Source RPM: (none) => firefox

Comment 1 David Walser 2016-06-07 16:29:57 CEST
Maybe another Gtk+3 3.20 issue?

CC: (none) => doktor5000, thierry.vignaud

Comment 2 Thierry Vignaud 2016-06-07 16:37:15 CEST
(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...
Comment 3 Rémi Verschelde 2016-06-07 16:40:59 CEST
(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.
Comment 4 Nicolas Salguero 2016-06-07 17:00:08 CEST
(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).
Comment 5 David Walser 2016-06-07 22:03:19 CEST
(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.
Comment 6 Marja Van Waes 2016-06-08 14:49:43 CEST
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) => marja11
Assignee: bugsquad => pkg-bugs

Comment 7 Thierry Vignaud 2016-06-08 15:34:14 CEST
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, firefox
CC: (none) => olav

Comment 8 Nicolas Salguero 2016-06-09 10:09:18 CEST
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

Comment 9 Marja Van Waes 2016-06-09 10:43:05 CEST
(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 => firefox
See Also: (none) => https://bugzilla.mozilla.org/show_bug.cgi?id=266600
Whiteboard: (none) => MGA5TOO

Comment 10 claire robinson 2016-06-09 11:11:50 CEST
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.
claire robinson 2016-06-09 11:14:09 CEST

CC: (none) => eeeemail

Comment 11 Nicolas Salguero 2016-06-09 11:40:37 CEST
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.
Comment 12 Nicolas Salguero 2016-06-09 11:42:04 CEST
I omit to say I successfully tested the workaround with my Mga5 and Cauldron VM.
David Walser 2016-06-09 12:14:08 CEST

Blocks: 18654 => (none)

Comment 13 Thierry Vignaud 2016-06-10 15:04:13 CEST
And thus is not related to gtk3
Morgan Leijström 2016-07-12 01:04:51 CEST

CC: (none) => fri

Comment 14 Aurelien Oudelet 2020-12-14 09:35:52 CET
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

Comment 15 Nicolas Salguero 2021-05-31 08:49:29 CEST
I think that problem does not occur anymore with current version.

Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.