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.
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
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?
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...
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.
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.