- webkit-efl - lists.webkit.org

FW: window.showModalDialog()
by Sun, Xun 07 Jan '13

07 Jan '13

Hi folks, I posted this query on the product-dev(a)lists.tizen.org list but got no comments so far. Could someone please comment if window.showModalDialog() would be a welcomed feature for Webkit-efl? (Webkit2 of course) And what would it take? It looks like something needs to be done in the UIClientEfl, but I failed to find the place for real implementation. Thanks & Regards Xun Sun -----Original Message----- From: Sun, Xun Sent: Tuesday, December 25, 2012 9:19 AM To: product-dev(a)lists.tizen.org Subject: window.showModalDialog() Hi, In the small application we are developing, we want to show a modal dialog to the user and get response back for processing. It turns out window.showModalDialog() is not working - no dialog is popped up. Googling around I found this bug that might be related - https://bugs.webkit.org/show_bug.cgi?id=84589 So what would it take to implement this function into webkit-efl? Is this planed? Thanks & Regards Xun Sun

3 4

Accessibility related crashes on the bots
by Krzysztof Czech 20 Dec '12

20 Dec '12

Hi WebKit-EFL, I created a bug https://bugs.webkit.org/show_bug.cgi?id=105504 so that we can track all the issues regarding the Accessibility. Br, > Send webkit-efl mailing list submissions to > webkit-efl(a)lists.webkit.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.webkit.org/mailman/listinfo/webkit-efl > or, via email, send a message with subject or body 'help' to > webkit-efl-request(a)lists.webkit.org > > You can reach the person managing the list at > webkit-efl-owner(a)lists.webkit.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of webkit-efl digest..." > > > Today's Topics: > > 1. Re: Accessibility related crashes on the bots (Pi?eiro) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 19 Dec 2012 20:54:34 +0100 > From: Pi?eiro <apinheiro(a)igalia.com> > To: webkit-efl(a)lists.webkit.org > Subject: Re: [webkit-efl] Accessibility related crashes on the bots > Message-ID: <50D21B7A.60908(a)igalia.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 12/18/2012 05:47 PM, Thiago Marcos P. Santos wrote: >> Hi WebKit-EFL, > Hi, I didn't answer before because I'm not directly working on the efl > port, but as nobody else stepped here, I will add a comment here. > >> We have been experiencing some flaky crashes on the bots. Help from >> people with working on this area is very appreciated. > In order to calm down people: there are a lot of people working on > improving the accessibity of EFL (ej: [1][2][3][4]), so for sure that > this issue that you detected is not being forgotten, and that this bug > is just part of the big amount of work done during the last weeks and to > be done on following weeks. > >> The stack trace is always as follows: > Having said so, probably this problem would be better managed with a bug > report instead that the mailing list. > > Thanks for the feedback. > > Best regards > [1] https://bugs.webkit.org/show_bug.cgi?id=104926 > [2] https://bugs.webkit.org/show_bug.cgi?id=104926 > [3] https://bugs.webkit.org/show_bug.cgi?id=104926 > [4] https://bugs.webkit.org/show_bug.cgi?id=105007 >

1 0

Accessibility related crashes on the bots
by Thiago Marcos P. Santos 19 Dec '12

19 Dec '12

