Closed Bug 1513725 Opened 2 years ago Closed 2 years ago

nsITransfer objects wrongly get initialized as private on aarch64 Windows on Snapdragon and therefore cause mysteriously missing downloads

Categories

(Core :: XPConnect, defect)

ARM64
Windows 10
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla66
Tracking Status
firefox66 --- verified

People

(Reporter: asa, Assigned: Gijs)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

I'm testing the Windows on Snapdragon native builds (aarch64 windows) and downloads get the indicator in the taskbar icon but no downloads button in the toolbar. Tested a treeherder optimized build from this morning.
OS: Unspecified → Windows 10
Hardware: Unspecified → ARM64
Version: unspecified → Trunk
Even if you force the button to show up through the customize screen, the button doesn't light up during downloads, and the list of downloaded files stays empty.
Blocks: arm64-windows-bugs
No longer blocks: aarch64-windows

Do you see any errors reported in the Browser Console when starting a download?

From the description I assume the download completes correctly, just that the icon in the toolbar doesn't show up. Is that right? Does it show up in the Downloads Library window? (Tools -> Download)

Flags: needinfo?(asa)

No errors in the browser console. Correct that the download completes but I never see the button appear in the toolbar. I don't see the download appear in the Downloads Library either.

Flags: needinfo?(asa)

I'm supposed to get one of these devices later this week so I'll try and debug when I do if nobody beats me to it.

Flags: needinfo?(gijskruitbosch+bugs)

Bug 1520378 suggests this is specific to executable files and doesn't happen e.g. for right-clicking images and then 'save image as...' - Asa / Mike, is that your experience as well ?

Flags: needinfo?(mh+mozilla)
Flags: needinfo?(asa)
See Also: → 1520378

(Wonder if this is related to safebrowsing or OS-based virus scanner checks or something like that...)

(In reply to :Gijs (he/him) from comment #6)

(Wonder if this is related to safebrowsing or OS-based virus scanner checks or something like that...)(In reply to :Gijs (he/him) from comment #5)

Bug 1520378 suggests this is specific to executable files and doesn't happen e.g. for right-clicking images and then 'save image as...' - Asa / Mike, is that your experience as well ?

Good catch! I just tried downloading some large image files and the button and panel do show up.

Flags: needinfo?(asa)
Flags: needinfo?(mh+mozilla)
Summary: downloads button and panel don't show on aarch64 Windows on Snapdragon → downloads button and panel don't show for executable files (and maybe others?) on aarch64 Windows on Snapdragon
See Also: 1520378
Duplicate of this bug: 1520378

I've clearly downloaded non-executables in the past, but they were archives, like zip files, and had the problem with those.

(In reply to Mike Hommey [:glandium] from comment #9)

I've clearly downloaded non-executables in the past, but they were archives, like zip files, and had the problem with those.

zip files from treeherder definitely do not make the downloads button appear.

(In reply to Nathan Froyd [:froydnj] from comment #10)

(In reply to Mike Hommey [:glandium] from comment #9)

I've clearly downloaded non-executables in the past, but they were archives, like zip files, and had the problem with those.

zip files from treeherder definitely do not make the downloads button appear.

To be clear, I'm not saying the issue is restricted to executables, just that this doesn't affect all downloads. Presumably there is some commonality between the filetypes that are broken (that isn't shared by images or other stuff that isn't broken) but without a machine to reproduce on I don't know how to track this down further, given there are no errors in the browser console...

(Apparently my new machine arrived at a depot less than 30 miles away in the wee hours of this morning but, if the fedex tracker page is to be believed, they don't know when they'll be delivering it, which leads me to believe it might be next week...)

Summary: downloads button and panel don't show for executable files (and maybe others?) on aarch64 Windows on Snapdragon → downloads button and panel don't show for some file types (executables, zip files, probably others) on aarch64 Windows on Snapdragon

OK, so debugging this on the JS side, the nsITransfer::Init() here is getting called with aIsPrivate set to true. That really shouldn't be happening, because the download is in a non-private window.

The good news is that for the moment you have a workaround to see / cancel / show the download: open a private window and opening the 'view all downloads' window in there (ctrl-j).

The bad news is that my current main suspect for what is going wrong there is something like https://bugzilla.mozilla.org/show_bug.cgi?id=821628 (the caller should be C++, I think). And I don't yet have a build set up on my new aarch64 machine to be able to check that. :froydnj, do you?

Flags: needinfo?(nfroyd)
See Also: → 821628
Summary: downloads button and panel don't show for some file types (executables, zip files, probably others) on aarch64 Windows on Snapdragon → nsITransfer objects wrongly get initialized as private on aarch64 Windows on Snapdragon and therefore cause mysteriously missing downloads

Chatted with Marco, this looks similar enough to bug 821628 that it seems worth just trying out the same fix to see if that is sufficient here:

13:07:35 <@Gijs> https://treeherder.mozilla.org/#/jobs?repo=try&revision=583a53141c7edb2da2ff0194c4c86302da9a678f and https://hg.mozilla.org/try/rev/75be133c679c0b60b2c49aaf54866712770f20c0

(In reply to :Gijs (he/him) from comment #13)

Chatted with Marco, this looks similar enough to bug 821628 that it seems worth just trying out the same fix to see if that is sufficient here:

13:07:35 <@Gijs> https://treeherder.mozilla.org/#/jobs?repo=try&revision=583a53141c7edb2da2ff0194c4c86302da9a678f and https://hg.mozilla.org/try/rev/75be133c679c0b60b2c49aaf54866712770f20c0

I can confirm this fix works. \o/

Flags: needinfo?(nfroyd)
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/b4f623538760
fix xptcall stubs for aarch64 for bool params, r=froydnj
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66
Flags: needinfo?(gijskruitbosch+bugs)
Assignee: nobody → gijskruitbosch+bugs
Depends on: 1521991
Component: Downloads Panel → XPConnect
Product: Firefox → Core
Target Milestone: Firefox 66 → ---

Gah, apologies for the excessive bug spam.

Target Milestone: --- → mozilla66

Verified - Fixed on latest Firefox Nighty and Firefox Beta on Laptop Lenovo Yoga with Windows 10.
The download icon appears and lights up after a file is downloaded. The files also appear in the downloads list.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.