Browser-laptop: Downloading a wrong Dropbox installer for the OS on Mac

[jenn-rhim]

• Did you search for similar issues before submitting this one?
  Yes
• Describe the issue you encountered:
  Getting the wrong dropbox installer file for the OS, when the request was made from Brave
• Platform (Win7, 8, 10? macOS? Linux distro?):
  macOS 10.12.6
• Brave Version (revision SHA):
  0.18.23

• Steps to reproduce:

  1. Go to https://www.dropbox.com/install (or within Dropbox web, once signed in, click on the user menu at the top right avatar, and then click on 'Install' menu item, located above Sign out)
  2. Click on 'Download Dropbox' button
  3. Client request is https://www.dropbox.com/download?os=mac

• Actual result:
  Brave tries to download “DropboxInstaller.exe” file

• Expected result:
  "DropboxInstaller.dmg" for macOS
• Will the steps above reproduce in a fresh profile? If not what other info can be added?
  Yes
• Is this an issue in the currently released version?
  Yes
• Can this issue be consistently reproduced?
  Yes

• Extra QA steps:

  1. Tested on Safari and Chrome: both auto download .dmg file to user's Downloads folder
     2.
     3.

• Screenshot if needed:
  

• Any related issues:

[celicoo]

The function responsible for downloading the file is the registerForDownloadListener (app/filtering.js), which registers a listener for the will-download event using the Electron session. The callback for the will-download listener receives 3 parameters: event, item and webContent. The item parameter is an object with the getURL method, and it is returning the following link:

https://dl-web.dropbox.com/installer?authenticode_sign=True&build_no=32.4.23&juno=True&juno_use_program_files=True&plat=win&tag=eyJUQUdTIjoiZUp5clZpcE9MUzdPek0tTHoweFJzbEl3TkRVM056U3hNREEzTnpHd3NEUTN0akN3TkxVd01yQzBOREd5TkRNM01qTUZpcGliMUFJQW5oME5wZ35-QE1FVEEifQ&tag_token=AHrAeoQC1lnsRpTc7P2oTuUqpaqYLkdTJVF9V8v3OBYdHg

When it should be returning:

https://dl-web.dropbox.com/installer?build_no=32.4.23&plat=mac&tag=eJyrVipOLS7OzM-Lz0xRslIwNDU3NzSxMDA3NzGwsDQ3tjCwNLUwMrC0NDGyNDM3MjMFipib1AIAnh0Npg~~%40META&tag_token=AHoYZbCl9XgViodp5JrYy4LQZYJryEdOEY7qHiYj4LihIg

perhaps this issue should be moved to the muon repository @luixxiul.

I hope I have helped :).

[luixxiul]

@celicoo do you know how to fix that? If so it would be appreciated if you could create a PR on https://github.com/brave/muon, our folk of the original electron. thanks!

[celicoo]

@luixxiul Sure :blush:

[bsclifton]

@celicoo nice find! Please ping @bridiver, @darkdh, @bbondy, or myself if you need help with creating a patch 😄

[celicoo]

@bsclifton I was able to track the will-download event until here, but now i'm not finding how to recompile only muon, if possible.

[bsclifton]

@celicoo when building (fresh and after making changes), I'll use the browser-laptop-bootstrap project and build using the following:
npm run build -- --debug_build=true --official_build=false

As long as your changes are isolated to Muon (ex: the under src/electron), it likely won't cause a full recompile. In the area you linked, you can easily add some debug statements like so:

LOG(ERROR) << "message goes here";

(of course, you'd have to find how to get the DownloadItem into a string or otherwise printable object if you wanted to print the values it has)

[darkdh]

you can use

LOG(EROR) << item->GetTargetFilePath().value();

[bridiver]

for some reason we're sending an empty user-agent when the link is clicked, but when you type https://www.dropbox.com/download?os=mac manually it works correctly. The resourceType is listed as other which also seems odd, but might be correct. I've never looked closely at the resource type for a download link. I see the same thing with shields up and down

[jonathansampson]

This issue was also reported by a user on Twitter.

The problem is caused by the [download] attribute. When it is present, an EXE is presented. When the attribute is not present, a DMG is presented:

<a href="/download?os=mac" download>Restart the Download</a>

The server responds with a location header resembling the following:

https://dl-web.dropbox.com/installer?authenticode_sign=True&build_no=42.4.114&juno=True&juno_use_program_files=True&plat=win&tag=eyJUQUdTIjoiZUp5clZpcE9MUzdPek0tTHoweFJzbEl3TWpVMXNUUXdNelF5c1RBME1UVTNOVEEyTkxVMHNqUzNNREswTkRjeUFNcUJ4TXhxQWFsWkRiNH5ATUVUQSJ9&tag_token=AJIhVisf0tbKuGob7b5QN47diG_3TbmFlHzZ04nhKgoyrQ

The browser then makes a request for that resource, which results in another response from the server having a content-disposition value of _attachment; filename=DropboxInstaller.exe_.

@bridiver, might be a thread to pull.

[dcrck]

Testing with 0.25.0, this issue appears to be fixed. @bsclifton , can you close the issue?