1882716 - Cannot cancel download when downloading large files using LoongArch Firefox

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Lin Runze]

User Agent: Mozilla/5.0 (X11; AOSC OS; Linux loongarch64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

Download arbitrary large files (500MiB~) using Firefox for LoongArch, click cancel button in Download Manager.

Could confirm this issue exists on AOSC and LoongArchLinux‘s Firefox 120, however on Loongnix's Firefox 68.12.4esr, everything works fine.

Actual results:

Download Manager unresponsive, the text shows the download still continue, however the progress bar stops moving.

If waiting for a really long time, the download may be canceled, and restart the browser sometimes does work, however it's possible the download will automatically restart and can not be canceled.

Expected results:

Download stops immediately.

Comment 1

[Manuel Bucher [:manuel]]

LoongArchLinux: https://loongarchlinux.org/
LoongArch: https://docs.kernel.org/arch/loongarch/introduction.html
LoongNIx: https://zh.wikipedia.org/wiki/Loongnix
AOSC: https://aosc.io/
Firefox 68 esr is from 2019: https://whattrainisitnow.com/release/?version=68
Firefox 120 from November 2023: https://whattrainisitnow.com/release/?version=120
PKGBUILD: https://github.com/loongarchlinux/extra/commit/90fc785dbebb3b73c3d8551ed17f14478263781e#diff-99e1a0f436ad038ceef414593e9d4ca33c4e53a807fcbbcf7e04ca4dcd2866cf (looks like Firefox is coming from an official Mozilla release).

Not sure if anyone from the Necko team can reproduce due to missing hardware.

To give you some pointers in helping figuring out what is going wrong:

• Opening a Bug report in your Distro might help you get it resolved the fastest.
• You could try to narrow down the regression range with: mozregression
• Recording a http-log and sending it to us at [e-mail] could lead to something.

Can you try to do the above and report back with your finding/links to bug report at your distro?

Comment 2

[Zhao Jiazhong]

Hi Runze and Manuel,

Thanks for your information. I'm SpiderMonkey loong64 port maintainer, I reproduced this bug on some LoongArch64 Distros, and I will have a look at it.

Thanks!

Comment 3

[Lin Runze]

Not sure if anyone from the Necko team can reproduce due to missing hardware.

The QEMU have already support LoongArch system emulation since version 7.2, you can use LoongArchLinux's qcow image for testing if needed: https://mirrors.wsyu.edu.cn/loongarch/archlinux/images/

Also, I believe Zhao from Loongson is going to working on this bug, thanks for your advice! I'll provide more info as far as I know.

Comment 4

[Manuel Bucher [:manuel]]

Thanks for your information. I'm SpiderMonkey loong64 port maintainer, I reproduced this bug on some LoongArch64 Distros, and I will have a look at it.

Thanks a lot! We are accepting patches can try to help out a bit if you need help troubleshooting.

Comment 5

[Zhao Jiazhong]

Attachment: Bug 1882716 - [loongarch] Keep unsigned 32-bit parameter sign-extended in register. r=nika

On loongarch64, 32-bit value in 64-bit register should be sign-extended, even
when it's type is unsigned.

Comment 6

[BugBot [:suhaib / :marco]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c0d80d856729
[loongarch] Keep unsigned 32-bit parameter sign-extended in register. r=nika DONTBUILD

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/c0d80d856729