r119962 reenabled tests after implementing breaking from native callback, but tests are still failing.
Is there a concept of V8 and JSC specific tests?
(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.
Skipped on Qt again until proper fix to paint the bot green - http://trac.webkit.org/changeset/119976
Working on it.
Created attachment 147061 [details] Patch
(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.
(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
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.
(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.
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"?
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?
(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.
Created attachment 147474 [details] Patch
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?
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
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
(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? :(