TaskManagerBrowserTest.WebWorkerJSHeapMemory: update postMessage() usage.

Fix TaskManagerBrowserTest.WebWorkerJSHeapMemory and enable.

Update and enable the test, including adjusting postMessage() usage to no
longer call the method without any arguments.

R=ncarter, alph
BUG=339441, 259368
Committed: https://crrev.com/340b1af9ed2b819cb87033a8355a4f5b9ffb7f3e
Cr-Commit-Position: refs/heads/master@{#322018}

[sof, 2015-03-23 19:30:50]

sigbjornf@opera.com changed reviewers:
+ alph@chromium.org, nick@chromium.org

[sof, 2015-03-23 19:30:51]

Please take a look - hope I got the reviewers right.. :)

We're trying to make postMessage() conform to spec --
https://codereview.chromium.org/1025203002/ -- and need to adjust a pair of
postMessage() uses in this (disabled) unit test.

[ncarter (slow), 2015-03-23 23:33:08]

It just so happens that I'm back from paternity leave today, so I'm able to
review this.

Thanks for the fix.

https://codereview.chromium.org/1027333003/diff/1/chrome/browser/task_manager...
File chrome/browser/task_manager/task_manager_browsertest.cc (right):

https://codereview.chromium.org/1027333003/diff/1/chrome/browser/task_manager...
chrome/browser/task_manager/task_manager_browsertest.cc:779: // Checks that task
manager counts a worker thread JS heap size.
Unfortunately, this has been disabled for a while, and it's atrophied in that
time. So as long as we're updating it, let's fix it. Fortunately, it doesn't
look too hard from what I can tell. I tried the following suggestions out
locally on my Windows box, and the test seems to be passing now.

https://codereview.chromium.org/1027333003/diff/1/chrome/browser/task_manager...
chrome/browser/task_manager/task_manager_browsertest.cc:781: // Flaky,
http://crbug.com/259368
Remove this line, since we're fixing this bug.

https://codereview.chromium.org/1027333003/diff/1/chrome/browser/task_manager...
chrome/browser/task_manager/task_manager_browsertest.cc:782:
IN_PROC_BROWSER_TEST_F(TaskManagerBrowserTest, DISABLED_WebWorkerJSHeapMemory) {
Remove the DISABLED_ so that the bots will start running the tests again.

https://codereview.chromium.org/1027333003/diff/1/chrome/browser/task_manager...
chrome/browser/task_manager/task_manager_browsertest.cc:783:
ui_test_utils::NavigateToURL(browser(), GetTestURL());
Call ShowTaskManager() -- before or after the NavigateToURL call; shouldn't
matter. This call used to happen in test setup, and we forgot to update this
disabled test.

https://codereview.chromium.org/1027333003/diff/1/chrome/browser/task_manager...
chrome/browser/task_manager/task_manager_browsertest.cc:805: 
Add two lines here:

ASSERT_NO_FATAL_FAILURE(WaitForTaskManagerRows(1, MatchTab("title1.html")));
ASSERT_NO_FATAL_FAILURE(WaitForTaskManagerRows(1, MatchAnyTab()));

https://codereview.chromium.org/1027333003/diff/1/chrome/browser/task_manager...
chrome/browser/task_manager/task_manager_browsertest.cc:806: int resource_index
= TaskManager::GetInstance()->model()->ResourceCount() - 1;
Change this to:

int resource_index = FindResourceIndex(MatchTab("title1.html"));

Just relying on the row we want to be the last entry in the TaskManager would
probably explain the test flakiness.

[sof, 2015-03-24 06:37:31]

On 2015/03/23 23:33:08, ncarter wrote:
> It just so happens that I'm back from paternity leave today, so I'm able to
> review this.
> 

Welcome back! :) Yes, I'm all for trying to fix the test as well -- I've
incorporated your changes verbatim.

[alph, 2015-03-24 14:50:13]

lgtm. thanks for fixing it!

[sof, 2015-03-24 15:01:15]

On 2015/03/24 14:50:13, alph wrote:
> lgtm. thanks for fixing it!

bots are all taking to the enabled test, so sending it along; thanks.

[sof, 2015-03-24 15:01:18]

The CQ bit was checked by sigbjornf@opera.com

[commit-bot: I haz the power, 2015-03-24 15:02:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1027333003/20001

[commit-bot: I haz the power, 2015-03-24 15:09:05]

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

[commit-bot: I haz the power, 2015-03-24 15:09:06]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[sof, 2015-03-24 15:12:15]

On 2015/03/24 15:09:06, I haz the power (commit-bot) wrote:
> Try jobs failed on following builders:
>   chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

ah, owner approval needed.

[ncarter (slow), 2015-03-24 17:09:04]

The CQ bit was checked by nick@chromium.org

[ncarter (slow), 2015-03-24 17:09:04]

lgtm

LGTM

[commit-bot: I haz the power, 2015-03-24 17:09:26]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1027333003/20001

[commit-bot: I haz the power, 2015-03-24 17:13:02]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-03-24 17:14:04]

Patchset 2 (id:??) landed as
https://crrev.com/340b1af9ed2b819cb87033a8355a4f5b9ffb7f3e
Cr-Commit-Position: refs/heads/master@{#322018}

[Nico, 2015-03-30 18:33:16]

thakis@chromium.org changed reviewers:
+ thakis@chromium.org

[Nico, 2015-03-30 18:33:17]

This test causes 100% of the flaky redness on the
http://build.chromium.org/p/chromium.fyi/builders/CrWinClang64(dbg)%20tester
bot. Is it really stable on the main waterfall? (The win/clang bots are in
bring-up, but it feels unlikely that this is a compiler bug)

[ncarter (slow), 2015-03-30 18:44:21]

Nico, thanks for the report. I can't imagine it's a compiler bug either, likely
a timing thing.

I'll disable and investigate.

[Nico, 2015-03-30 21:31:09]

On 2015/03/30 18:44:21, ncarter wrote:
> Nico, thanks for the report. I can't imagine it's a compiler bug either,
likely
> a timing thing.
> 
> I'll disable and investigate.

(Nick disabled the test in https://codereview.chromium.org/1045943002/ .
Thanks!)