Launchpad has imported 84 comments from the remote bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1517101.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2019-01-01T12:12:43+00:00 wohlraj wrote: User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0 Steps to reproduce: When being prompted as to where should a file be open or downloaded, the dialog box opens but then the browser is almost frozen/very very slow. I sometimes have to wait 3 or 4 minutes before being able to click OK. Meanwhile, the browser is not usable. Using Linux Mint 19.1, the issues appeared with Firefox 64. Testing through different versions from here: https://ftp.mozilla.org/pub/firefox/releases/ The issue happens only with Firefox 64 and 65 : 63 works fine. Actual results: Browser freezes Expected results: Let me click OK or Cancel Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/0 ------------------------------------------------------------------------ On 2019-01-01T12:15:40+00:00 wohlraj wrote: Side note: the issue happens also when totally erasing the profiles and/or in safe mode Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/1 ------------------------------------------------------------------------ On 2019-01-01T16:50:25+00:00 Bugzilla-tf wrote: I can't reproduce this with Firefox64 on Ubuntu18.04LTS Can you please use our mozregression tool to test different builds to find the change in Firefox that causes this ? - https://mozilla.github.io/mozregression/ Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/2 ------------------------------------------------------------------------ On 2019-01-01T19:36:11+00:00 wohlraj wrote: Now I'm not reproducing with any nightly build. Testing against different production versions, results are not consistent, once I it worked fine with v63, another time not. I'll keep trying identifying the root cause on my side, not sure what to do with this ticket then. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/3 ------------------------------------------------------------------------ On 2019-01-02T13:07:42+00:00 Sledru wrote: Usually, this happens when a filesystem is slow or cannot be mounted. For example, a cifs/smb or nfs remote file system. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/4 ------------------------------------------------------------------------ On 2019-01-02T17:29:54+00:00 wohlraj wrote: (In reply to Sylvestre Ledru [:sylvestre] from comment #4) > Usually, this happens when a filesystem is slow or cannot be mounted. > For example, a cifs/smb or nfs remote file system. I use some SMB mounts every day, but I do have the issue even when none of them is mounted. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/5 ------------------------------------------------------------------------ On 2019-01-05T18:14:36+00:00 Github-com wrote: I can reproduce this on Ubuntu 18.04.1 LTS, using FF 64. I do not have any shares mounted. My filesystem is a fast SSD. Hitting "File - Save Page As" works quickly, as expected. But, 100% of the time, if I click on a download link, I get the download prompt with the "OK" button greyed out. All of FF becomes unresponsive and I either have to wait a few minutes, or hit the ESC key. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/6 ------------------------------------------------------------------------ On 2019-01-05T18:18:15+00:00 Sledru wrote: Do you see anything interesting if you run strace -p <pid> -f -s foo.log ? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/7 ------------------------------------------------------------------------ On 2019-01-08T21:21:20+00:00 Leonidas wrote: I get this 100% of the time. once the dialog appears everything is frozen for 20+ seconds, it varies. Everything from clicking the other radio button to choosing OK (which doesn't even get enabled on focus as it usually does) Manjaro Linux x86-64 Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/8 ------------------------------------------------------------------------ On 2019-01-09T13:06:04+00:00 Peter-magyari wrote: *** Bug 1517959 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/9 ------------------------------------------------------------------------ On 2019-01-09T22:18:55+00:00 Andrei Miculita wrote: Also having this bug. 2 more people confirmed here https://www.reddit.com/r/firefox/comments/accd32/extremely_slow_download_prompt/ Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/13 ------------------------------------------------------------------------ On 2019-01-11T00:53:11+00:00 Leonidas wrote: Going to try mozregression tomorrow. Versions <= 63 and >= 66 work as expected so I'm using v66 nightly right now. Other dialogs like "View Page Info" are slow to load as well, and it feels the same, related. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/15 ------------------------------------------------------------------------ On 2019-01-11T11:35:51+00:00 Leonidas wrote: Output of `mozregression --good 63 --bad 64` is [this paste](https://pastebin.com/raw/Y42nzh8u). Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/16 ------------------------------------------------------------------------ On 2019-01-11T11:38:41+00:00 Leonidas wrote: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cec74a3c6a5cf518f175ba9d7903e5dd66f25cc8&tochange=88315c6735dec7bbb70c5933e2b11e7343114f73 Those radio group changes are certainly suspicious >.> Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/17 ------------------------------------------------------------------------ On 2019-01-15T08:49:57+00:00 Gyula-palko wrote: *** Bug 1519526 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/18 ------------------------------------------------------------------------ On 2019-01-15T08:53:43+00:00 Bugzilla-tf wrote: Brian could you take a look if your patch could be the cause of this bug ? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/19 ------------------------------------------------------------------------ On 2019-01-15T15:21:31+00:00 Leonidas wrote: Firefox 66 isn't affected actually Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/20 ------------------------------------------------------------------------ On 2019-01-15T15:27:20+00:00 Bgrinstead wrote: (In reply to jpegxguy from comment #13) > https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=cec74a3c6a5cf518f175ba9d7903e5dd66f25cc8&tochange=88315c6735dec7bbb70c5933e2b11e7343114f73 > > Those radio group changes are certainly suspicious >.> OK, thanks for tracking this down. (In reply to jpegxguy from comment #16) > Firefox 66 isn't affected actually So something (probably Bug 1481949) landed in 64 that caused this issue, but something else landed in 66 that fixed it (I think you mentioned 65 is affected as well). Would it be possible to use mozregression with 'bad' as 65 and 'good' as 66 to narrow down what fixed it, so we can see if it's something that could be uplifted? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/21 ------------------------------------------------------------------------ On 2019-01-15T16:12:36+00:00 Leonidas wrote: At first I ran `mozregression --good 66 --bad 65` but 66 is not an actual release so it didn't work. What did was to work with the nightly build I'm running and v64. Here is the output of `mozregression --good 2019-01-11 --bad 64 --find-fix` [pastebin here](https://pastebin.com/raw/d5ux1bef) Seems like something in https://hg.mozilla.org/integration/mozilla- inbound/pushloghtml?fromchange=1bb44497f6c0601c16de02b9595402ccc661b29a&tochange=0c7a54d4cc426d989d5759f962c8c0af737d5a5b fixed it Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/22 ------------------------------------------------------------------------ On 2019-01-15T16:22:06+00:00 Bgrinstead wrote: (In reply to jpegxguy from comment #18) > At first I ran `mozregression --good 66 --bad 65` but 66 is not an actual > release so it didn't work. What did was to work with the nightly build I'm > running and v64. > > Here is the output of `mozregression --good 2019-01-11 --bad 64 --find-fix` > [pastebin here](https://pastebin.com/raw/d5ux1bef) > > Seems like something in > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1bb44497f6c0601c16de02b9595402ccc661b29a&tochange=0c7a54d4cc426d989d5759f962c8c0af737d5a5b > fixed it Oh, it actually totally makes sense that Bug 1492326 would have fixed this. This made it so looking up whether the radiogroup implements nsIDOMXULSelectControlElement doesn't need to call into JS anymore. I don't expect that would be an easy patch to uplift, though. So we may need to figure out something else, unless if Neil thinks it could be. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/23 ------------------------------------------------------------------------ On 2019-01-15T16:53:29+00:00 Bgrinstead wrote: (In reply to Brian Grinstead [:bgrins] from comment #19) > (In reply to jpegxguy from comment #18) > > Seems like something in > > https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1bb44497f6c0601c16de02b9595402ccc661b29a&tochange=0c7a54d4cc426d989d5759f962c8c0af737d5a5b > > fixed it > > Oh, it actually totally makes sense that Bug 1492326 would have fixed this. > This made it so looking up whether the radiogroup implements > nsIDOMXULSelectControlElement doesn't need to call into JS anymore. I'm not sure why this perf issue would only show up on Linux, though Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/24 ------------------------------------------------------------------------ On 2019-01-15T17:13:35+00:00 Enn wrote: At first glance, since both Bug 1492326 and the radiogroup bug have caused several regressions (including some issues which have not yet been fixed) I'd think that haven't neither patch in would be better. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/25 ------------------------------------------------------------------------ On 2019-01-15T18:18:29+00:00 Mklltech wrote: Is there a way to uplift what fixed the issue in 66 and bring it over to current release in a minor patch update? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/26 ------------------------------------------------------------------------ On 2019-01-15T18:26:54+00:00 Bgrinstead wrote: (In reply to Mkll from comment #22) > Is there a way to uplift what fixed the issue in 66 and bring it over to > current release in a minor patch update? I don't think so - it's too sweeping of a change and as Neil noted in Comment 21 there's still at least one regression that blocks it that hasn't been fixed. I think the best case would be if we can get a profile from this and come up with a temporary JS fix that could be landed in 64/65. I don't know know off hand how difficult that will be (without regressing other things like accessibility). Would it be possible to generate a profile of the bad case using the addon at https://perf-html.io/? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/27 ------------------------------------------------------------------------ On 2019-01-15T20:58:26+00:00 Leonidas wrote: Could both of the patches be held back in a minor release? It a very long wait till v66 hits stable? I will try the profile thing when I have the time though Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/28 ------------------------------------------------------------------------ On 2019-01-16T14:18:33+00:00 Overholt-u wrote: My understanding is we're not going to have another 64 dot release given the impending 65 release. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/30 ------------------------------------------------------------------------ On 2019-01-16T16:44:42+00:00 Leonidas wrote: 65 is affected as well though Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/31 ------------------------------------------------------------------------ On 2019-01-16T16:56:46+00:00 Bgrinstead wrote: (In reply to jpegxguy from comment #26) > 65 is affected as well though We have separate flags for each release, so setting `status-firefox64` to `wontfix` just means we won't uplift a fix to 64. `status-firefox65` is still set to `affected`, although I think we'll have to be creative to come up with a fix that could be uplifted, given Comment 23. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/32 ------------------------------------------------------------------------ On 2019-01-16T16:58:20+00:00 Leonidas wrote: (In reply to Brian Grinstead [:bgrins] from comment #27) > (In reply to jpegxguy from comment #26) > > > 65 is affected as well though > > We have separate flags for each release, so setting `status-firefox64` to > `wontfix` just means we won't uplift a fix to 64. `status-firefox65` is still > set to `affected`, although I think we'll have to be creative to come up with > a fix that could be uplifted, given Comment 23. Ah, I see. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/33 ------------------------------------------------------------------------ On 2019-01-16T17:08:29+00:00 Leonidas wrote: Firefox 65.0b11, profile: https://perfht.ml/2FCmiUW Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/34 ------------------------------------------------------------------------ On 2019-01-16T17:13:17+00:00 Bugzilla-tf wrote: *** Bug 1520443 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/35 ------------------------------------------------------------------------ On 2019-01-16T17:15:41+00:00 Bugzilla-tf wrote: Please note that all reports for this bug seem to be from Linux users Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/36 ------------------------------------------------------------------------ On 2019-01-16T17:49:16+00:00 Bgrinstead wrote: (In reply to jpegxguy from comment #29) > Firefox 65.0b11, profile: https://perfht.ml/2FCmiUW Thanks, that helps a lot. I see at https://perfht.ml/2RQ1ksl calls to getCustomInterfaceCallback taking ~2000ms (https://dxr.mozilla.org /mozilla-beta/source/toolkit/content/customElements.js#221), the to create the actual interface proxy takes ~33ms (https://dxr.mozilla.org /mozilla-beta/source/toolkit/content/customElements.js#236) and then calls into the proxy taking ~1100ms (https://dxr.mozilla.org/mozilla- beta/source/toolkit/content/customElements.js#246). I guess somehow the Linux download window is triggering a boatload of calls to and from JS. Need to look into this further to see what's triggering them. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/37 ------------------------------------------------------------------------ On 2019-01-18T20:44:47+00:00 Bgrinstead wrote: On an Ubuntu VM with 65, when I download a file like https://ftp.mozilla.org/pub/firefox/releases/0.10.1/Firefox%201.0PR.dmg.gz I'm not seeing any jank. Does this happen only with certain file types? I'm wondering if it's related to the number of applications in the "Open with" list, or something like that. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/38 ------------------------------------------------------------------------ On 2019-01-18T20:52:15+00:00 Bgrinstead wrote: I'm seeing some strange results in https://perfht.ml/2W2Uejq. There's a call to nsViewManager::DispatchEvent, followed by about a billion calls to std::deque::_M_reallocate_map, followed by calls to LifecycleGetCustomInterfaceCallback (the thing that got replaced with a C++ call in Bug 1492326). I wonder if we are still having the calls to std::deque::_M_reallocate_map but the C++ Qi is just a lot faster, so it isn't noticeable. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/39 ------------------------------------------------------------------------ On 2019-01-18T22:09:34+00:00 Bgrinstead wrote: I've also requested some help from QA to see if they can reproduce this on 65. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/40 ------------------------------------------------------------------------ On 2019-01-18T22:16:11+00:00 Bad-and-ugly-b wrote: (In reply to Brian Grinstead [:bgrins] from comment #33) > On an Ubuntu VM with 65, when I download a file like > https://ftp.mozilla.org/pub/firefox/releases/0.10.1/Firefox%201.0PR.dmg.gz > I'm not seeing any jank. > > Does this happen only with certain file types? I'm wondering if it's related > to the number of applications in the "Open with" list, or something like that. I tried that download, still had the same problem described here. Only this time I didn't force quit and waited instead. I got a funny message about an unresponsive script, it said "Script: chrome://global/content/customElements.js:184" By the way, how do I attach an image to my reply? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/41 ------------------------------------------------------------------------ On 2019-01-18T22:17:41+00:00 Bgrinstead wrote: (In reply to bad.and.ugly from comment #36) > By the way, how do I attach an image to my reply? Thanks, that would help. Click the "Attach File" link near the top of the page, which should take you to https://bugzilla.mozilla.org/attachment.cgi?bugid=1517101&action=enter. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/42 ------------------------------------------------------------------------ On 2019-01-18T22:19:23+00:00 Bgrinstead wrote: (In reply to bad.and.ugly from comment #36) > (In reply to Brian Grinstead [:bgrins] from comment #33) > > > On an Ubuntu VM with 65, when I download a file like > > https://ftp.mozilla.org/pub/firefox/releases/0.10.1/Firefox%201.0PR.dmg.gz > > I'm not seeing any jank. > > > > Does this happen only with certain file types? I'm wondering if it's > > related to the number of applications in the "Open with" list, or something > > like that. > > I tried that download, still had the same problem described here. Only this > time I didn't force quit and waited instead. I got a funny message about an > unresponsive script, it said "Script: > chrome://global/content/customElements.js:184" Also, how many items show up in the list of recommended applications for that file type? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/43 ------------------------------------------------------------------------ On 2019-01-18T22:38:29+00:00 Leonidas wrote: No, it happens 100% of the time, with varying delays after the click. I forgot to mention it happens with other dialogs as well, like View Page Info. Something in the way firefox handles it's own native dialogs. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/44 ------------------------------------------------------------------------ On 2019-01-21T12:50:53+00:00 Catalin-sasca wrote: I tried reproducing the issue on Firefox 64.0b3, 64.0b5, 65.0b5 and 65.0b11 under Ubuntu 18.04 (x64) and Linux Mint 19.1 (x64), but without success. I tried under normal circumstances with clean profiles and safe mode, everytime the browser behaving correctly, without any kind of freezes. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/46 ------------------------------------------------------------------------ On 2019-01-21T13:24:19+00:00 Leandro-8 wrote: I confirm this problem in Mint 19.1 (Firefox 64). I will add one information, which I don't know if it is related: If I go to Preferences -> Connection Settings and try to change the "Configure Proxy..." option, there is quite a delay in the clicking of the options. Actually there is a delay in any of the selection bullets of the Preferences. It seems to be the same issue and not related to downloads, file systems, etc, but to the selection form. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/47 ------------------------------------------------------------------------ On 2019-01-21T13:27:42+00:00 Leandro-8 wrote: Just an additional information: after changing some of the selection options which have this delay, that translates to slow functioning of the whole firefox window. Just try to go back and forth in different tabs after that. There is clearly some overhead caused by the selection box that is slowing everything down. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/48 ------------------------------------------------------------------------ On 2019-01-21T15:07:16+00:00 Leonidas wrote: Yeah it's found throughout the Firefox UI Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/49 ------------------------------------------------------------------------ On 2019-01-21T15:35:36+00:00 Catalin-sasca wrote: I still can't reproduce the problem, I tried all the steps mentioned above by leandro and still nothing, the browser behaves correctly. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/50 ------------------------------------------------------------------------ On 2019-01-21T16:44:19+00:00 Leandro-8 wrote: I have this problem in a Samsung S51 Pro notebook (which has a Nvidia GeForce card and a SSD drive). I have Mint 19.1 installed in a much slower machine (a small Nuc box), and I don't see the problem there. I do not if this is of any help. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/51 ------------------------------------------------------------------------ On 2019-01-21T19:47:31+00:00 Leonidas wrote: (In reply to Catalin Sasca, QA [:csasca] from comment #44) > I still can't reproduce the problem, I tried all the steps mentioned above by leandro and still nothing, the browser behaves correctly. Seeing as it is a performance problem, maybe your specific machine doesn't mind the load Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/52 ------------------------------------------------------------------------ On 2019-01-22T15:54:35+00:00 Bgrinstead wrote: (In reply to jpegxguy from comment #46) > (In reply to Catalin Sasca, QA [:csasca] from comment #44) > > > I still can't reproduce the problem, I tried all the steps mentioned above > > by leandro and still nothing, the browser behaves correctly. > > Seeing as it is a performance problem, maybe your specific machine doesn't > mind the load Is there anything that stands out with your system or hard drive that might help for reproducing? See in particular https://bugzilla.mozilla.org/show_bug.cgi?id=1517101#c4 and https://bugzilla.mozilla.org/show_bug.cgi?id=1517101#c7 Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/54 ------------------------------------------------------------------------ On 2019-01-22T17:17:44+00:00 Leonidas wrote: So, I booted from USB with the latest Manjaro Xfce preview image. Both 64.0.2 and 65.0b11: No issues. I guess we know that my hardware isn't the problem. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/55 ------------------------------------------------------------------------ On 2019-01-22T17:32:18+00:00 Leonidas wrote: Interesting. Running firefox with firejail solves this as well. (or at least it's faster, but visually I can't say it's slower than normal). Seems like firefox is looking for something that firejail prevents it from seeing? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/56 ------------------------------------------------------------------------ On 2019-01-22T17:34:17+00:00 Leonidas wrote: If it's smething filesystem related, this is what firefox sees in a firejail: https://firejail.wordpress.com/documentation-2/firefox- guide/#security Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/57 ------------------------------------------------------------------------ On 2019-01-22T17:43:58+00:00 Bgrinstead wrote: (In reply to Sylvestre Ledru [:sylvestre] from comment #7) > Do you see anything interesting if you run > strace -p <pid> -f -s foo.log ? jpegxguy, could you try running this during the hang and post your log? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/58 ------------------------------------------------------------------------ On 2019-01-22T18:03:19+00:00 Leandro-8 wrote: Created attachment 9038278 strace -p ... -f >& foo.log I think I get these messages [pid 28336] madvise(0x7f2e0ab02000, 32768, MADV_DONTNEED) = 0 in the instant the problem is manifested. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/59 ------------------------------------------------------------------------ On 2019-01-22T19:55:19+00:00 Dolske wrote: Moving this to fix-optional, as 65 ships in 1 week and this (existing) regression isn't going to be fixed by then. Without a reproducible test case (or more than a couple of people able to reproduce), this also seems unlikely to be fixed in a 65.0.x dot release in the next few weeks (before 66 is on its way, which apparently fixes the issue entirely). But we'll see what happens. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/60 ------------------------------------------------------------------------ On 2019-01-22T22:27:41+00:00 Leonidas wrote: Created attachment 9038368 strace -p <PID> -f -o firefox.log I also get the `madvise` syscalls, precisely when the button press happens, whether that is clicking the `RSS` button in `View Page Info` or selecting to download instead of opening file Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/61 ------------------------------------------------------------------------ On 2019-01-23T16:12:32+00:00 Jgoulet1994-e wrote: I am having the same problem on two different machines that are running Linux Mint 19 Cinnamon. I have included the system information for one device. Would the hardware information of both assist in reproducing this issue? System: Host: MYHOST Kernel: 4.15.0-43-generic x86_64 bits: 64 gcc: 7.3.0 Desktop: Cinnamon 3.8.9 (Gtk 3.22.30-1ubuntu1) dm: lightdm Distro: Linux Mint 19 Tara Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/62 ------------------------------------------------------------------------ On 2019-01-23T18:57:33+00:00 Leonidas wrote: I have found a workaround. The single `firejail` option that mitigates this behavior is `nodbus`. Any idea why disabling D-Bus access fixes this problem? This means that if you are affected by the problem you can run firefox like so: `firejail --noprofile --nodbus firefox` You can also edit the `firefox.desktop` file in `/usr/share/applications`. Of course, one can use firejail with its default firefox profile as it adds a nice layer of protection. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/63 ------------------------------------------------------------------------ On 2019-01-23T20:30:56+00:00 Jgoulet1994-e wrote: jpegxguy, I cannot find information on launching firefox without d-bus access. It seems this option is unique to firejail and there is not a similar one in firefox. I don't believe editing the firefox.desktop file is a valid alternative. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/64 ------------------------------------------------------------------------ On 2019-01-23T20:39:02+00:00 Leonidas wrote: (In reply to jgoulet1994 from comment #57) > jpegxguy, I cannot find information on launching firefox without d-bus access. It seems this option is unique to firejail and there is not a similar one in firefox. I don't believe editing the firefox.desktop file is a valid alternative. I can see why there isn't a firefox option for that. And yes, this is a workaround, and it has consequences. It's not a solution. I just wanted to share what I did so that I can still use Firefox instead of Nightly on a daily basis Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/65 ------------------------------------------------------------------------ On 2019-01-23T22:53:27+00:00 Leandro-8 wrote: (In reply to jpegxguy from comment #56) > I have found a workaround. The single `firejail` option that mitigates this > behavior is `nodbus`. Any idea why disabling D-Bus access fixes this problem? > > This means that if you are affected by the problem you can run firefox like > so: > `firejail --noprofile --nodbus firefox` > You can also edit the `firefox.desktop` file in `/usr/share/applications`. Of > course, one can use firejail with its default firefox profile as it adds a > nice layer of protection. I do not understand this suggestion. firejail was not installed in my computer, and after installing, I get: % firejail --noprofile --nodbus firefox Error: invalid --nodbus command line option Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/66 ------------------------------------------------------------------------ On 2019-01-24T13:50:38+00:00 Leonidas wrote: Maybe the firejail your sitribution has in the repositories comes without the nodbus option. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/67 ------------------------------------------------------------------------ On 2019-01-28T17:46:54+00:00 Bugzilla-tf wrote: *** Bug 1523320 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/68 ------------------------------------------------------------------------ On 2019-01-29T15:49:07+00:00 Jgoulet1994-e wrote: Is there any update on the status of this bug? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/69 ------------------------------------------------------------------------ On 2019-01-29T21:59:36+00:00 Leonidas wrote: At least Firefox Developer Edition is at v66, I use that now. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/70 ------------------------------------------------------------------------ On 2019-01-29T22:05:46+00:00 Bgrinstead wrote: (In reply to jpegxguy from comment #63) > At least Firefox Developer Edition is at v66, I use that now. Yeah - I'm sorry this is happening and appreciate all the extra information folks have given here, but until we can get a reproducible test case there's not a lot that can be done for 65. In the meantime, I'd suggest either using Beta / Developer Edition or using the workaround in Comment 56 if that works locally. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/71 ------------------------------------------------------------------------ On 2019-01-29T22:16:26+00:00 Leonidas wrote: To tell you truth, I'll use Firefox Dev as my main, I like new features, and it's in my repos :) Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/72 ------------------------------------------------------------------------ On 2019-01-30T16:25:20+00:00 Gijskruitbosch+bugs wrote: (In reply to Brian Grinstead [:bgrins] from comment #34) > I'm seeing some strange results in https://perfht.ml/2W2Uejq. There's a call to nsViewManager::DispatchEvent, followed by about a billion calls to std::deque::_M_reallocate_map, followed by calls to LifecycleGetCustomInterfaceCallback (the thing that got replaced with a C++ call in Bug 1492326). I wonder if we are still having the calls to std::deque::_M_reallocate_map but the C++ Qi is just a lot faster, so it isn't noticeable. Neil, does this profile help figure out what's going on here? Are we confident there's nothing left to fix after bug 1492326? Jan, any idea what the connection with dbus is here? Going to mark P3 while we're still no closer to reliable STR for now. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/73 ------------------------------------------------------------------------ On 2019-01-30T22:46:12+00:00 Akred-x wrote: Hello, As a user, do you know how we can help for the investigation ? Thanks Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/74 ------------------------------------------------------------------------ On 2019-01-31T13:50:22+00:00 Gijskruitbosch+bugs wrote: (In reply to akred from comment #67) > Hello, > > As a user, do you know how we can help for the investigation ? > > Thanks It's still not clear why this is reproducing for some people and not others. It doesn't make a lot of sense to me that this is particularly bad for some users and doesn't happen at all for others; the effects described (hangs for minutes / lots of seconds) are too severe to be explained by purely performance differences between machines. So there must be some other difference; I just don't know what that is. It's also as-yet unclear what the connection is between the dbus disabling and the bugs that regressed and fixed this issue. That is, the regressing/fixing bugs change the <radio> elements in the dialog that pops up asking about saving/opening files. The dbus code is presumably only used for checking what the default handler app is on your OS (in the context of that dialog, that is; we obviously might use dbus for other stuff in other places). On builds where the issue is fixed (66 beta and 67 nightly), are there a lot of entries in the "open with" dropdown under the "open" option for files where this happens on broken builds, or something? Do all those entries show up when you download something with mimetype application /octet-stream as well, and in that case, are those downloads showing the same problem on affected/broken builds? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/75 ------------------------------------------------------------------------ On 2019-02-01T16:57:18+00:00 Bugzilla-tf wrote: *** Bug 1524540 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/76 ------------------------------------------------------------------------ On 2019-02-02T05:37:24+00:00 Gingerbread-man-2 wrote: *** Bug 1524582 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/77 ------------------------------------------------------------------------ On 2019-02-02T07:41:21+00:00 Sledru wrote: Putting it back on the release managers radar because of the number of dups Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/78 ------------------------------------------------------------------------ On 2019-02-02T13:03:52+00:00 Release-mgmt-account-bot wrote: Changing the priority to p1 as the bug is tracked by a release manager for the current release. See [How Do You Triage](https://mozilla.github.io/bug-handling/triage-bugzilla#how-do-you-triage) for more information Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/79 ------------------------------------------------------------------------ On 2019-02-02T22:45:06+00:00 Akred-x wrote: Hello, I have tested with the latest Firefox 65 (64bits) right now with many type of files (mp3 / mp3/ txt, etc...) and all of them present the same issue. For example for a PDF, on "open with entry", I have only 2 entries : "PDF viewer" (the default one of Linux Mint) and "other" option. (If it can help, in this case if I select other, I have 6 entries, which are winebrowser / Document View / 2 entries of Image Magick / Master PDF editor) But if you say that the issue is fixed on Firefox 66, it's a good news no ? (In reply to :Gijs (he/him) from comment #68) > (In reply to akred from comment #67) > > > Hello, > > > > As a user, do you know how we can help for the investigation ? > > > > Thanks > > It's still not clear why this is reproducing for some people and not others. > It doesn't make a lot of sense to me that this is particularly bad for some > users and doesn't happen at all for others; the effects described (hangs for > minutes / lots of seconds) are too severe to be explained by purely > performance differences between machines. So there must be some other > difference; I just don't know what that is. > > It's also as-yet unclear what the connection is between the dbus disabling > and the bugs that regressed and fixed this issue. That is, the > regressing/fixing bugs change the <radio> elements in the dialog that pops up > asking about saving/opening files. The dbus code is presumably only used for > checking what the default handler app is on your OS (in the context of that > dialog, that is; we obviously might use dbus for other stuff in other places). > > On builds where the issue is fixed (66 beta and 67 nightly), are there a lot > of entries in the "open with" dropdown under the "open" option for files > where this happens on broken builds, or something? Do all those entries show > up when you download something with mimetype application/octet-stream as > well, and in that case, are those downloads showing the same problem on > affected/broken builds? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/80 ------------------------------------------------------------------------ On 2019-02-02T22:47:00+00:00 Bgrinstead wrote: (In reply to akred from comment #73) > I have tested with the latest Firefox 65 (64bits) right now with many type of > files (mp3 / mp3/ txt, etc...) and all of them present the same issue. > For example for a PDF, on "open with entry", I have only 2 entries : "PDF > viewer" (the default one of Linux Mint) and "other" option. > (If it can help, in this case if I select other, I have 6 entries, which are > winebrowser / Document View / 2 entries of Image Magick / Master PDF editor) > > But if you say that the issue is fixed on Firefox 66, it's a good news no ? Could you please test locally with Beta (66) and confirm that the issue is fixed for you? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/81 ------------------------------------------------------------------------ On 2019-02-03T16:11:31+00:00 Akred-x wrote: Hello Brian, I have just tested with firefox 66 beta4, and the issue is fixed !!! We just have to wait for the stable release ;) Thank you ! (In reply to Brian Grinstead [:bgrins] from comment #74) > (In reply to akred from comment #73) > > I have tested with the latest Firefox 65 (64bits) right now with many type > > of files (mp3 / mp3/ txt, etc...) and all of them present the same issue. > > For example for a PDF, on "open with entry", I have only 2 entries : "PDF > > viewer" (the default one of Linux Mint) and "other" option. > > (If it can help, in this case if I select other, I have 6 entries, which > > are winebrowser / Document View / 2 entries of Image Magick / Master PDF > > editor) > > > > But if you say that the issue is fixed on Firefox 66, it's a good news no ? > > Could you please test locally with Beta (66) and confirm that the issue is > fixed for you? Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/82 ------------------------------------------------------------------------ On 2019-02-03T16:37:36+00:00 Bugzilla-tf wrote: Someone affected could use mozregression with the --find-fix flag to find the patch that fixed the bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/83 ------------------------------------------------------------------------ On 2019-02-03T16:53:40+00:00 Gijskruitbosch+bugs wrote: (In reply to Matthias Versen [:Matti] from comment #76) > Someone affected could use mozregression with the --find-fix flag to find the patch that fixed the bug. This already happened, see earlier comments and dep/blocking bugs. The point is nobody really understands *why* this dialog is affected in this way, ie what is slow here and why is it less slow now and is there something else that we should take away from this. That's what all the outstanding needinfo's are about... Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/84 ------------------------------------------------------------------------ On 2019-02-03T17:06:38+00:00 Bugzilla-tf wrote: *** Bug 1524859 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/85 ------------------------------------------------------------------------ On 2019-02-13T16:34:19+00:00 Jaws wrote: The patches within bug 1492326 are too large to get uplifted to 65 and it is unclear what within that patchset fixed this. At this point in 65 we're unlikely to fix this bug, and since this bug is not present in 66 there is no remaining action to be taken for this bug. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/86 ------------------------------------------------------------------------ On 2019-02-17T18:12:55+00:00 Bugzilla-tf wrote: *** Bug 1528584 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/87 ------------------------------------------------------------------------ On 2019-02-24T16:30:00+00:00 B-emilio wrote: *** Bug 1514692 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/88 ------------------------------------------------------------------------ On 2019-02-25T15:59:20+00:00 Ryanvm wrote: I'm adding this as a known issue to the Fx65 relnotes. We should probably add a note for 66 as well that it's fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/89 ------------------------------------------------------------------------ On 2019-02-25T19:10:23+00:00 Lhenry wrote: Noted in 66 beta, and i'll be sure to bring that into release as well. Reply at: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1811105/comments/90 ** Changed in: firefox Status: Unknown => Fix Released ** Changed in: firefox Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1811105 Title: Browser hangs when 'open with' dialog opens. To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1811105/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
