- webkit-efl - lists.webkit.org

Do we really need a global history implementation?
by Raphael Kubo da Costa 16 May '12

16 May '12

Hey there. Mikhail has been working on a few patches [1][2][3][4] adding support for a global history to the port. Most of the code in those patches looks fine, but before commenting on the bugs I would like to discuss whether we actually need a global history implementation at all. Only the Apple ports (mac and win) really use the global history callbacks in WebCoreSupport (Qt implements some bits just to pass the layout tests [5]). For us, it means we need to add a few more data structures and emit a few very specialized signals I doubt users are going to need (such as "perform,client,redirect" or "navigate,with,data"). The only benefit I see so far is that a few more tests will be unskipped, but then if we choose we do not want to support this feature we can just move the skipped tests to the "Tests which are expected to fail" section. Does anyone have a different opinion or has anyone needed a global history implementation when using the port? [1] https://bugs.webkit.org/show_bug.cgi?id=86343 [2] https://bugs.webkit.org/show_bug.cgi?id=82579 [3] https://bugs.webkit.org/show_bug.cgi?id=86370 [4] https://bugs.webkit.org/show_bug.cgi?id=82724 [5] http://trac.webkit.org/browser/trunk/Source/WebKit/qt/WebCoreSupport/FrameL…

3 3

Buildbot Green
by Dominik Röttsches 10 May '12

10 May '12

Dear WebKit EFL folks, Thanks to a great team effort, the WebKit EFL Linux 64bit Debug Buildbot is now green and http://wkb.ug/85601 - [EFL] Green Tree task force was marked RESOLVED FIXED, see also [1]. A big thanks to everyone involved who contributed patches, investigated and gardened test cases, reviewed and committed our patches. This is a great milestone on the way of improving the stability and robustness of the EFL port. It gives us the powerful opportunity to use run-webkit-tests locally and expect close to zero failures when testing patches during development. That's why we'd like to encourage everybody to make use of this tool and check patches for regressions before landing. If you have any questions regarding how to get the same results on your machine as on the bot, please feel free to post to this list and we'll try to resolve such issues. From now, we'll keep a close eye on the bot and we'll set up a gardening schedule in order to keep the bot green in the future. Dominik [1] http://goo.gl/ei1gL ;-)

1 0

glib integration and timers precision
by Thiago Marcos P. Santos 09 May '12

09 May '12

Hi Webkit EFL, We have the ecore main loop pumping glib main loop because of libsoup (mainly) on EWK. I have the feeling that we are having more issues with timeouts/timers/delays than other platforms and it might be somehow related (noticed that when fixing some flaky tests). - Does anyone knows the performance impact of this pumping? We are also using the default ecore timer precision which has a small delay. - Is it a good idea to set it to maximum precision (maybe on DRT only)? Cheers,

1 0

Ubuntu 12.04 on Buildbots?
by Dominik Röttsches 05 May '12

05 May '12

Hi Gyuyoung, you mentioned you were planning to upgrade the Release buildbot to Ubuntu 11.x Now that Ubuntu 12.04 got released - that doesn't seem like an up-to-date idea anymore. How about skipping 11.x and upgrade it to 12.04 directly? Then we could do the same with the Debug buildbot and they would be in sync. What do you think? Dominik -- Dominik Röttsches<dominik.rottsches(a)linux.intel.com>

4 4

Release Bot needs a clean build
by Thiago Marcos P. Santos 27 Apr '12

27 Apr '12

Hi guys, Some tests are failing because a build flag is disabled: ENABLE_DRAG_SUPPORT = OFF We had the same problem on the Debug bot. It can be solved by triggering a clean build or by removing CMakeCache.txt. Cheers,

1 0

Few change suggestions in EFL port
by Tomasz Morawski 23 Apr '12

23 Apr '12

Hello, I would like to propose changes related to some aspect of c programming style used in our EFL WebKit port that could make our port more consistent with other WebKit port like Gtk and Qt. Currently, we are trying to follow some EFL libraries programming style that hides structures declaration inside cpp files and use one single private header file. I know that it works inside EFL's libraries but the our WebKit port it is not and it will never be typical EFL's library. I think current solution doesn't work well for example: overgrown files like ewk_view.h/cpp, ewk_frame.h/cpp files and ewk_private.h file, a lot of unneeded public API that is used only by internal WebKit tools (like DRT) but it will be never uses by final user. Moreover, there is a lot of programmers that would like to cleanup this mess and have more readable port architecture. I suggest to: 1) Allow to define ewk_*_private.h files when it is needed and use it internally like Gtk, Qt port does. It is possible to use ewk_*_private.h files by internal test application: the DRT tree or other tests. 2) Move structures form cpp files to corresponding private header files (approach like Gtk and typical for c programming) 3) Move private function from ewk_private.h to corresponding private header files and delete this file (more objective) After that: 4) Simplify and remove some code that will be no need after this refactor (some code is only for handling private by force structures). 5) Reduce size of ewk_frame.h/cpp and ewk_view.h/cpp files by moving some declaration to ewk_*_private.h 6) We will follow typical for WebKit's port architecture like qt, gtk port do (they use private file widely). Due to that the port code organization will be more familiar for gtk reviewers and newcomer programmer. What you think about this? Best Regards, Tomasz Morawski

