RESOLVED INVALID 88780
Web Inspector: Reenabled tests in r119962 still fails
https://bugs.webkit.org/show_bug.cgi?id=88780
Summary Web Inspector: Reenabled tests in r119962 still fails
Csaba Osztrogonác
Reported 2012-06-11 06:58:47 PDT
r119962 reenabled tests after implementing breaking from native callback, but tests are still failing.
Attachments
Patch (9.97 KB, patch)
2012-06-12 05:19 PDT, Peter Wang
no flags
test result after enlarge the value of m_timeout (398 bytes, text/plain)
2012-06-13 01:30 PDT, Peter Wang
no flags
Patch (9.32 KB, patch)
2012-06-13 20:28 PDT, Peter Wang
pfeldman: review+
webkit.review.bot: commit-queue-
Archive of layout-test-results from ec2-cr-linux-01 (878.01 KB, application/zip)
2012-06-14 05:28 PDT, WebKit Review Bot
no flags
Konrad Piascik
Comment 1 2012-06-11 07:01:22 PDT
Is there a concept of V8 and JSC specific tests?
Csaba Osztrogonác
Comment 2 2012-06-11 07:10:02 PDT
(In reply to comment #1) > Is there a concept of V8 and JSC specific tests? As far as I know the defcato rule is that platform independent expected files(next to the test) mean JSC specific and expected files in platform/chromium mean V8 specific results.
Csaba Osztrogonác
Comment 3 2012-06-11 07:12:04 PDT
Skipped on Qt again until proper fix to paint the bot green - http://trac.webkit.org/changeset/119976
Peter Wang
Comment 4 2012-06-11 18:18:28 PDT
Working on it.
Peter Wang
Comment 5 2012-06-12 05:19:33 PDT
Peter Wang
Comment 6 2012-06-12 05:28:06 PDT
(In reply to comment #5) > Created an attachment (id=147061) [details] > Patch There is a bug in xhr-breakpoints.html. The first parameter of "_setBreakpoint(url, bool)" should be assigned as "null" rather than an empty string, since in this function has a conditional statement "if (!url) ". Other test cases is ok.
Pavel Feldman
Comment 7 2012-06-12 06:24:04 PDT
(In reply to comment #6) > (In reply to comment #5) > > Created an attachment (id=147061) [details] [details] > > Patch > > There is a bug in xhr-breakpoints.html. The first parameter of "_setBreakpoint(url, bool)" should be assigned as "null" rather than an empty string, since in this function has a conditional statement "if (!url) ". > Other test cases is ok. !"" == true
Pavel Feldman
Comment 8 2012-06-12 08:39:45 PDT
Comment on attachment 147061 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147061&action=review > LayoutTests/inspector/debugger/xhr-breakpoints.html:44 > + pane._setBreakpoint(null, true); This should be "". "" stands for any XHR. Other than that, lgtm.
Peter Wang
Comment 9 2012-06-12 20:09:53 PDT
(In reply to comment #8) > (From update of attachment 147061 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=147061&action=review > > > LayoutTests/inspector/debugger/xhr-breakpoints.html:44 > > + pane._setBreakpoint(null, true); > > This should be "". "" stands for any XHR. Other than that, lgtm. Yes, I've investigated the related code and noticed it. But it's wired that Qt browser works well if I manually set breakpoint for "Any XHR", but failed to DRT test.:( The only different is that "_setBreakpoint()" is invoked by a click event in my manual operation and in DRT case it is directly called with parameters.
Peter Wang
Comment 10 2012-06-13 01:30:06 PDT
Created attachment 147262 [details] test result after enlarge the value of m_timeout I assigned "m_timeout" of "Tools/DumpRenderTree/qt/LayoutTestControllerQt.cpp" to 90000, the test result seems more close to expected. I have no idea should I just increase its value or write this case to "Layouttests/platform/qt/Skipped"?
Peter Wang
Comment 11 2012-06-13 01:43:47 PDT
And if I split the case into three according to test suites. Every cases can pass the test. Pavel, do you think it's a option to split the case to let Qt Browser walk around timeout problem?
Pavel Feldman
Comment 12 2012-06-13 04:56:47 PDT
(In reply to comment #11) > And if I split the case into three according to test suites. Every cases can pass the test. > Pavel, do you think it's a option to split the case to let Qt Browser walk around timeout problem? I think splitting the test will be masking the issue. I'd leave it skipped and file appropriate bug.
Peter Wang
Comment 13 2012-06-13 20:28:57 PDT
Peter Wang
Comment 14 2012-06-13 20:37:04 PDT
I've filed https://bugs.webkit.org/show_bug.cgi?id=89056 to record the problem of "xhr-breakpoints.html". Now only this case is left in Skipped of Qt Browser. And I'm sure this case can pass the test if we walk around the timeout problem. Csaba and Pavel, do you think the result is acceptable?
WebKit Review Bot
Comment 15 2012-06-14 05:28:28 PDT
Comment on attachment 147474 [details] Patch Attachment 147474 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12966009 New failing tests: inspector/debugger/step-through-event-listeners.html inspector/debugger/event-listener-breakpoints.html
WebKit Review Bot
Comment 16 2012-06-14 05:28:33 PDT
Created attachment 147562 [details] Archive of layout-test-results from ec2-cr-linux-01 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Peter Wang
Comment 17 2012-06-14 18:53:11 PDT
(In reply to comment #14) > I've filed https://bugs.webkit.org/show_bug.cgi?id=89056 to record the problem of "xhr-breakpoints.html". Now only this case is left in Skipped of Qt Browser. > And I'm sure this case can pass the test if we walk around the timeout problem. > Csaba and Pavel, do you think the result is acceptable? (In reply to comment #16) > Created an attachment (id=147562) [details] > Archive of layout-test-results from ec2-cr-linux-01 > > The attached test failures were seen while running run-webkit-tests on the chromium-ews. > Bot: ec2-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick Sorry, I cannot find anything related with my test cases? :(
Note You need to log in before you can comment on or make changes to this bug.