Pano downloads files from copied URLs and freezes the UI for a while after the download

[busybox11]

Description

What is the bug?

Problem Explanation

The bug happens when you copy the URL to a direct file download target.

Pano will download the entirety of the file, and right after doing it, it will freeze the entire UI for a while. I'm assuming this is a parsing state, but the preview in the history stays ONLY the URL, not the file preview.

Expected Behavior

A clear and concise description of what you expected to happen, and how the actual outcome differs:

• Pano (probably) shouldn't download the entire file
• Even if it does, it shouldn't freeze the entire UI, locking the system up for a (relatively) small period of time

Reprodution

How one can find the bug?

Steps To Reproduce

Steps to reproduce, if applicable:

1. Open GNOME system monitor BEFORE downloading
2. Copy a link to a file (example: http://ipv4.download.thinkbroadband.com/512MB.zip - 512MB file)
3. Observe network interface download speeds to rise as soon as you copied the link
4. GNOME should freeze as soon as the file is finished downloading, which you will notice as soon as it unfreezes, because the network speeds will be back to normal and one CPU core will be at 100% while it freezes.

Details

Mark with [ ] all that applies:

It happens with any application?

• [X] Yes, it applies to any application.
• [ ] No. Only with the following applications:
  • VSCode
• [ ] It works with the following applications that I have tried:
  • Fill in a list with any application that applies

It happens only on one computer?

• [ ] I don't know.
• [X] No. I have tried it on more than one computer.

It happens only with some specific gnome configuration?

• [ ] I don't think that the configuration matters.
• [X] Yes. Only if the following config is set up:
  • Link previews

It happens only with some specific extension installed?

• [X] I don't think that the installed extensions affect the bug/behavior.
• [ ] Yes. Only if the following gnome extension is installed:
  • Fill in a list with any extension tha applies.
  • Fill in also any detail about the extensions that applies.

Diagnostics

Under what conditions does it happen?

Should only occur when Link previews is turned on in settings.

Environment

• GNOME Shell version: 43.4
• Distro: ArchLinux
• Distro version: N/A

Screenshots

If applicable, add screenshots to help explain your problem:

Network speeds rising to 50MB/s for a ~500MB file, CPU core @100% as soon as it finishes. GNOME unfreezed and I took the capture.

Still shows up as a link in the history, no matter what file it is - tested with a valid ZIP file and test PNG file, hidden for privacy reasons.

[ttmx]

This gets stuck in src/utils/linkParser.ts, in the p.write(data) line, about line 107. It attempts to parse the file you give it as html, which is very slow for a 1GB file. This is imperfectly but trivially fixed by only p.writing the first 10000 or so characters of the file, this is always instant, and I cannot find websites that don't have their meta tags in the first 10000 characters.

Would it be possible to merge request?

[busybox11]

@ttmx I guess you could do a merge request, yeah. Maybe even a fork - this extension does not seem to be supported anymore. I'd love to use your changes, though I don't really have much time to tinker with it and debug the extension.

Maybe a better solution would be to use a separated single thread that will return the extension's preview contents once it's loaded? This won't fix the full file download issue, but it would improve the overall experience.

[LXK-98]

I just faced the same issue. I was very confused when out of nowhere my network usage spiked and then my whole OS froze. It would be nice to see this fixed, maybe by querying the type of response first and only accepting HTML, images and the like and of course having a size limit so you don't try and download a 1GB file for a preview. It would be interesting to know how for example Discord handles link previews since they don't have this issue (see below, first link is a file that gets downloaded by the extension, but Discord is smart enough not to do that and only show the preview for the second link which responds with HTTPS/has a preview image in the metadata): For now I guess I'll keep the link preview disabled which sucks because it's a cool feature!