4 8

Pulseaudio Issues on Debug Buildbot solved
by Dominik Röttsches 20 Apr '12

20 Apr '12

Hi Gyuoung, I just resolved some pulseaudios issues on our buildbot that were causing a number of media tests to timeout, for example: http/tests/media/video-throttled-load-metadata.html I documented the solution here: https://trac.webkit.org/wiki/BuildBot#TimeoutsonGStreamerrelatedtestsonLinux Maybe this is needed on the release buildbot as well. Regards, Dominik -- Dominik Röttsches<dominik.rottsches(a)linux.intel.com>

2 1

test_expectations.txt vs Skipped for EFL - Was Re: [webkit-dev] handling failing tests ...
by Dominik Röttsches 15 Apr '12

15 Apr '12

Hi EFL folks, On 04/10/2012 12:42 AM, Dirk Pranke wrote: > Recently I've noticed more people making changes and adding test > failure suppressions to various ports' test_expectations.txt files. > This is great! > > However, I don't think we have an agreement over what the "best > practices" are here, so I thought I'd list out what I thought they > were, and others can comment / correct me as necessary: > > 1) Don't mix test_expectations.txt files and Skipped files. This is > really confusing to everyone involved ... your port should use one or > the other where possible. (*) > > (*) I have an outstanding to-do to modify new-run-webkit-tests to a > better way of tracking expectations to merge the inheritance/cascade > aspects of Skipped files with the flexibility in types of failures > that you get from expectations. Eventually we should have a mechanism > that replaces both, but for now, we don't. See > https://bugs.webkit.org/show_bug.cgi?id=83508 . 1) On webkit-dev Dirk recommends using only one approach per port. I'd like to discuss which approach of the two we're going to use. EFL port currently has both, test_expectations.txt and Skipped. Skipped is more frequently updated and works as our reference. But recently, I admit I moved some cases to test_expectations.txt after rebaselining. In EFL, test_expectations.txt has ~20 commits, Skipped has ~108. So Skipped seems to be more frequently used. I see two commits from Gyuyoung indicating that he'd like to move forward using test_expectations.txt, and there has been a discussion in https://bugs.webkit.org/show_bug.cgi?id=75940 Which approach should we take? Personally, I like the expressiveness of test_expectations.txt for differentiating between DEBUG and RELEASE and also associating tests with bugs very clearly, so I would vote in favour of moving everything from Skipped to test_expectations.txt. 2) As a next step, I'd like to mark all currently failing cases on the buildbots to be skipped. The failure retries are single-process and are taking too much time without any additional value. No doubt that we need to analyse and fix them, but the buildbot doesn't need to waste time and cycles on them for each build. Your feedback is welcome. Regards, Dominik -- Dominik Röttsches<dominik.rottsches(a)linux.intel.com> Linux Software Engineer Intel Finland Oy - BIC 0357606-4 - PL 281, 00181 Helsinki

2 1

Re: [webkit-efl] test_expectations.txt vs Skipped for EFL - Was Re: [webkit-dev] handling failing tests ...
by Dominik Röttsches 13 Apr '12

13 Apr '12

On 04/13/2012 05:29 PM, Gyuyoung Kim wrote: > Hello, > > >> EFL port currently has both, test_expectations.txt and Skipped. > >> Skipped is more frequently updated and works as our reference. But > recently, I admit I moved some cases to test_expectations.txt after > >> rebaselining. > > In my humble opinion, we need to go text_expectation.txt. As far as I > know, text_expectation.txt is to deal with unsupported test cases. > However, as you know, it is not easy to move from Skipped file to > text_expectation.txt due to the many unsupported test cases in Skipped > file. If we can use both Skipped file and test_expectation.txt for a > while, it is easy to move after reducing Skipped file as much as we can. That sounds good to me. Alright - for now, I am going to move the permanent failures we see on the bots into "SKIP" lines in test expectations. Regards, Dominik -- Dominik Röttsches<dominik.rottsches(a)linux.intel.com>

1 0

EFL Linux Debug Buildbot online
by Dominik Röttsches 13 Apr '12

13 Apr '12

Hi, I am happy to inform you that the EFL Debug Buildbot got online tonight (EEST). By now it has completed its maiden build "0" :-) http://build.webkit.org/builders/EFL%20Linux%20Debug There's some tuning to do in the next few days, but it already gives us useful information. Let's continue to work on getting the bots green. Regards, Dominik -- Dominik Röttsches<dominik.rottsches(a)linux.intel.com> Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4

4 5