Fix navigation to unittest files

Fix navigation to unittest files.

We have a number of instances where unit tests call UrlOf('blank.html') or something
similar. The _base_dir is src/tools/telemetry/unittest_data, so the output of relpath
is something like ../blank.html. This works because the http server just ignores the
../ and serves up http://localhost/blank.html. In the case of cros autotests, the output of
relpath ends up being something like ../../../../../../autotest/, and this doesn't work.
When running unit tests via autotest, cwd and the unittest_data directory have no common
parent. If they did, the buggy code would continue to work.

This patch introduces navigate_to_test.NavigateToTestFile, which takes a filename relative to the unittest data directory, converts it to an absolute path, sets up an http server pointing to the unittest data directory, and navigates the tab to the file as requested. tab_test_case.Navigate is a wrapper used by the majority of these unit tests.

Enable all previously failing cros unittests as well.

BUG=337582
TEST=manual

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=252253

[achuithb, 2014-01-31 01:13:14]

Let me know what you think, Dave.

[dtu, 2014-02-03 21:27:31]

On 2014/01/31 01:13:14, achuith.bhandarkar wrote:
> Let me know what you think, Dave.

Hrm, this looks straightforward from the perspective of the unit tests, but has
a weird corner case, and the special case if statement gives a little bit too
much "magical" behavior for my taste.

The path passed into UrlOf should always be a qualified path (that is, either
absolute or relative to the CWD). It doesn't make total sense to pass a path
that's relative to the serving directory, because there may be multiple serving
directories. (I think what actually happens under the hood, is the HTTP server
uses the common prefix of the serving directories, but this behavior is not
obvious to the user.)

I think the unit tests are not doing the right thing, and it was only a
coincidence that they've passed so far on desktop.

[achuithb, 2014-02-03 21:39:31]

On 2014/02/03 21:27:31, dtu wrote:
> On 2014/01/31 01:13:14, achuith.bhandarkar wrote:
> > Let me know what you think, Dave.
> 
> Hrm, this looks straightforward from the perspective of the unit tests, but
has
> a weird corner case, and the special case if statement gives a little bit too
> much "magical" behavior for my taste.
> 
> The path passed into UrlOf should always be a qualified path (that is, either
> absolute or relative to the CWD). It doesn't make total sense to pass a path
> that's relative to the serving directory, because there may be multiple
serving
> directories. (I think what actually happens under the hood, is the HTTP server
> uses the common prefix of the serving directories, but this behavior is not
> obvious to the user.)
> 
> I think the unit tests are not doing the right thing, and it was only a
> coincidence that they've passed so far on desktop.

They are totally not. I was just being lazy - do you want me to fix all the unit
test invocations instead?

[dtu, 2014-02-03 21:42:52]

On 2014/02/03 21:39:31, achuith.bhandarkar wrote:
> On 2014/02/03 21:27:31, dtu wrote:
> > On 2014/01/31 01:13:14, achuith.bhandarkar wrote:
> > > Let me know what you think, Dave.
> > 
> > Hrm, this looks straightforward from the perspective of the unit tests, but
> has
> > a weird corner case, and the special case if statement gives a little bit
too
> > much "magical" behavior for my taste.
> > 
> > The path passed into UrlOf should always be a qualified path (that is,
either
> > absolute or relative to the CWD). It doesn't make total sense to pass a path
> > that's relative to the serving directory, because there may be multiple
> serving
> > directories. (I think what actually happens under the hood, is the HTTP
server
> > uses the common prefix of the serving directories, but this behavior is not
> > obvious to the user.)
> > 
> > I think the unit tests are not doing the right thing, and it was only a
> > coincidence that they've passed so far on desktop.
> 
> They are totally not. I was just being lazy - do you want me to fix all the
unit
> test invocations instead?


Yes, please. If you think of a way of doing this that has straightforward
behavior in the corner case, that would be good too.

[achuithb, 2014-02-18 22:29:58]

Dave, I've done this the 'right' way - there's no special magic in UrlOf any
more, and we always pass in the absolute qualified path.

Let me know what you think.

(Adding Tony for an additional pair of eyes).

[tonyg, 2014-02-19 16:30:12]

lgtm

Love to see these tests getting re-enabled. Here's to a more stable Telemetry on
CrOS!

[dtu, 2014-02-19 19:30:31]

lgtm

[achuithb, 2014-02-19 19:55:27]

On 2014/02/19 19:30:31, dtu wrote:
> lgtm

Thank you!

[achuithb, 2014-02-19 19:55:42]

The CQ bit was checked by achuith@chromium.org

[commit-bot: I haz the power, 2014-02-19 19:56:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/achuith@chromium.org/151003003/80001

[commit-bot: I haz the power, 2014-02-19 22:47:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-02-19 22:47:51]

Retried try job too often on mac_rel for step(s) telemetry_unittests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[achuithb, 2014-02-20 01:32:36]

The CQ bit was checked by achuith@chromium.org

[commit-bot: I haz the power, 2014-02-20 01:41:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/achuith@chromium.org/151003003/400001

[commit-bot: I haz the power, 2014-02-20 05:11:40]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/achuith@chromium.org/151003003/400001

[commit-bot: I haz the power, 2014-02-20 09:07:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/achuith@chromium.org/151003003/400001

[commit-bot: I haz the power, 2014-02-20 12:29:06]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/achuith@chromium.org/151003003/400001

[commit-bot: I haz the power, 2014-02-20 16:03:49]

Change committed as 252253