Bug 90522 – REGRESSION(r121813): Causes browser_tests failure: ErrorPageTest.DNSError_GoBack2{Forward2,AndForward} on Chromium {Linux,Mac,Win} (Requested by yosin on #webkit).

• Status: RESOLVED
• Resolution: INVALID
• Component: New Bugs

[WebKit Review Bot]

http://trac.webkit.org/changeset/121813 broke the build:
Causes browser_tests failure: ErrorPageTest.DNSError_GoBack2{Forward2,AndForward} on Chromium {Linux,Mac,Win} (Requested by yosin on #webkit).

This is an automatic bug report generated by the sheriff-bot. If this bug
report was created because of a flaky test, please file a bug for the flaky
test (if we don't already have one on file) and dup this bug against that bug
so that we can track how often these flaky tests case pain.

"Only you can prevent forest fires." -- Smokey the Bear

[WebKit Review Bot]

Created attachment 150726 [details]
ROLLOUT of r121813

Any committer can land this patch automatically by marking it commit-queue+.  The commit-queue will build and test the patch before landing to ensure that the rollout will be successful.  This process takes approximately 15 minutes.

If you would like to land the rollout faster, you can use the following command:

  webkit-patch land-attachment ATTACHMENT_ID

where ATTACHMENT_ID is the ID of this attachment.

Flakiness Dashboard:
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=browser_tests&tests=ErrorPageTest.DNSError_GoBack2

[WebKit Review Bot]

Comment on attachment 150726 [details]
ROLLOUT of r121813

Clearing flags on attachment: 150726

Committed r121836: <http://trac.webkit.org/changeset/121836>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Brady Eidson]

(In reply to comment #0)
> http://trac.webkit.org/changeset/121813 broke the build:
> Causes browser_tests failure: ErrorPageTest.DNSError_GoBack2{Forward2,AndForward} on Chromium {Linux,Mac,Win} (Requested by yosin on #webkit).

Are these tests that live in the WebKit open source project and have visibility from build.webkit.org?

If not, they should not keep WebKit changes from fixing WebKit regressions.

> Are these tests that live in the WebKit open source project and have visibility from build.webkit.org?
No. It was found on Chromium build bots.

> If not, they should not keep WebKit changes from fixing WebKit regressions.
I think this is WebKit tests doesn't cover this issue and affects other ports.
I hope japhe@ write tests in WebKit.

[Brady Eidson]

(In reply to comment #6)
> > Are these tests that live in the WebKit open source project and have visibility from build.webkit.org?
> No. It was found on Chromium build bots.

The Chromium buildbots on the Chromium project should not be allowed to hold up progress of the WebKit project.

If there is a change in WebKit that is undesirable to the Chromium project, the burden is on someone from the Chromium project to construct a test case in WebKit terms that demonstrates why the change is undesirable for WebKit.
 
> > If not, they should not keep WebKit changes from fixing WebKit regressions.
> I think this is WebKit tests doesn't cover this issue and affects other ports.

Chromium (as represented at the Chromium project) is not a WebKit port but rather a WebKit client.

Do you have evidence that this change directly affected the tests for a WebKit *port* here at webkit.org, as opposed to a WebKit client that is external to the WebKit project?

> I hope japhe@ write tests in WebKit.

Again, in this situation, the burden to write a failing test was not on him, but rather was on you (or another representative from the Chromium project).

[Brady Eidson]

If you need help constructing a test to submit to a webkit.org bug that shows a problem in the WebKit codebase, please don't hesitate to ask Nate or myself (or anyone in #webkit, really) for help.