Revert 227347 "Run strip via xcrun."

When the SDK is set to something that Xcode doesn't know about (such as 10.6),
xcrun doesn't work correctly.

mark@cougar bash$ xcrun strip
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: no files specified
mark@cougar bash$ SDKROOT=/SDKs/MacOSX10.6.sdk xcrun strip
xcodebuild: error: SDK "/SDKs/MacOSX10.6.sdk" cannot be located.
xcrun: error: unable to find utility "strip", not a developer tool or in PATH

> Run strip via xcrun.
> 
> In Xcode 5, strip is no longer in SYSTEM_DEVELOPER_BIN_DIR. It is only in
> DT_TOOLCHAIN_DIR. I also checked Xcode 4.6.1 and found that DT_TOOLCHAIN_DIR
> was also set there, and strip is in both SYSTEM_DEVELOPER_BIN_DIR and
> DT_TOOLCHAIN_DIR in that version.
> 
> Environment variables as set when Xcode is installed at /Applications/Xcode.app:
> 
> SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
> DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefa
> ult.xctoolchain
> 
> xcrun should be able to find strip without having to resort to manual
> environment interpretation.
> 
> R=thakis@chromium.org
> 
> Review URL: https://codereview.chromium.org/24352006

TBR=mark@chromium.org

Review URL: https://codereview.chromium.org/26235007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@227524 0039d316-1c4b-4281-b951-d872f2087c98
Proper fix for a hanging bug in chrome.downloads.acceptDanger() on mac.

WebContents modal dialogs are only displayed if their host contents is actually visible, not just if they should be visible.
https://code.google.com/p/chromium/codesearch#chromium/src/components/web_modal/web_contents_modal_dialog_manager.cc&rcl=1380589389&l=42
On mac, ExtensionPopupController starts running and rendering the popup about 200ms before the webcontents actually becomes visible.
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/cocoa/extensions/extension_popup_controller.mm&l=32

Before this CL, when acceptDanger() created the modal dialog, it would Block the popup web contents but wouldn't actually show the modal dialog because the popup web contents was still animating into view. After this CL, the popup can call acceptDanger() as early as it likes, but the modal dialog won't actually be created until the popup web contents finishes animating in, so the modal dialog will be shown.

100ms is about the speed of human perception, so the modal dialog should not seem to lag much more than the rest of the system.
It doesn't check the wall time when it retries, it just counts how many times it's tried to show the dialog. So if chrome only gets a timeslice every 5 seconds, then it'll time out after 5 seconds times the maximum number of retries.
3 retries (x 100ms) would probably be sufficient most of the time. Too few retries would mean that the acceptDanger() call would unnecessarily fail. 10 retries is probably unnecessarily safe without wasting too much computing time if a future bug should cause the popup to never finish animating into view.

BUG=280107
R=asargent@chromium.org

Review URL: https://codereview.chromium.org/25665007

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@227525 0039d316-1c4b-4281-b951-d872f2087c98
SVN changes up to revision 227525