WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
110566
Layout Test fast/loader/stateobjects/state-url-sets-links-visited.html is timing out in chromium
https://bugs.webkit.org/show_bug.cgi?id=110566
Summary
Layout Test fast/loader/stateobjects/state-url-sets-links-visited.html is tim...
Vsevolod Vlasov
Reported
2013-02-22 01:05:45 PST
The following layout test is failing in chromium fast/loader/stateobjects/state-url-sets-links-visited.html Caused by:
http://trac.webkit.org/changeset/143678
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Floader%2Fstateobjects%2Fstate-url-sets-links-visited.html
Attachments
Add attachment
proposed patch, testcase, etc.
Vsevolod Vlasov
Comment 1
2013-02-22 01:09:10 PST
Committed
r143702
: <
http://trac.webkit.org/changeset/143702
>
Benjamin Poulain
Comment 2
2013-02-22 01:18:09 PST
A timeout is a little unexpected. The max time before failing should have been around 1-2 second. Thank you for updating TestExpectations. I will update the file once the support is added to Chromium via Internals.
Adam Barth
Comment 3
2013-02-22 08:33:46 PST
> I will update the file once the support is added to Chromium via Internals.
Do you plan to do that?
Adam Barth
Comment 4
2013-02-22 08:49:00 PST
Mr. Poulain doesn't seem to be around, so I'm rolling out the change. Hopefully he'll be able to re-land it cleanly and not break other ports.
Benjamin Poulain
Comment 5
2013-02-22 10:22:52 PST
(In reply to
comment #3
)
> > I will update the file once the support is added to Chromium via Internals. > > Do you plan to do that?
I have had a patch ready for a while. I am fixing the related tests flakiness before landing:
https://bugs.webkit.org/show_bug.cgi?id=109772
Benjamin Poulain
Comment 6
2013-02-22 10:30:18 PST
Mr. Barth, can you please explain what is up?
Adam Barth
Comment 7
2013-02-22 10:37:13 PST
> Mr. Barth, can you please explain what is up?
You broke this test and you weren't around, so I rolled out your patch. Please feel free to re-land it in a way that doesn't break it.
Benjamin Poulain
Comment 8
2013-02-22 10:52:31 PST
(In reply to
comment #7
)
> > Mr. Barth, can you please explain what is up? > > You broke this test and you weren't around, so I rolled out your patch. Please feel free to re-land it in a way that doesn't break it.
So I "broke" a failing test? Yes, yes, I guess rolling out without explanation is much more appropriate than just updating TestExpectations. It is also good I talked about this test with you on IRC yesterday. Thank you for your help.
Adam Barth
Comment 9
2013-02-22 10:58:46 PST
> So I "broke" a failing test?
Yes. You caused a test to change behavior in an unexpected way. That makes makes the bot turn red and is what we mean by breaking a test.
> Yes, yes, I guess rolling out without explanation is much more appropriate than just updating TestExpectations. It is also good I talked about this test with you on IRC yesterday. Thank you for your help.
The policy of this project is that you are not permitted to break other ports. I tried to contact you on the bug and on IRC, but you weren't around. I did the appropriate thing and reverted your patch. If you would like to change the policy for WebCore to match the "Apple can break other ports" policy for WebKit2, that's something that needs to be discussed on webkit-dev. I realize that I'm taking a hard line here, but I'm afraid that the WebKit2 "Apple is the only port that matters" policy will slow creep into WebCore.
Benjamin Poulain
Comment 10
2013-02-22 11:02:55 PST
(In reply to
comment #9
)
> I realize that I'm taking a hard line here, but I'm afraid that the WebKit2 "Apple is the only port that matters" policy will slow creep into WebCore.
True, and I am well known for not helping the other ports too!!! I tend not to help Chromium like when you break WebKit1 yesterday (I was probably drunk back then).
Adam Barth
Comment 11
2013-02-22 11:16:20 PST
> True, and I am well known for not helping the other ports too!!! I tend not to help Chromium like when you break WebKit1 yesterday (I was probably drunk back then).
I appreciate your helping with that compile failure. It was obvious to me how to fix this test, I probably would have done that, but it wasn't obvious. Sweeping the problem under the rug in TestExpectations just leads to there being a lot of dirt under the rung. In any case, rollout patch out and rolling it back in isn't really a big deal. It's generally the safer course of action than trying to hot-fix an issue. For example, even after fixing the compile failure, there were several follow-on problems with Eric's patch yesterday. It's not clear to me that trying to hot-fix them led to the best outcome.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug