New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 32921 link

Starred by 19 users

Issue metadata

Status: Fixed
Closed: Sep 2014
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

issue 68200

Sign in to add a comment

Opening a downloaded item won't bring it into focus unless the owner app is already opened.

Project Member Reported by, Jan 22 2010

Issue description

Assuming you have PDF Viewer as your default viewer for PDF files, make sure 
it is closed.

Click to download a PDF file. Wait until it is finished, then click on the 
download item button to open the file.

Observe that it opens in the background but Chrome stays at the front.

It should open and take focus away from Chrome.
Status: Assigned
Labels: Area-Feature
Labels: -Area-Feature Area-UI

Comment 4 by, Mar 13 2010

Status: Started

Comment 5 by, May 21 2010

Status: Assigned
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.

Comment 6 by, May 21 2010

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	    172	     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	    172 

Maybe that makes a difference?	     85

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

Comment 8 by, May 21 2010

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.

Comment 9 by, May 21 2010

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 (, 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 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 <file>" in your Terminal
3. In Chromium, press the download shelf button
4. Preview takes active state
Status: ExternalDependency
Filed with Apple as radar://8019954. Publicly posted to
Status: Started
I have a nice work around using AppleEvents.  Yay!
The following revision refers to this bug: 

r56026 | | 2010-08-13 08:24:53 -0700 (Fri, 13 Aug 2010) | 7 lines
Changed paths:

[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:

Status: Fixed
Labels: Verifier-Deepakg
Verified label updated by AutoAllocator, contact AmolK or KrisR for details
Status: Verified
Verified in 6.0.496.0 (Official Build 56183) dev using
 Issue 57248  has been merged into this issue.
 Issue 57367  has been merged into this issue.

Comment 20 by, Nov 1 2010

 Issue 27629  has been merged into this issue.
Status: Available
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.
Status: ExternalDependency
Blocking: 68200

Comment 24 by, Mar 28 2012

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.

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.
Blocking: chromium:68200
Project Member

Comment 29 by, Mar 10 2013

Blocking: -chromium:68200
Labels: -Feature-Downloads -Area-UI Cr-UI-Browser-Downloads Cr-UI

Comment 30 by, Jan 28 2014

FWIW, we currently have a local repro case in chrome - calling platform_util::OpenItem from a tab-modal dialog does not activate the finder.

platform_util::ShowItemInFolder _does_ activate the finder, so I'm not sure this is actually blocked on the rdar bug.
I filed the radar against 10.6, so it's entirely possible they've fixed it since then. 10.6 was the first OS release with a Cocoa finder, so it's possible this was just a bug in NSWorkspace<>new Finder.
Project Member

Comment 32 by, Sep 29 2014

The following revision refers to this bug:

commit b83907e0384a25d8d10e5e15c564db4ec18f21bc
Author: Robert Sesek <>
Date: Mon Sep 29 19:44:00 2014

[Mac] On Mavericks or later, use NSWorkspace to open download items.

With the NSWorkspaceLaunchWithErrorPresentation option, Finder no longer
silently fails opening the file.

BUG= 32921
TEST=Download a DMG file. Click the download shelf button to open/mount it. Finder activates the new disk image window as the topmost.
TEST=Download a file with an unassociated file extension type (e.g.  "test.foobar"). Click the download shelf button to open it. Finder presents the unknown file type dialog.

Review URL:

Cr-Commit-Position: refs/heads/master@{#297239}


Status: Fixed
This should work on 10.9 now.
 Issue 114370  has been merged into this issue.

Sign in to add a comment