Mac: Let browser_tests run in bundled mode for their whole lifetime.

Mac: Let out-of-process tests run in bundled mode for their whole lifetime.

Since out-of-process tests override the EXE path to look like the bundled app, it makes sense to override AmIBundled() as well.

This is important because the renderer process started from browser_tests runs as bundled, and if browser and renderer process don't agree on bundled-ness, the "load plugin" requests for internal plugins from the renderer have the wrong plugin path, causing the plugin load to fail.

Also add a DCHECK that makes sure that AmIBundled() doesn't flip-flop.

This makes PDFBrowserTest work on mac, so enable it.

It looks like even unit_tests uses the out-of-process test runner, so this change is a bit hairy :-/

BUG=61258, 63183
TEST=all existing tests still pass, PDFBrowserTest.* passes.

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

[TVL, 2010-11-15 17:15:06]

Handing this off to Mark as he wrote a lot of the bundled/version directory
stuff.

This also undoes what we did with AmIBundled last time this came up, so that
seems like a dangerous start.

[Mark Mentovai, 2010-11-15 17:49:59]

Things are kind of broken now, but this still feels like a huge hack. I wonder
if there’s a way to fix things for real.

What sorts of path accesses are we really after?

http://codereview.chromium.org/4947002/diff/7001/chrome/common/chrome_paths_m...
File chrome/common/chrome_paths_mac.mm (right):

http://codereview.chromium.org/4947002/diff/7001/chrome/common/chrome_paths_m...
chrome/common/chrome_paths_mac.mm:68: // Raw test binary.
Care to elaborate?

[Nico, 2010-11-15 18:17:31]

On Mon, Nov 15, 2010 at 6:50 PM,  <mark@chromium.org> wrote:
> Things are kind of broken now, but this still feels like a huge hack. I
> wonder if there’s a way to fix things for real.
> What sorts of path accesses are we really after?

The one I care about at the moment is this guy:

// Gets the path for internal plugins.
bool GetInternalPluginsDirectory(FilePath* result) {
#if defined(OS_MACOSX)
  // If called from Chrome, get internal plugins from a subdirectory of the
  // framework.
  if (mac_util::AmIBundled()) {
    *result = chrome::GetFrameworkBundlePath();
    DCHECK(!result->empty());
    *result = result->Append("Internet Plug-Ins");
    return true;
  }
  // In tests, just look in the module directory (below).
#endif

  // The rest of the world expects plugins in the module directory.
  return PathService::Get(base::DIR_MODULE, result);
}

This returns different paths in the browser/test process and in the
renderer process.

Imho, this CL merely makes the existing hack (browser_tests changing
the exe name) more correct :-P
Another approach is to not change the exe name on OS X (which may or
may not be a can of worms) and to IPC the internal plugin directory to
the renderer at some point.

>
http://codereview.chromium.org/4947002/diff/7001/chrome/common/chrome_paths_m...
> chrome/common/chrome_paths_mac.mm:68: // Raw test binary.
> Care to elaborate?

Hm, this might no longer be necessary. In an earlier version of this
CL, I overrode AmIBundled, then did some other stuff, and then changed
the EXE path. I recently moved the EXE override to happen right after
the bundle override. I will try removing this and see if things still
work.

[Mark Mentovai, 2010-11-15 18:49:12]

I’ll give you an LGTM because this isn’t really any worse than the
current state of the world, but it’d be cleaner if you didn’t have
that phantom MacOS check that I picked on.

[Nico, 2010-11-15 19:20:11]

On Mon, Nov 15, 2010 at 7:49 PM, Mark Mentovai <mark@chromium.org> wrote:
> I’ll give you an LGTM because this isn’t really any worse than the
> current state of the world, but it’d be cleaner if you didn’t have
> that phantom MacOS check that I picked on.

Thanks. Looks like the MacOS check isn't necessary.