Cannot cancel opening/loading a huge log/text file
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: akwky, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0
Steps to reproduce:
Every time I click on a link leading to a big (120MB) log file, I am unable to cancel the operation or navigate away for ~40 seconds. It probably finishes loading before it unfreezes. My connection to the file location is ~2MB/s. Other windows and tabs are unaffected and work fine during that period.
Steps:
- Prepare a big text file (e.g. jenkins build log file)
- Store it on a server accessed via "slowish" network
- Accidentally click on a link to that big file
- The tab gets frozen until it fully loads. Clicking "Stop loading", navigate Back etc. does not work.
Note that an "evil" server could seize my browser tab forever.
Actual results:
The tab keeps opening and downloading the file regardless of user input.
- The "Stop loading this page (Esc)" button does not work.
- Navigation does not work
- Address bar does not work
- 1 CPU core is fully used during the load (I have i5-6500)
- Memory usage slightly rises during load (by less than 1GB / 32GB total)
The rest of the browser is unaffected and keeps working as expected (which is good).
- The offending tab can be closed
- Other tabs work
- Other windows work as well
Expected results:
The Esc key, "Stop loading" or navigation buttons should stop loading the page and allow me to navigate elsewhere.
(In the end, I just want to go back and click the correct link.)
Hi Kaja,
Thanks for your contribution!
I wasn't able to reproduce this issue, I've tested with files larger than 120MB and didn't have this problem. I can always cancel and retry downloads without any problem.
If you can please share the file or give more specific details about what you are trying to perform.
Regards,
Hi Seba,
The issue occurs when the file is being opened+rendered inside the browser as it loads. In other words, the server must not offer it for saving to disk, but open and display it as a page.
I was not talking about file downloads (the blue download arrow), if that's what you were testing.
Is it reproducible now?
Thanks,
Kaja
(PS: My apologies for delayed response. I've somehow missed the email alert for this.)
Hi Kaja!
Sorry for the delay! You were right, I misunderstood the bug and have tested it focusing on the file download section (Blue arrow). I was thinking that maybe this was occurring due to some specific pc set up but after seeing that you are using an i5-6500, I assume we can discard this is not a performance-related issue.
In this second run, I've tried using https://norvig.com/big.txt on Version 72.0 and in Nightly but I haven't had any freezes or delays when loading the file. Could you share the exact same file that you are using to reproduce it?
Thank you Kaja!
Regards,
Hi Seba, thanks for not giving up on this.
I've duplicated your file 1000 times to get the issue reproducible also on reasonably fast (100MBit) internet. I can see the issue following these steps:
- Open this page http://adelka.paveldolezal.com/kaja/big.html
- Click on the biggest (6GB) file.
- Observe "Transferring data from <site> ..." message in your lower left corner of Firefox.
- Try clicking the navigation buttons ("back", "Stop loading this page", "Esc").
- Observe that the navigation buttons do nothing until the full file is loaded.
Note: The 6GB is large enough to also cause slow text rendering, memory consumption etc. It is NOT related to this bug. If you have slower link available, you'll see it reproducible even with smaller files (as available in the link above).
Thanks
Kaja
Hi Kaja,
Sorry for the delay, I could reproduce this issue but I had to open the same biggest file twice, in fact, I've opened every file once and the biggest one twice, leave it as inactive a few moments and then I could see the issue. The thing is that after a while, some of the tabs will recover. I will add some screenshots about the process, I want you to check them and tell if that is the exact same behavior that you are seeing on your end.
Regards,
This is the other message that I'm receiving after a while that leaving the tab inactive.
Comment 8•5 years ago
|
||
Moving to Layout. Do we have a bug we can dupe this to?
Comment 9•5 years ago
|
||
why moving it to layout? Do we have a profile? I'd expect interruptible reflow to allow closing the file even if time is spent on reflow.
Comment 10•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #9)
why moving it to layout?
Layout was just a guess. I'll move this bug to Core::General until we have more information.
Do we have a profile? I'd expect interruptible reflow to allow closing the file even if time is spent on reflow.
Kaja, can you please record a performance profile while reproducing the problem?
It's quite straightforward. You just need to install and run the Firefox Profiler extension following the instructions here:
Reporter | ||
Comment 11•5 years ago
|
||
Hi all,
Thanks again for your attention.
The screenshots do not correspond exactly to what I'm seeing. Mainly, NO popup regarding script performance shows up.
I've tried to capture the profile here https://perfht.ml/39Vfz4e and here https://perfht.ml/37OBVTC
The first capture is me clicking a link to the huge file. Contrary to your screenshots, the page text usually renders fine while loading. During the "freeze" I was repeatedly trying to navigate back or cancel the loading. After it eventually loaded, a mouse dropdown showed automatically.
The second capture was me navigating back to previous page and then forward to the same file. Interestingly, the page did not render the text until fully loaded (another ~40s) and the capture shows more DOM than Layout work.
What is most curious is that I've measured 47 seconds of real time while the profiling run, but the profiler results show only 17s.
Note: Btw, I think, to more accurately reproduce this issue, use a slow network connection, to avoid having the computer process huge files (which may stress memory, cpu etc. and hide the real issue).
I hope this helps a bit. Let me know what else I can do.
Thanks
Kaja
Comment 12•5 years ago
|
||
(In reply to Kaja from comment #11)
I've tried to capture the profile here https://perfht.ml/39Vfz4e and here https://perfht.ml/37OBVTC
Oddly those aren't loading for me. Maybe it's a problem with profiler.firefox.com (the error seems to indicate maybe)?
The first capture is me clicking a link to the huge file. Contrary to your screenshots, the page text usually renders fine while loading. During the "freeze" I was repeatedly trying to navigate back or cancel the loading. After it eventually loaded, a mouse dropdown showed automatically.
The second capture was me navigating back to previous page and then forward to the same file. Interestingly, the page did not render the text until fully loaded (another ~40s) and the capture shows more DOM than Layout work.What is most curious is that I've measured 47 seconds of real time while the profiling run, but the profiler results show only 17s.
I'm willing to bet Greg knows the answer to these questions :)
Comment 13•5 years ago
|
||
Oddly those aren't loading for me. Maybe it's a problem with profiler.firefox.com (the error seems to indicate maybe)?
They are loading fine for me. Is there an error in your console? We recently migrated profile storage infrastructure.
What is most curious is that I've measured 47 seconds of real time while the profiling run, but the profiler results show only 17s.
The profiler uses a circular buffer, and older entries roll off, so only the last 17 seconds was actually stored in memory, even though the profile was recorded for 47 seconds. You can increase the buffer size if your machine can handle the extra memory load. If you are still having issues you can make the profiler sample less by increasing the sampling interval.
Comment 14•5 years ago
|
||
The priority flag is not set for this bug.
:wleung, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 15•5 years ago
|
||
Odd taht the profiles didn't load for me before but work now. Oh well :)
A first glance looks like lots of reflow and structured clone stuff so I'll move this to Layout and needinfo sfink to take a look at https://perfht.ml/37OBVTC.
Comment 16•3 years ago
|
||
(Sorry, this bug kind of died on my plate.)
The structured cloning is indeed taking a lot of time here. From my naive view, it looks like it's sending lots of data to a webextension. It would be worth retrying this with addons disabled to see if it still happens.
But the crux of the issue in the profile still appears to be that reflows are not getting interrupted.
Comment 17•3 years ago
|
||
They seem to get interrupted to some extent, in the profile I see periods of ~10 seconds of jank, not a single massive jank period... Opening http://adelka.paveldolezal.com/kaja/1000big.txt is excruciatingly slow, but I can close it and it doesn't keep doing layout in the background...
Updated•2 years ago
|
Description
•