"Open Containing Folder" locks up Firefox

RESOLVED WORKSFORME

Status

()

defect
P5
normal
RESOLVED WORKSFORME
10 months ago
3 months ago

People

(Reporter: kolubat, Unassigned)

Tracking

60 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 months ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180613020227

Steps to reproduce:

Download a file, click downloads icon, click button to open containing folder (or right click and choose the menu item)


Actual results:

Firefox locks up (can't interact with it, and in some window managers it's necessary to switch to a separate tty to use the system again at all)

This is not a new issue (has existed for at least months). Using Firefox 60.0.1 right now.


Expected results:

The enclosing folder for the download should open.

Running "xdg-open /home/kyan" manually works fine.

Comment 1

10 months ago
Hi Kolubat,

I tested this on Ubuntu 16.04 64 bits with Firefox 60.0.2, but could not manage to reproduce it.
Firefox is responsive while opening the download folder or the file itself.
Screen capture- https://testing-1.tinytake.com/sf/MjcwMjYxN184MTA2MDY4

If this is a regression range, could you please provide the regression range? Information is available here- https://mozilla.github.io/mozregression/

thanks

Test env't:
----------
Version 	60.0.2
Build ID 	20180605171542
Update Channel 	release
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Component: Untriaged → Downloads Panel
Flags: needinfo?(kolubat)

Updated

10 months ago
Priority: -- → P5
(Reporter)

Comment 2

10 months ago
I'm working on getting mozregression going. (The prebuilt GUI version failed with "./mozregression-gui: /usr/lib64/libcrypto.so.1.0.0: no version information available (required by /home/kyan/mozregression-gui.tar/mozregression-gui/dist/libpython2.7.so.1.0)", and a corresponding error for /usr/lib64/libssl.so.1.0.0.)

If I remember correctly, this issue was happening in Firefox 52 ESR, so it's probably pretty rare.

Unrelated to this issue but 'search for text when you start typing' just got turned on automatically again. It's been doing that every few months for several years, hard to track down since it happens so rarely, but very annoying when it does...

Once I have the results from mozregression, I will post back here.

Would a videorecording of the issue be helpful?
(Reporter)

Comment 3

10 months ago
Huh. It didn't crash, just now, while running mozregression, nor when I tried it again in the browser.

I did a big system update recently, which I suspect fixed or removed something that had been interacting badly with Firefox. Sorry, this means I can't test now.

While I'm happy it's fixed itself, I'd still kind of like to understand why the X session froze until Firefox was killed, since that's something that shouldn't have been happening...

It looks like this is the relevant code: https://dxr.mozilla.org/comm-central/source/mozilla/xpcom/io/nsLocalFileUnix.cpp#1952 (called at https://dxr.mozilla.org/comm-central/source/mozilla/browser/components/downloads/DownloadsCommon.jsm#464).

It looks like with the GTK toolkit, the way Firefox implements showing a file relies on a lot of other bits and pieces, some of which are outside of Firefox itself.

I wonder if I had a bad build of some external library, and just never noticed it because Firefox is the only GTK app I use for anything serious, and it got fixed by the update. Hmm.

Is it possible for a broken external library to cause a problem like this?

Sorry again for the trouble. I guess I can't provide a good mozregression or video, unless/until I can get it broken again...
Flags: needinfo?(kolubat)
(Reporter)

Comment 4

10 months ago
Er, it's not *that* rare, apparently, a few other people have mentioned it elsewhere:

https://forums.linuxmint.com/viewtopic.php?t=213784 
https://github.com/mate-desktop/caja/issues/777
https://ubuntu-mate.community/t/firefox-freezes-after-trying-to-open-downloads/12630?_escaped_fragment_

That last one says they fixed it by something something DBus something something.

Anyway, a DBus problem probably shouldn't lock up Firefox, I wouldn't think...

Sorry for all the messages, just Web searched on a whim after sending the last message and thought these reports of this I found might be worth sharing here.
(Reporter)

Comment 5

3 months ago

This isn't broken for me any more with 62.0.3. I'm not sure what changed. Maybe an update fixed it. Anyway, might as well close the bug now. Thanks, sorry for the noise!

(Reporter)

Updated

3 months ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.