I know I ran these tests locally when I was working on the CL.  Why didn't they show up as failures?

Anyway, the issue is that the CL added a new attribute and I forgot to update the idl test with that.

Sorry about that!

Interesting. I also wonder why it only fails on Mac10.12. Raymond, could you point me to your earlier CL  that supposedly broke the test?

Yeah, just noticed crbug.com/626703 for the timeone out Mac10.12. I didn't know about that either.

And running ToT code today (that includes the new IDL attribute) on my linux box shows the webaudio idlharness test passes.

Plus I can't find run-blink-wptserve anymore.

The CL that added a new attribute: https://chromium-review.googlesource.com/c/chromium/src/+/945076

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/63cd4dfaaf44489cb6614d27de3bc08e4056c57b

commit 63cd4dfaaf44489cb6614d27de3bc08e4056c57b
Author: Raymond Toy <rtoy@chromium.org>
Date: Tue Apr 24 18:50:01 2018

Add AudioParam.automationRate to WebAudio IDL

Update WebAudio interface to include the very recently added
automationRate attribute for an AudioParam.

Also remove idlharness time expectation (suggested by Robert Ma).

And this doesn't actually resolve any of failures in the bug, but
it's a convenient place to update the IDL that should have been
done earlier.

Bug:  836051 
Test: webaudio/idlharness.https.html
Change-Id: Icd535ee63f0a5f8772cb3445c762c89154fbda88
Reviewed-on: https://chromium-review.googlesource.com/1026199
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553218}
[modify] https://crrev.com/63cd4dfaaf44489cb6614d27de3bc08e4056c57b/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/63cd4dfaaf44489cb6614d27de3bc08e4056c57b/third_party/WebKit/LayoutTests/external/wpt/interfaces/web-audio-api.idl
[modify] https://crrev.com/63cd4dfaaf44489cb6614d27de3bc08e4056c57b/third_party/WebKit/LayoutTests/external/wpt/webaudio/idlharness.https-expected.txt

I suspect the timeout was an unrelated, transient flake. The CL above doesn't actually "fix" anything, just removing the timeout expectation as there's really no reason for this IDL harness test to time out.

I'm going to mark as fixed since the "issue" is probably a flake (c#5).

If it's wrong, please reopen or file a new issue.