Modifying some downloads hooks to act per-window (so that incognito windows c...

Modifying some downloads hooks to act per-window (so that incognito windows can be correctly targetted) and updating some surrounding test cases.

BUG=59259
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=71856

[Nirnimesh, 2011-01-15 02:28:04]

http://codereview.chromium.org/6159001/diff/36001/chrome/test/functional/down...
File chrome/test/functional/downloads.py (right):

http://codereview.chromium.org/6159001/diff/36001/chrome/test/functional/down...
chrome/test/functional/downloads.py:602: # WaitForAllDownloadsToComplete is
flaky for this test case.
Please create a bug and cc rdsmith on it. Reference the bug here

And in the interest of keeping the flakiness low, continue using the old method,
or at least use that too.

http://codereview.chromium.org/6159001/diff/36001/chrome/test/pyautolib/pyaut...
File chrome/test/pyautolib/pyauto.py (right):

http://codereview.chromium.org/6159001/diff/36001/chrome/test/pyautolib/pyaut...
chrome/test/pyautolib/pyauto.py:743: try:
why?

[Allen, 2011-01-15 02:52:57]

On 2011/01/15 02:28:04, Nirnimesh wrote:
>
http://codereview.chromium.org/6159001/diff/36001/chrome/test/functional/down...
> File chrome/test/functional/downloads.py (right):
> 
>
http://codereview.chromium.org/6159001/diff/36001/chrome/test/functional/down...
> chrome/test/functional/downloads.py:602: # WaitForAllDownloadsToComplete is
> flaky for this test case.
> Please create a bug and cc rdsmith on it. Reference the bug here
> 
> And in the interest of keeping the flakiness low, continue using the old
method,
> or at least use that too.

Yes, the current incarnation is not flaky, but it includes the seemingly
redundant WaitUntil.
> 
>
http://codereview.chromium.org/6159001/diff/36001/chrome/test/pyautolib/pyaut...
> File chrome/test/pyautolib/pyauto.py (right):
> 
>
http://codereview.chromium.org/6159001/diff/36001/chrome/test/pyautolib/pyaut...
> chrome/test/pyautolib/pyauto.py:743: try:
> why?

It turns out that incognito windows do not initialize a download manager until
something downloads-related is invoked.

furthermore, the download manager on the incognito profile includes downloads
from the normal profile, so once loaded, the actual number of downloads known to
the manager might be > 0, so the test to show that a new download started was
changed below to an inequality.

This didn't seem ideal, but I wasn't sure about alternatives.  Perhaps a
function that simply invoked pre-loading of the download manager.  If this
sounds better to you, make a fuss and I'll look into it.

[Nirnimesh, 2011-01-15 11:03:32]

> It turns out that incognito windows do not initialize a download manager until
> something downloads-related is invoked.

At this point I think we could get rid of the check for download manager in
provider, that is return back an empty list.
No download manager essentially means no downloads.

[Nirnimesh, 2011-01-15 11:07:03]

> At this point I think we could get rid of the check for download manager in
> provider, that is return back an empty list.

No, I take that back. 
Trigger a download, restart the browser and immediately ask for DownloadsInfo()
and it might return an empty list.. which is badness.

LGTM