Hi WebKit-EFL, We have been experiencing some flaky crashes on the bots. Help from people with working on this area is very appreciated. The stack trace is always as follows: crash log for WebProcess (pid <unknown>): STDOUT: <empty> STDERR: 1 0x7f1f6a3eb318 STDERR: 2 0x7f1f6ac5e4a0 STDERR: 3 0x7f1f69318979 WebCore::AccessibilityRenderObject::remoteSVGRootElement() const STDERR: 4 0x7f1f69318a79 WebCore::AccessibilityRenderObject::detachRemoteSVGRoot() STDERR: 5 0x7f1f69318aa1 WebCore::AccessibilityRenderObject::detach() STDERR: 6 0x7f1f692f621a WebCore::AXObjectCache::~AXObjectCache() STDERR: 7 0x7f1f69478bb5 WebCore::Document::clearAXObjectCache() STDERR: 8 0x7f1f69486940 WebCore::Document::detach() STDERR: 9 0x7f1f698f121c WebCore::Frame::setView(WTF::PassRefPtr<WebCore::FrameView>) STDERR: 10 0x7f1f698f355b WebCore::Frame::createView(WebCore::IntSize const&, WebCore::Color const&, bool, WebCore::IntSize const&, WebCore::IntRect const&, bool, WebCore::ScrollbarMode, bool, WebCore::ScrollbarMode, bool) STDERR: 11 0x7f1f6b491e3d WebKit::WebFrameLoaderClient::transitionToCommittedForNewPage() STDERR: 12 0x7f1f69826776 WebCore::FrameLoader::transitionToCommitted(WTF::PassRefPtr<WebCore::CachedPage>) STDERR: 13 0x7f1f69828da7 WebCore::FrameLoader::commitProvisionalLoad() STDERR: 14 0x7f1f69809219 WebCore::DocumentLoader::finishedLoading() STDERR: 15 0x7f1f6980dad2 WebCore::DocumentLoader::maybeLoadEmpty() STDERR: 16 0x7f1f6980dcb8 WebCore::DocumentLoader::startLoadingMainResource() STDERR: 17 0x7f1f69829720 WebCore::FrameLoader::continueLoadAfterNavigationPolicy(WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>, bool) STDERR: 18 0x7f1f6982975d WebCore::FrameLoader::callContinueLoadAfterNavigationPolicy(void*, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>, bool) STDERR: 19 0x7f1f69841428 WebCore::PolicyCallback::call(bool) STDERR: 20 0x7f1f698461d2 WebCore::PolicyChecker::continueAfterNavigationPolicy(WebCore::PolicyAction) STDERR: 21 0x7f1f6b499a24 WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction(void (WebCore::PolicyChecker::*)(WebCore::PolicyAction), WebCore::NavigationAction const&, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>) STDERR: 22 0x7f1f698481d0 WebCore::PolicyChecker::checkNavigationPolicy(WebCore::ResourceRequest const&, WebCore::DocumentLoader*, WTF::PassRefPtr<WebCore::FormState>, void (*)(void*, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>, bool), void*) STDERR: 23 0x7f1f69829c29 WebCore::FrameLoader::loadWithDocumentLoader(WebCore::DocumentLoader*, WebCore::FrameLoadType, WTF::PassRefPtr<WebCore::FormState>) STDERR: 24 0x7f1f6982a555 WebCore::FrameLoader::load(WebCore::DocumentLoader*) STDERR: 25 0x7f1f6982df0b WebCore::FrameLoader::load(WebCore::FrameLoadRequest const&) STDERR: 26 0x7f1f6b4b6cb6 WebKit::WebPage::loadURLRequest(WebCore::ResourceRequest const&, WebKit::SandboxExtension::Handle const&) STDERR: 27 0x7f1f6b4b717b WebKit::WebPage::loadURL(WTF::String const&, WebKit::SandboxExtension::Handle const&) STDERR: 28 0x7f1f6b52f120 WebKit::WebPage::didReceiveWebPageMessage(CoreIPC::Connection*, CoreIPC::MessageID, CoreIPC::MessageDecoder&) STDERR: 29 0x7f1f6b3569c8 CoreIPC::MessageReceiverMap::dispatchMessage(CoreIPC::Connection*, CoreIPC::MessageID, CoreIPC::MessageDecoder&) STDERR: 30 0x7f1f6b43b79c WebKit::WebProcess::didReceiveMessage(CoreIPC::Connection*, CoreIPC::MessageID, CoreIPC::MessageDecoder&) STDERR: 31 0x7f1f6b353166 CoreIPC::Connection::dispatchMessage(CoreIPC::Connection::Message<CoreIPC::MessageDecoder>&) Br,

2 1

LayoutTest percentage results problem
by Mateusz Leszko 14 Dec '12

14 Dec '12

Hello. I am struggling with LayoutTests "--debug-rwt-logging" parameter. I need to take percentage of passing tests. It's suppose to be problem with this. For example when running LayoutTests/editing/input/ test I got result: Found 34 tests; running 29, skipping 5. => Results: 34/34 tests passed (100.0%) => Tests to be fixed (5): Previously, about week ago I got problem like => Results: 95/93 tests passed (102.15%) For LayoutTests/editing/style/ But now it's different problem. Regards Mateusz Leszko

