[bug] Download in private mode

[Nokius]

Download of an file in private-mode is not listet in Settings->System->Transfer. Also there is no banner that the download is committed completed.

Version: sailfish-browser-1.2.36.1-10.13.2.jolla.armv7hl [SailfishOS 1.1.7.24 (Björnträsket)]

[ghost]

I think this is how it should be, private browsing shouldn't leave any local traces.

[Nokius]

sure if there is no entry in the Transfer are ok but u don't see any think User don't know that the download starts or finish I found out by switching back to normal mode that I had download the file 6 times before :s

[ghost]

Oh, sure, a temporary notification would probably be useful, but definitely nothing that remains after private browsing is stopped.

[Nokius]

Yes, even the information about the Download like satus and remaining time in the Settings Cover would be nice

[Nokius]

@rainemak this is the issue I mention last night,

may it's possible to trigger in SFOS 2.0 introduce notification when the Download is done. This will may help to avoid confusion on the user side.

p.s. on the other hand the user is not able to use the download, only if he use a terminal or a filemanager.

[siteshwar]

We are seeing this issue because gecko does not produce dl-done message in private mode. Here is the code which checks for download mode before producing this message https://github.com/nemomobile-packages/gecko-dev/blob/74f02d2d3e7b4c1129ee81a21b750b689ff7e41a/toolkit/components/downloads/nsDownloadManager.cpp#L2891-L2893

[siteshwar]

@rainemak @rojkov Is it ok if I just take out the checks for mPrivate before producing download related messages in this code block https://github.com/nemomobile-packages/gecko-dev/blob/74f02d2d3e7b4c1129ee81a21b750b689ff7e41a/toolkit/components/downloads/nsDownloadManager.cpp#L2875-L2912 ?

[rojkov]

This is an interesting problem for UX designers: private downloads should not be listed in the Transfer UI, but there should be a possibility to cancel big downloads.

The current workaround could be removing the mPrivate checks from gecko and adding similar checks to browser's downloadmanager.cpp ("in case of a private download don't call the transfer engine, but show notification"). BTW, in xulrunner based on gecko38 this nsDownloadManager is disabled and Downloads.jsm is used instead.

[siteshwar]

ok, so fix seems to be trivial for gecko31.

@roppola Any ideas about how should the user interface behave for private downloads ?

[siteshwar]

embedlite-components use download id attribute to uniquely identify a download (https://github.com/nemomobile-packages/embedlite-components/blob/d0ade277a4a2b31089a9f073736348d631c18bec/jscomps/DownloadManagerUI.js#L31). However this attribute is not guarranted to be unique across private and normal browsing modes and it's not available in private mode (https://github.com/nemomobile-packages/gecko-dev/blob/nemo_embedlite_31/toolkit/components/downloads/nsDownloadManager.cpp#L3256-L3257).

Ideally we should be using guid attribute instead of id (See https://github.com/nemomobile-packages/gecko-dev/blob/nemo_embedlite_31/toolkit/components/downloads/nsIDownload.idl#L90-L95). guid is an alphanumeric attribute and we would need to modify sailfish-browser code to use QString instead of integers to use guid attribute. I am not sure if these changes will be compatible with Downloads.jsm.

[roppola]

I would propose we create a simple download UI inside the browser. Tapping the transfer icon could expand the toolbar, just like when searching from page or entering url. But instead of input field, there's a list of recenlty dowloaded files. It's probably enough to have ~10 latest downloads and a link to transfer UI to see everything.

Any takers? If it sounds something we can run with, I can create something to look at. I know it might be more than anyone asked for, but there's not really a way around the conflict with transfer UI wanting to expose things and private browsing to hide it.

[Nokius]

@siteshwar Thanks for taking action on this issue :)

@roppola I like your idea sounds like great idea, but we would have still the issue that User can't open Files from Private Browsing. There is no link to the Transfer UI, but the User is able to see that the Download is happening/happened

[siteshwar]

If Transfer UI is the only way I have access to downloaded files, then I would prefer my private downloads are listed in it (instead of creating a new solution within the browser). One solution could be that Transfer UI should know about private downloads and give user a choice to clean up private downloads if needed.

[roppola]

@Nokius Well, the idea is not mine, I'm looking at Firefox desktop client :) It maintains a persistent list of files downloaded during normal browsing, and a session based list for private one. Firefox for Android does the same, but you can see all private downlods inline with normal ones until the private browsing session ends.

@siteshwar SfOS transfer UI was intended to be an one stop shop for all upload/download related needs, so it kind of makes sense to implement private download functionality there. However, I don't know who maintains it atm, and how long would it take to get this feature approved by the mgmt so it can be implemented. Our internal backlog is still pretty lengthy, so this might not rank high there.

Lastly, the current method of opening dowloaded file is slow by modern standards. You first get a notification, tap it to invoke transfer UI page in settings app, before you can tap the downloaded file to jump again to another app. It's two cross-window transitions, which is between 50-100% too much/slow, depending of what browser we compare it to :)

I can be wrong though. Maybe it's actually trivial to implement private download functionality to transfer UI, and also fix the download notification so that it doesn't always have to open settings app. @rainemak and @rojkov, what do you think?

[ghost]

I think some functionality could be duplicated. The browser could have its own 'download list', where tapping on a downloaded file immediately opens it, but all transfers could still be listed in the transfers UI. In any case the current way of doing it is indeed way too slow, especially if the Settings applications isn't active before you tap the downloaded file notification.

[Nokius]

just a little heads up on this issue.

Now days the browser shows in private mode that the download finished and yes the user will see it under Setting -> Transfer. My original opened issue is so solved.

The privacy issue, the stored information about the downloaded file should be a followup issue within Settings. Now days the download could be removed from the list because of the fact SailfishOS has now a build in File manager so users could find the file again.