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

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Asa Dotzler [:asa]]

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.

Comment 1

[Mike Hommey [:glandium]]

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.

Comment 2

[:Felipe Gomes (needinfo for replies!)]

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)

Comment 3

[Asa Dotzler [: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.

Comment 4

[:Gijs (he/him)]

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.

Comment 5

[:Gijs (he/him)]

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 ?

Comment 6

[:Gijs (he/him)]

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

Comment 7

[Asa Dotzler [:asa]]

(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.

Comment 9

[Mike Hommey [:glandium]]

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

Comment 10

[Nathan Froyd [:froydnj]]

(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.

Comment 11

[:Gijs (he/him)]

(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...)

Comment 12

[:Gijs (he/him)]

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?

Comment 13

[:Gijs (he/him)]

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

Comment 14

[Nathan Froyd [:froydnj]]

(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/

Comment 15

[:Gijs (he/him)]

Attachment: Bug 1513725 - fix xptcall stubs for aarch64 for bool params, r?froydnj

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b4f623538760
fix xptcall stubs for aarch64 for bool params, r=froydnj

Comment 17

[Raul Gurzau (:RaulG)]

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

Comment 18

[:Gijs (he/him)]

Gah, apologies for the excessive bug spam.

Comment 19

[Mike de Boer [:mikedeboer]]

https://hg.mozilla.org/projects/cedar/rev/b4f6235387606ef6fbf72556f25e46b20816903f
Bug 1513725 - fix xptcall stubs for aarch64 for bool params, r=froydnj

Comment 20

[Timea Cernea [:tbabos][inactive]]

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.