3 3

How to run layout tests with X server 1.13.0
by Raphael Kubo da Costa 21 Nov '12

21 Nov '12

Still on the theme of b0rkedness related to Accelerated Compositing... tl;dr version: If you are using X server 1.13.0 (which means you are on Ubuntu 12.10, Arch Linux, Fedora 18 etc) and want to run layout tests, either: o Pass `--no-tiled-backing-store' to build-webkit. o Build a copy of the X server somewhere with commits 5f5bbbe543f65c48ecbb5cce80116a86ca3fbe86 and aad428b8e21c77397c623b78706eb64b1fea77c9 reverted and use its version of Xvfb. Full version: There is a regression in the 1.13.0 release (which has not been fixed yet) of the X server that prevents Xvfb from loading the GLX extension needed by the `opengl_x11' Evas backend used when WTF_USE_TILED_BACKING_STORE (and thus Accelerated Compositing) is enabled. I'm not sure if the folks are working on a WebKit patch that at least makes things degrade gracefully instead of crashing [1] when the `opengl_x11' backend cannot be loaded, but that is sort of orthogonal to the issue in X itself. [1] https://gist.github.com/61bf7390f76fddb5c97b I have reported the issue upstream [2] and will try to send a patch fixing the problem to the xorg-devel list as soon as possible. [2] http://lists.freedesktop.org/archives/xorg-devel/2012-November/034411.html Meanwhile, if you are affected you either need to disable the use of tiled backing store altogether or build your own copy of Xvfb with those commits I mentioned disabled. -- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki

1 1

Disable Tiled Backing Store
by Gyuyoung Kim 21 Nov '12

21 Nov '12

Hi EFL folks, API test has been failed we enabled the tiled backing store by default. http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release/builds/7415 http://trac.webkit.org/changeset/133859 Beside it looks there are layout test problems when we use tiled backing store in some HW yet. So, I roll it out for now. When you fix these problems, please enable it again. Gyuyoung. -- Gyuyoung Kim SW Engineer, WebKit EFL Email : gyuyoung.kim(a)webkit.org Phone : +82 10 9530 0209

2 2

Tip of the day: building WebKit faster
by Thiago Marcos P. Santos 21 Nov '12

21 Nov '12

I often see people building WebKit EFL using the build-webkit even when they change a harmless line of code in a .cpp file. The fastest way of building in this case is by invoking "make" directly from the ./WebKitBuild/[Release|Debug]/ folder. Example: If you changed something on WebCore and is using the MiniBrowser for testing, you have 4 options: 1. The coward option: will build everything, somehow equivalent to build-webkit but probably faster. $ make -jN 2. The safe option: will build all the dependencies up to the binary. $ make MiniBrowser -jN 3. The cowboy option: in case you haven't changed the WebCore ABI, it will build all the deps up to WebCore. $ make webcore_efl -jN 4. Gangnam Style: will build and link just WebCore, fastest way possible. Developer is 100% sure that no ABI breakage happened. No dependency lookup. $ make webcore_efl/fast -jN N = Some people use the number of cores, others twice as much. You know what is best. Dedicated to Raphael Kubo which taught me the /fast one. Cheers,

3 2

ewebkit DOM
by HariHara Sudhan 20 Nov '12

20 Nov '12

Is there any method i can access DOM or, find out some value of a hidden text box elements values, from ewebkit. -- Regards HariHaraSudhan

3 3

Re: [webkit-efl] How to run layout tests with ATI and NVidia drivers
by Byung-Woo Lee 14 Nov '12

14 Nov '12

Thank you for sharing this! For the easy use, how about adding layout test options for this? I made a bug to add layout test options(--mesa-3d, --no-mesa-3d) to use mesa 3D library. https://bugs.webkit.org/show_bug.cgi?id=102174 When '--mesa-3d' is set, LD_LIBRARY_PATH will be set as below. LD_LIBRARY_PATH=/usr/lib/`uname -m`-linux-gnu/mesa/ --no-mesa-3d is the default action that does not set LD_LIBRARY_PATH. Thanks & Regards, Byungwoo. ------- Original Message ------- Sender : 한강일<kangil.han(a)samsung.com> S5(책임)/책임/차세대S/W개발그룹(무선)/삼성전자 Date : 2012-11-14 13:14 (GMT+09:00) Title : Re: [webkit-efl] How to run layout tests with ATI and NVidia drivers Thanks for this information! You finally found it. ;-) This works both on my Ubuntu 12.04 32/64 bit machines. :-) -----Original Message----- From: Thiago Marcos P. Santos [mailto:tmpsantos@gmail.com] Sent: Wednesday, November 14, 2012 4:04 AM To: webkit-efl(a)lists.webkit.org Cc: kangil.han(a)samsung.com Subject: How to run layout tests with ATI and NVidia drivers tl;dr version: LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/mesa/ ./Tools/Scripts/run-webkit-tests --efl Full version: Some developers have been experiencing crashes when running layout tests on computers equipped with ATI and nVidia cards. The crash happens when evas tries to compile a shader: STDOUT: STDERR: ERR<4668>:evas-gl_common evas_gl_shader.c:1039 _evas_gl_common_shader_program_source_init() Abort compile of shader vert (rect): #ifdef GL_ES STDERR: precision highp float; ... Full backtrace here -> http://pastie.org/pastes/5371448/text The interesting thing is that we use Xvfb + LLVMPipe (software GL in a short) when running the tests, so the GPU should be irrelevant: but only in theory. I noticed that when running glxinfo inside the XVfb, I was getting the client glx vendor string ATI. Kangil also hinted that on his computer, after removing the nVidia drivers, he had no crashes anymore (but X was falling back to vesa). $ DISPLAY=:555 glxinfo |grep 'client glx vendor' client glx vendor string: ATI Ubuntu links with the libGL provided by the graphics card vendor by default: $ ldd /usr/bin/glxinfo |grep libGL libGL.so.1 => /usr/lib/fglrx/libGL.so.1 (0xb7646000) For running the layout tests using LLVMPipe, we need to use the mesa libGL. In order to do that, we can play some tricks with LD_LIBRARY_PATH: $ LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/mesa/ ./Tools/Scripts/run-webkit-tests --efl This is only needed by the layout tests script (because it spawns a Xvfb). MiniBrowser should run normally because it will connect to your standard Xorg instance with GPU-based GL. Cheers, _______________________________________________ webkit-efl mailing list webkit-efl(a)lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-efl

1 0

How to run layout tests with ATI and NVidia drivers
by Thiago Marcos P. Santos 14 Nov '12

14 Nov '12

tl;dr version: LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/mesa/ ./Tools/Scripts/run-webkit-tests --efl Full version: Some developers have been experiencing crashes when running layout tests on computers equipped with ATI and nVidia cards. The crash happens when evas tries to compile a shader: STDOUT: <empty> STDERR: ERR<4668>:evas-gl_common evas_gl_shader.c:1039 _evas_gl_common_shader_program_source_init() Abort compile of shader vert (rect): #ifdef GL_ES STDERR: precision highp float; ... Full backtrace here -> http://pastie.org/pastes/5371448/text The interesting thing is that we use Xvfb + LLVMPipe (software GL in a short) when running the tests, so the GPU should be irrelevant: but only in theory. I noticed that when running glxinfo inside the XVfb, I was getting the client glx vendor string ATI. Kangil also hinted that on his computer, after removing the nVidia drivers, he had no crashes anymore (but X was falling back to vesa). $ DISPLAY=:555 glxinfo |grep 'client glx vendor' client glx vendor string: ATI Ubuntu links with the libGL provided by the graphics card vendor by default: $ ldd /usr/bin/glxinfo |grep libGL libGL.so.1 => /usr/lib/fglrx/libGL.so.1 (0xb7646000) For running the layout tests using LLVMPipe, we need to use the mesa libGL. In order to do that, we can play some tricks with LD_LIBRARY_PATH: $ LD_LIBRARY_PATH=/usr/lib/i386-linux-gnu/mesa/ ./Tools/Scripts/run-webkit-tests --efl This is only needed by the layout tests script (because it spawns a Xvfb). MiniBrowser should run normally because it will connect to your standard Xorg instance with GPU-based GL. Cheers,

2 1