Bug 122181 - Please add a way to quick peek at failing tests at build.webkit.org/dashboard
Summary: Please add a way to quick peek at failing tests at build.webkit.org/dashboard
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Enhancement
Assignee: Alexey Proskuryakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-01 14:43 PDT by Alexey Proskuryakov
Modified: 2014-01-03 11:28 PST (History)
1 user (show)

See Also:


Attachments
proposed patch (37.93 KB, patch)
2014-01-02 00:19 PST, Alexey Proskuryakov
no flags Details | Formatted Diff | Diff
screenshot (482.86 KB, image/png)
2014-01-02 00:23 PST, Alexey Proskuryakov
no flags Details
another screenshot (33.11 KB, image/png)
2014-01-02 00:52 PST, Alexey Proskuryakov
no flags Details
proposed patch (38.03 KB, patch)
2014-01-02 01:01 PST, Alexey Proskuryakov
timothy: review+
Details | Formatted Diff | Diff
with a better way to load JSONP (37.25 KB, patch)
2014-01-03 11:22 PST, Alexey Proskuryakov
thorton: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 2013-10-01 14:43:36 PDT
It's good to have a way to go to complete test run results, but often, I just want a quick peek at which tests failed. Some kind of hover activated view would be helpful.

That could have links to result, and possibly to flakiness dashboard. Ideally, it would even tell me more about each test, e.g. when it started to fail, or whether it's been flaky on this bot. It could specifically note if it's a new test that was just landed in a failing state.
Comment 1 Alexey Proskuryakov 2013-10-16 10:44:37 PDT
See also bug 122901.
Comment 2 Alexey Proskuryakov 2014-01-02 00:19:02 PST
Created attachment 220209 [details]
proposed patch
Comment 3 Alexey Proskuryakov 2014-01-02 00:23:00 PST
Created attachment 220210 [details]
screenshot

> That could have links to result, and possibly to flakiness dashboard. Ideally, it would even tell me more about each test, e.g. when it started to fail, or whether it's been flaky on this bot. It could specifically note if it's a new test that was just landed in a failing state.

This patch doesn't implement all wishes at once. We'll see how necessary they are when using this first iteration
Comment 4 Alexey Proskuryakov 2014-01-02 00:52:23 PST
Created attachment 220213 [details]
another screenshot
Comment 5 Alexey Proskuryakov 2014-01-02 01:01:45 PST
Created attachment 220214 [details]
proposed patch

Slightly updated JSONP load error handling. Got rid of document.write in loadJSONP().
Comment 6 Alexey Proskuryakov 2014-01-02 12:13:37 PST
Comment on attachment 220214 [details]
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=220214&action=review

> Tools/ChangeLog:51
> +        enter it without a mousenter event, install a handler for mousewheel instead, and block
> +        document scrolling from this event handler when needed.

Bug 120786 tracks that we are not getting this mousewheel. I'll add a FIXME with the number when landing.
Comment 7 Alexey Proskuryakov 2014-01-02 12:14:12 PST
Comment on attachment 220214 [details]
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=220214&action=review

>> Tools/ChangeLog:51
>> +        document scrolling from this event handler when needed.
> 
> Bug 120786 tracks that we are not getting this mousewheel. I'll add a FIXME with the number when landing.

this *mouseenter*
Comment 8 Timothy Hatcher 2014-01-02 16:19:25 PST
Comment on attachment 220214 [details]
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=220214&action=review

> Tools/ChangeLog:47
> +        * BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/Popover.js:

We should merge these back to the Web Inspector too, if they are applicable.

> Tools/BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/Utilities.js:73
> +function loadJSONP(url, jsonCallbackName, callback)

Another option would be to tweak JSON.load to support an optional jsonCallbackName. Then just preprocess the result string (stripping the callback) before doing JSON.parse. That seems cleaner than creating an invisible iframe. And less likely to have XSS issues.

> Tools/BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/Utilities.js:77
> +    console.assert(typeof jsonCallbackName == "string");

I like to use === as much as possible.
Comment 9 Alexey Proskuryakov 2014-01-03 08:39:13 PST
> That seems cleaner than creating an invisible iframe.

Indeed! I went with invisible frame approach because these files don't have CORS headers, but since they reside on the same host, they don't need the headers.

I'll change it and post a new patch.
Comment 10 Alexey Proskuryakov 2014-01-03 11:22:31 PST
Created attachment 220322 [details]
with a better way to load JSONP

Only substantial changes are in Utilities.js.
Comment 11 Alexey Proskuryakov 2014-01-03 11:28:37 PST
Committed <http://trac.webkit.org/r161273>.