(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Taking

I'm having trouble understanding this bug, especially because it doesn't repro well in the debugger :(. I've also 
noticed the following:

1. Quit Preview, if open.
2. Download a PDF and click the download item button.
3. Preview activates quickly and then deactivates.
4. Quit Preview.
5. Press *the same* download item and Preview activates and stays that way.
6. Quit Preview.
7. Download the same PDF (or a different one).
8. Press the button, and get the same behavior as 3.

So it seems that if the file gets opened once (and you hit this bug), it will not happen subsequent times for that 
file. I stepped through the debugger and they obviously take the same code path, so I do not know what gives.

Preview stays active for me in step 3 (10.5.8).

However, extended attributes on the file change between 2 and 7:

dhcp-172-19-9-120:src thakis$ ls -l@ ~/Downloads/Chrome/BROCHURE_CONGRESSI_4nov.pdf 
-rw-r--r--@ 1 thakis  5000  2326686 May 21 08:31 
/Users/thakis/Downloads/Chrome/BROCHURE_CONGRESSI_4nov.pdf
	com.apple.metadata:kMDItemWhereFroms	    172 
	com.apple.quarantine	     85 
dhcp-172-19-9-120:src thakis$ ls -l@ ~/Downloads/Chrome/BROCHURE_CONGRESSI_4nov.pdf 
-rw-r--r--@ 1 thakis  5000  2326686 May 21 08:31 
/Users/thakis/Downloads/Chrome/BROCHURE_CONGRESSI_4nov.pdf
	com.apple.metadata:kMDItemWhereFroms	    172 


Maybe that makes a difference?

com.apple.quarantine	     85

That makes it seem like a sandbox issue at first glance.

Maybe this is a SL issue, because I see this on 10.6.  I'm not sure if it's an issue with our sandbox or if it's 
something with the way NSWorkspace works.

It's probably not an issue with our sandbox, because downloading happenings in the browser process, which isn't 
sandboxed (and you can always run chrome with --no-sandbox and check). I think andy meant OS X's sandbox 
for downloaded files (com.apple.quarantine), though it'd be weird if quarantined files opened up normally but in 
the background.

This is an Apple bug; Safari has the same issue (if you Opt+Click a PDF link, rather than letting it get displayed 
in-browser).  I'll file a Radar on Monday.

That is, yes, the com.apple.quarantine flag is responsible for this non-activating behavior. Proof:

1. Download a PDF file, but do not press the shelf's button
2. Type "xattr -d com.apple.quarantine <file>" in your Terminal
3. In Chromium, press the download shelf button
4. Preview takes active state

Filed with Apple as radar://8019954. Publicly posted to http://openradar.appspot.com/radar?id=374401.

I have a nice work around using AppleEvents.  Yay!

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=56026 

------------------------------------------------------------------------
r56026 | rsesek@chromium.org | 2010-08-13 08:24:53 -0700 (Fri, 13 Aug 2010) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/base.gypi?r1=56026&r2=56025
   A http://src.chromium.org/viewvc/chrome/trunk/src/base/scoped_aedesc.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/platform_util_mac.mm?r1=56026&r2=56025

[Mac] Use an AppleEvent to tell the Finder to open downloaded items, rather than NSWorkspace.

BUG=32921,50263
TEST=Force a PDF to download. Quit Preview, if open. Open the downloaded PDF from the download shelf. Preview opens and becomes frontmost.
TEST=Download a file of a type that you do not have an application with which to open it. Open it from the download shelf. Finder bounces for your attention to choose an application to open it.

Review URL: http://codereview.chromium.org/3151011
------------------------------------------------------------------------

(No comment was entered for this change.)

Verified label updated by AutoAllocator, contact AmolK or KrisR for details

Verified in 6.0.496.0 (Official Build 56183) dev using http://www.torrentbit.net/torrent/1747720/40%20Amazing%20Fireworks%20and%20Crackers%20HQ%20Wallpapers/

 Issue 57248  has been merged into this issue.

 Issue 57367  has been merged into this issue.

 Issue 27629  has been merged into this issue.

Reopening since this still doesn't work for files opened in the Finder (dmgs, zip files). I don't think we can do much about it, and Safari on Lion seems to have the same problem, but we should have an open bug for this.

(No comment was entered for this change.)

(No comment was entered for this change.)

Pinging this issue.  Currently in v17 it's not as originally described in the bug, but it still is funcitonally worse compared to firefox.

Chrome repro steps:  Download a .dmg file, let it complete, click it from the downloads shelf at the bottom.

Expected Results:  DMG is mounted by finder with focus
Actual Results: DMG is mounted and open in a finder window, but z-order is at the bottom, below the chrome window, and the user thinks it is a no-op


Firefox: Download DMG, presented with an 'open with or save as' dialog.  Select save.  Double click dmg from downloads pane.

Results: DMG is mounted and opened above the page, but below the downloads popup.


We've had some high profile users trip up during install on this issue.

(No comment was entered for this change.)

(No comment was entered for this change.)

This is an important issue creating confusion for users running installers from in Chrome. In particular this is impacting G+ Hangouts as it makes it hard for users to install the GoogleTalkPlugin on mac.  Please let us know what we can do to get this prioritized.