Obsolete
Status Update
No update yet.
Comments
do...@gmail.com
Forgot the attachment. Trivial example now attached.
sa...@chromium.org
[Empty comment from Monorail migration]
do...@gmail.com
Sorry, missed a crucial step when typing this up:
5. Navigate to chrome://downloads.
5. Navigate to chrome://downloads.
be...@chromium.org
Do you want to open downloads when they complete? I'd use the onChanged event for that, not onCreated.
I think you can rely on the state being in_progress in onCreated for items that were not restored from history.
The created event is fired synchronously on the UI thread, so the download cannot complete until the ExtensionDownloadsEventRouter finishes processing the created event.
This is true even for trivial downloads: you can copy that data url directly into the omnibox.
If you have a log showing the onCreated event with a state other than in_progress for a new download not restored from history then I'll reopen this issue. I'll use the startTime to verify that it's a new download; e.g. below you can see that onCreated was logged 2 milliseconds after the download started.
chrome.downloads.onCreated.addListener(function(d){console.log('created', new Date().toISOString(), JSON.stringify(d))});
created 2014-11-13T16:46:27.027Z {"bytesReceived":0,"canResume":false,"danger":"safe","exists":true,"fileSize":0,"filename":"","id":115,"incognito":false,"mime":"application/octet-stream","paused":false,"referrer":"","startTime":"2014-11-13T16:46:27.025Z","state":"in_progress","totalBytes":0,"url":"data:application/octet-stream,"}
At a low level, restoring a download item from history is considered a kind of creation. If the downloads system is ever modified to fire events asynchronously in a way that makes it possible for the download to complete before the ExtensionDownloadsEventRouter finishes processing the created event, then we can revisit the idea of suppressing created events for items restored from history or exposing information about whether the download is new or from history.
I think you can rely on the state being in_progress in onCreated for items that were not restored from history.
The created event is fired synchronously on the UI thread, so the download cannot complete until the ExtensionDownloadsEventRouter finishes processing the created event.
This is true even for trivial downloads: you can copy that data url directly into the omnibox.
If you have a log showing the onCreated event with a state other than in_progress for a new download not restored from history then I'll reopen this issue. I'll use the startTime to verify that it's a new download; e.g. below you can see that onCreated was logged 2 milliseconds after the download started.
chrome.downloads.onCreated.addListener(function(d){console.log('created', new Date().toISOString(), JSON.stringify(d))});
created 2014-11-13T16:46:27.027Z {"bytesReceived":0,"canResume":false,"danger":"safe","exists":true,"fileSize":0,"filename":"","id":115,"incognito":false,"mime":"application/octet-stream","paused":false,"referrer":"","startTime":"2014-11-13T16:46:27.025Z","state":"in_progress","totalBytes":0,"url":"data:application/octet-stream,"}
At a low level, restoring a download item from history is considered a kind of creation. If the downloads system is ever modified to fire events asynchronously in a way that makes it possible for the download to complete before the ExtensionDownloadsEventRouter finishes processing the created event, then we can revisit the idea of suppressing created events for items restored from history or exposing information about whether the download is new or from history.
do...@gmail.com
Thanks for the tips on the workaround. I have indeed resorted to in_progress (as well as a sanity backstop with startTime.
But I disagree that onCreated should be called when "save as" is used or chrome://downloads is visited. Perhaps it happens naturally as an implementation detail of "restoring a download item from history", but that is not a concept that is anywhere visible in the API.
At the minimum, this is a documentation issue. And perhaps when it is written down that onCreated might be called 1000s for items that aren't actually being downloaded, this bug will be re-visited.
is...@google.com
This issue was migrated from crbug.com/chromium/432757?no_tracker_redirect=1
[Monorail components added to Component Tags custom field.]
[Monorail components added to Component Tags custom field.]
Description
Steps to reproduce the problem:
I'm reproducing this on 39, but have customers seeing it with 38 and 37 also. It'll sound strange, but I reproduced it with a clean profile on multiple machines. It may be Windows only. Here are the repro steps:
1. Load the attached extension as an unpacked extension (it just does a console.log for onCreated)
2. Make sure you have items listed in the chrome://downloads page. If not, then go download something like this:
3. Shut down Chrome completely.
4. IMPORTANT: Make sure all chrome.exe processes are closed (with taskmgr, procmgr, etc). For example, in my case, I have to kill them because some linger.
What is the expected behavior?
chrome.downloads.onCreated is not hit at all, and nothing is logged in the console.
What went wrong?
Look in the extension's console. You will see onCreated get hit for EVERY SINGLE item in the chrome://downloads page.
You can also reproduce this problem by right-clicking on a link and selecting "Save As" instead of going to the chrome://downloads page. But note that it only happens once per process run, you have to re-start chrome.exe completely for it to happen again.
This very strange behavior caused a really serious problem for us (i.e. we end up re-opening all of the downloads, thinking that they were new downloads).
WebStore page:
Did this work before? N/A
Chrome version: 39.0.2171.62 Channel: beta
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 15.0 r0
I am actively seeking a workaround for detecting new downloads vs. items that have already been downloaded. I'm concerned that in_progress status is not good enough because I'm not sure that we are guaranteed to always get in_progress (instead of just sometimes receiving "complete").