Re: [webkit-dev] Announcing WebKit for Wayland
On Tue, Dec 9, 2014 at 1:19 PM, Benjamin Poulain benja...@webkit.org wrote: Hi Žan, Thanks for announcing this project here. Can you explain a bit why you decided to use the UIProcess directly inside the compositor? I am a bit concerned about the security of this model because the UIProcess becomes an attack vector for the compositor. Sharing the memory space with the compositor would prevent aggressive sandboxing. The main idea behind this design is to remove the intermediate purpose of the UIProcess when it comes to updating the display server with rendering results from the WebProcess, handling input events (originating from the compositor) in the WebProcess, etc. For such tasks UIProcess did nothing but relay them forward, and not necessarily efficiently. This change in architecture goes hand-in-hand with the idea of removing the dependency on any toolkit. Most of these are nowadays exclusively tailored to run best under some specific desktop environment, relying on additional protocols for window management that bring in unnecessary overhead. And since the toolkit is utilized in the UIProcess, it requires that the UIProcess is run under a compositor, and not in parallel to it. Removing the toolkit also gives us a large amount of leeway in adjusting the input processing, display updates and other things to our needs. But even without the toolkit the whole setup could still easily run under the more traditional environments, as we're recommending for developer setups where the Weston compositor with the WebProcess client runs under the parent X or Wayland display. The current architecture does inhibit sandboxing, and the best alternative solution we can offer at the moment is randomizing the address space layout. We're still open to other possibilities, including perhaps again moving the UIProcess into a separate process but keeping the current design of the WebProcess acting as a direct client of the Wayland compositor. The port has been in the works for four months now, and while we might have not yet approached security seriously, we're definitely not keen on keeping the issues unaddressed. Cheers, Zan Great Wayland support seems like an important target for WebKit on Linux. Do you know what are the plans for GTK and EFL? Benjamin On 12/9/14 7:44 AM, Žan Doberšek wrote: Hi, now with proper formatting, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards, Zan Dobersek On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com mailto:zandober...@gmail.com wrote: Hi, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented
Re: [webkit-dev] Announcing WebKit for Wayland
On Tue, Dec 9, 2014 at 5:52 PM, Gyuyoung Kim gyuyoung@webkit.org wrote: Hello, Do you know what are the plans for GTK and EFL? As far as I know, EFL community has tried to support wayland. Thus some folks of WebKit EFL port seem to plan to support the wayland based of EFL support when it is ready. Basically same goes for the GTK+ port -- we mainly rely on the toolkit to properly support the Wayland protocol. Despite that we must deploy a few custom solutions for specific problems. For instance, in order to efficiently transfer the composited results from the WebProcess to the Wayland compositor we are planning to use a nested Wayland compositor in the UIProcess to relay that data to GTK+. First implementations of this approach ended up blitting the rendered data onto the Cairo surface of the relevant GtkWidget. To make things worse, the surface was using shared memory, and had its data invalidated completely whenever the GtkWidget had a redraw queued. This meant that Gyuyoung. On Wednesday, December 10, 2014, Benjamin Poulain benja...@webkit.org wrote: Hi Žan, Thanks for announcing this project here. Can you explain a bit why you decided to use the UIProcess directly inside the compositor? I am a bit concerned about the security of this model because the UIProcess becomes an attack vector for the compositor. Sharing the memory space with the compositor would prevent aggressive sandboxing. Great Wayland support seems like an important target for WebKit on Linux. Do you know what are the plans for GTK and EFL? Benjamin On 12/9/14 7:44 AM, Žan Doberšek wrote: Hi, now with proper formatting, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards, Zan Dobersek On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com mailto:zandober...@gmail.com wrote: Hi, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web
Re: [webkit-dev] Announcing WebKit for Wayland
On Wed, Dec 10, 2014 at 9:46 AM, Žan Doberšek zandober...@gmail.com wrote: On Tue, Dec 9, 2014 at 5:52 PM, Gyuyoung Kim gyuyoung@webkit.org wrote: Hello, Do you know what are the plans for GTK and EFL? As far as I know, EFL community has tried to support wayland. Thus some folks of WebKit EFL port seem to plan to support the wayland based of EFL support when it is ready. Basically same goes for the GTK+ port -- we mainly rely on the toolkit to properly support the Wayland protocol. Despite that we must deploy a few custom solutions for specific problems. For instance, in order to efficiently transfer the composited results from the WebProcess to the Wayland compositor we are planning to use a nested Wayland compositor in the UIProcess to relay that data to GTK+. First implementations of this approach ended up blitting the rendered data onto the Cairo surface of the relevant GtkWidget. To make things worse, the surface was using shared memory, and had its data invalidated completely whenever the GtkWidget had a redraw queued. This meant that ... a whole lot of data was being sent to the parent compositor for each update of the widget, which obviously caused problems on weaker embedded systems running in 1080p resolution. Luckily in the last few months GTK+ finally received support for drawing OpenGL content in GtkWidgets, so the final implementation will be much more efficient. Cheers, Zan Gyuyoung. On Wednesday, December 10, 2014, Benjamin Poulain benja...@webkit.org wrote: Hi Žan, Thanks for announcing this project here. Can you explain a bit why you decided to use the UIProcess directly inside the compositor? I am a bit concerned about the security of this model because the UIProcess becomes an attack vector for the compositor. Sharing the memory space with the compositor would prevent aggressive sandboxing. Great Wayland support seems like an important target for WebKit on Linux. Do you know what are the plans for GTK and EFL? Benjamin On 12/9/14 7:44 AM, Žan Doberšek wrote: Hi, now with proper formatting, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards, Zan Dobersek On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com mailto:zandober...@gmail.com wrote: Hi, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware
[webkit-dev] Announcing WebKit for Wayland
Hi, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards,Zan Dobersek ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcing WebKit for Wayland
Hi, now with proper formatting, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards, Zan Dobersek On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com wrote: Hi, Igalia is happy to announce the Wayland port of WebKit. This port avoids using traditional GUI toolkits in favor of directly operating with the Wayland display protocol. Leveraging the WebKit2 multi-process architecture, the UIProcess is implemented as a shared library and loaded by the Wayland compositor, enabling the WebProcess to act as a direct client of the compositor while still being controlled by the UIProcess. EGL, the Wayland EGL platform, and OpenGL ES are used for hardware-accelerated compositing of the rendered Web content. GLib, Libsoup and Cairo are used under the hood. The port serves as a good base for building systems and environments that are mostly or completely relying on the Web platform technologies for building the desired interface. Overall the port is still in its early days, with some basic functionality (e.g. functional keyboard and mouse input support) and many other Web platform features still not supported. But with Wayland EGL support constantly growing in graphics drivers for different GPUs, it can already be tested on devices like the Raspberry Pi or the Jetson TK1 development board. In terms of supported Wayland compositors, for the moment we only support Weston (the reference Wayland compositor implementation), which is also used for development purposes. It's also used for running the layout tests by again pushing WebKitTestRunner functionality into a shared library, though all that is still in very early stages. The code is available on GitHub. There are also short instructions for building the dependencies and the port, and how to run it. https://github.com/WebKitForWayland/webkit There's also additional repositories there (for Cairo, Weston), containing changes that haven't yet been pushed upstream. In the following days we'll also be providing Buildroot configurations that can be used for cross-compiling the whole software stack for the supported hardware. We look forward to continuing evolving this work, enabling further features and improving performance on the software side and adding support for additional devices. As with all open-source projects, contributions are welcome. Regards,Zan Dobersek ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] GTK build of FTL JIT
The GTK port does not support building and running with FTL at this point, though it is planned to at least experiment with it. Cheers, Zan On Wed, Apr 16, 2014 at 8:38 AM, Filip Pizlo fpi...@apple.com wrote: First of all, we only support the FTL on Darwin - the Linux support is highly experimental and I don't know if the people working on it have done anything in a long time. This is true both of the code on the WebKit side, which was originally implemented on Darwin with Darwin-specific assumptions, and also of the LLVM side, which also was originally Darwin-specific. None of that code should be Darwin-only forever but the Linux bits have to be written by somebody. That said, you could probably get the ball rolling on a proper port by opening a bug on bugs.webkit.org and posting the crash you are seeing. You definitely don't need a testing branch of LLVM. Either trunk works or nothing works. -Fil On Apr 16, 2014, at 7:46 AM, Vahag Vardanyan v...@ispras.ru wrote: I have used the latest version from llvm.org and I am getting the error desribed before. Can you advise possible solutions of this problem ? May be I need to use one of the testing branches of LLVM compiler ? On Wed, Apr 16, 2014 at 6:21 PM, Filip Pizlo fpi...@apple.com wrote: You can check out LLVM from their svn repository. See llvm.org. -Fil On Apr 16, 2014, at 2:08 AM, Vahag Vardanyan v...@ispras.ru wrote: Hi, I've been trying to enable FTL JIT for gtk build under Linux. I've managed to build JSC with FTL JIT enabled using LLVM trunk, however jsc fails run time at phase FTLCompile during the call of llvm-GetPointerToGlobal function. I realize that probably the problem is in LLVM version, if so, can you please provide proper source of LLVM, or give an advise how to fix fails and run FTL on Linux. Thanks in advance. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] EFL and GTK on Darwin
Hi. On Mon, Feb 10, 2014 at 6:30 PM, Dan Bernstein m...@apple.com wrote: Hi everyone, and especially EFL and GTK contributors! In preparation for changing PLATFORM(MAC) to be false when building for iOS, I have been reviewing usage of PLATFORM(MAC) throughout our codebase. Some of these uses are really about targeting the Darwin OS. However, I could not simply replace PLATFORM(MAC) with OS(DARWIN), because the latter also encompasses the EFL and GTK platforms when building for Darwin (which the former does not). Therefore, thus far I have replaced relevant instances of PLATFORM(MAC) with (OS(DARWIN) !PLATFORM(EFL) !PLATFORM(GTK)). Just to be clear, this is about code that's not appropriate to guard with PLATFORM(COCOA)? This is ugly and seems like a waste of time, so I was wondering: 1. Is there a configuration of the EFL port that actually builds for Darwin? 2. Is there a configuration of the GTK port that actually builds for Darwin? Yes, this configuration is supported by the GTK port through the MacPorts project. Jeremy Huddleston regularly upstreams modifications to properly support building the GTK port on Darwin. 3. If such configuration(s) exist, would it be OK for them to use Darwin when building for Darwin? This could be possible, but it depends really on the code in question. Jeremy would probably be the best candidate to exactly tell you whether the new code is viable to use for the GTK port on Darwin. If the answer to 1 and 2 is no, or if the answer to 3 is yes, then I will simply use OS(DARWIN) to replace PLATFORM(MAC) where that is the intent, and, depending on the answers to 1 and 2, update the EFL and GTK build systems to include the Darwin-based implementations where needed. Thanks! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Merging back the jsCStack branch
There are still outstanding and unresolved issues on the GTK and EFL ports that are reported in bug #12. https://bugs.webkit.org/show_bug.cgi?id=12 The Apple Win7 builder is also having problems after the merge. On Wed, Jan 29, 2014 at 11:18 AM, Michael Saboff msab...@apple.com wrote: The branch has been merged back to trunk in change set r163027: http://trac.webkit.org/changeset/163027. - Michael On Jan 27, 2014, at 6:00 PM, mhahnenb...@apple.com wrote: Hello WebKitters, The JavaScriptCore team is planning on merging back our temporary development branch (at http://trac.webkit.org/browser/branches/jsCStack) that we've been working on for the past couple of months. The primary features that this branch will bring to trunk are: (1) JavaScript code in JavaScriptCore now runs exclusively on the C stack. Previously JavaScriptCore made use of the C stack only for calls into its C++ runtime, and it used a separate custom stack data structure for execution of compiled JavaScript code. Now it's all C stack all the time. This work was primarily in support of the next feature... (2) More FTL goodness. The FTL already existed in trunk, but the most recent bleeding edge work has been done on the branch since that work depended on the other C-stack-related work. It will still be behind #ifdefs, and it won't be compiled by default. The plan is to merge back early tomorrow morning so that if there are any major issues they won't cause any significant impact. I'll be available via IRC and email to help with any problems. Let me know if this plan doesn't work for you. Thanks! -Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Make accelerated compositing mandatory
The GTK port also disables accelerated compositing at build-time when building specifically for the Wayland windowing target. Adding AC support for this configuration is planned, but a stub implementation can be used as well until then. Cheers, Zan On Tue, Jan 28, 2014 at 10:47 AM, Martin Robinson mrobin...@webkit.orgwrote: On Tue, Jan 28, 2014 at 10:33 AM, Anders Carlsson ander...@apple.com wrote: I'm not a layout and rendering person, but I suspect that the burden lies in that part of WebCore. I also don't think building with accelerated compositing means that it has to be enabled at all; WebKitGTK+ on Windows could probably just have a stub implementation of the relevant GraphicsLayer classes. A stub implementation disabled at runtime would be fine for us, I believe. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit, C++11, and Visual Studio 2013
There's a PPA available for Ubuntu 12.04 that provides both GCC 4.7 and 4.8. Is that an option? Cheers, Zan On Mon, Dec 9, 2013 at 11:43 AM, Osztrogonác Csaba o...@inf.u-szeged.huwrote: Hi, is there any plan to use more C++11 featurese not mentioned here? I just ask it, because many of us still use Ubuntu 12.04 LTS with its default compiler - GCC 4.6. (Now EFL and Nix port builds fine.) So my question is if we will need GCC 4.7 or 4.8 in the near future because of using C++11 featurese not supported by older compilers? You can find here the GCC's C++11 support table: http://gcc.gnu.org/projects/cxx0x.html Ossy Anders Carlsson írta: On Dec 6, 2013, at 4:15 PM, Brent Fulgham bfulg...@apple.com mailto: bfulg...@apple.com wrote: Hi Alex, There are a few items missing from VS2012 (see http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx) that we are already using in the Mac-specific source code: 1. Variadic Templates 2. Initializer Lists 3. Explicit conversion operators 4. Deleted functions 5. range-based for loops. - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Range based loops
These types of loops don't appear to be available in MSVC 2010, which AFAIK still needs to be supported. http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx On Fri, Nov 8, 2013 at 12:24 AM, Sergio Villar Senin svil...@igalia.comwrote: As the project steadily moves to C++11 I was wondering whether range based loops are desirable or not. I don't remember any specific discussion about which C++11 features people like to use in the project (I know we're using some of them auto, std::move semantics, rvalues...). BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Anybody living in trunk with INDEXED_DATABASE enabled?
As you've probably already discovered for yourself by now, the GTK and EFL ports enable the feature when building through build-webkit. Thanks for hacking on this. Cheers, Zan On Thu, Sep 19, 2013 at 4:58 PM, Brady Eidson beid...@apple.com wrote: Hey all, Is anybody living in trunk with INDEXED_DATABASE enabled? I’m trying to get a gauge for how disruptive I’ll be able to be while hacking on it. Thanks, ~Brady ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcing new port: Nix
The GTK, Qt and EFL ports were originally mentioned in this thread as the ports that could share much of the POSIX- or GLib-specific code. That's as close as they come to the new Nix port which would also use this code. The three ports are heavily tied to their respective toolkits. They could still theoretically all use the Nix port's mechanisms to display and operate with the Web content inside the toolkit widgets, but this is very unlikely to happen for either of these ports. Cheers, Zan On Sep 10, 2013 11:54 PM, Filip Pizlo fpi...@apple.com wrote: This would be pure win if Qt/Gtk/EFL switched to it - but otherwise it seems like it would add a lot of maintenance burden. Do you also provide the appropriate scaffolding for a Gtk, Qt, or EFL user to use Nix in the same way that they would now use those native ports' views? If you did this, it would obviate the need for the other ports, leading to a simpler development experience for WebKit contributors. -Filip On May 17, 2013, at 5:41 AM, Luciano Wolf luciano.w...@openbossa.org wrote: The openBossa team at INdT Brazil is proud to announce “Nix” - a new WebKit2 port based on POSIX and OpenGL. Nix stands for “WebKit for unix-like platforms” and, if you consider the German meaning of the word nix, it can be taken as “WebKit plus nothing”. We are looking forward to upstreaming and maintaining this port. Below you will find a brief history about Nix, besides its main goals and motivation. :: A little bit of history :: The first of Nix basic ideas arose from a conversation between Kenneth Rohde Christiansen and Noam Rosenthal, who were wondering about the idea of having a “platform/glib” or platform/posix”. Other ports such as EFL, GTK and Qt would then be able to develop themselves on top of it, having a common source core. While QtWebKit’s QQuickWebView is great for embedding web content into QtQuick, a few people felt they needed more freedom to implement a different WebView behavior than the one being provided by Qt. Behavior more suitable for tricky use cases like embedding web content in a 3D world, for example. A private API called QRawWebView was implemented to fulfil this gap. Motivated by the 2 aforementioned concepts and by the idea of having a “lightweight” GL based port for developing some prototypes on a RaspberryPi, in August 2012 Caio Oliveira and Jesus Sanchez-Palencia, long term WebKit developers and former INdT employees, kick-started what they called WebKitNix. They started from the EFL port, took out every EFL-specific piece of code, implemented a “raw” GL-based WebView, provided a C API in the WK2 fashion and a set of platform/device APIs based on the former Chromium’s Source/Platform. We can summarize its evolutionary process as: 1. Initial idea: platform/posix or platform/glib (share code); 2. Evolved problem: we wanted to have different behaviors for QQuickWebView - Qt Raw WebView 3. Network: QtWebKit + Soup experiment 4. Efl Raw WebView experiment 5. Efl Without Efl :) 6. Nix was born. :: What is inside it? :: Most of Nix’s building pieces are shared with other existing ports: CMake build system, GLib, libsoup and Cairo. Also, it uses Coordinated Graphics, Tiled Backing Store and existing WebKit2 C APIs. Having such a tiny WebKit API means that Nix has the smallest possible footprint on the rest of the WebKit project. We take seriously the notion that the WebKit project is for a web rendering engine and nothing else, and try to develop as much of the auxiliary features as possible outside the WebKit project, on top of the API or in the injected bundle. Nix is already covered by Layout Tests, API Tests (TestWebKitAPI) and Ref Tests which are run by our buildbot[1]. Perf tests are supported but we don’t have a buildbot ready for them at this time. Pixel Tests are on the way. Today we have around 75% of layout tests coverage. We have been merging Nix with webkit.org three times per week so it is kept up-to-date. There is a public repository[2] with the original git history and we are looking forward to upstreaming it. (Yes, we fulfill all the “requirements” defined by the “Successful Port How To” document[3]) :: Who should use it? :: It targets whoever wants to have a hardware accelerated WebKit2 port on UNIX based devices, with a minimum effort. Nix is now running on x86 and ARM (Raspberry Pi[4] is a supported platform). Flexibility and freedom is guaranteed: you can define your WebView behavior and there’s no toolkit attached, so it may be used with EFL, GTK, Qt or even no toolkit at all. :: Who’s working on it now? :: This port was made in openBossa - an open source research group in Brazil. Nowadays, the team comprehends 5 WebKit committers and 4 more developers. In January, several contributors from the university of Szeged have joined the project as well, and are responsible for many valuable contributions like the current work to
[webkit-dev] Moving MemoryInfo under window.internals
Hi, the MemoryInfo interface[1] is currently exposed in window.console[2] and window.performace[3] despite not being standardized or in process of standardization by any spec. It's also only partially functional under the JSC bindings as the jsHeapSizeLimit attribute returns an undefined value[4]. At the moment grepping through the source tree only shows two uses of the interface in a couple of PerformanceTests files[5][6]. Is anyone else aware of any other places where it's used downstream (so its removal would break things outside of WebKit)? If possible, I propose moving the interface under window.internals and adjust the two places where it's used. This also opens the possibility of removing two MemoryInfo-specific settings, memoryInfoEnabled and quantizedMemoryInfoEnabled[7]. The quantization[8] of the given memory information is also not necessary anymore as the information is not exposed to the Web anymore. The jsHeapSizeLimit attribute should be removed as well as it's basically a no-op with the JSC bindings. Thoughts? Cheers, Zan [1] http://trac.webkit.org/browser/trunk/Source/WebCore/page/MemoryInfo.idl [2] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Console.idl [3] http://trac.webkit.org/browser/trunk/Source/WebCore/page/Performance.idl [4] http://trac.webkit.org/browser/trunk/Source/WebCore/bindings/js/JSMemoryInfoCustom.cpp#L39 [5] http://trac.webkit.org/browser/trunk/PerformanceTests/resources/runner.js#L109 [6] http://trac.webkit.org/browser/trunk/PerformanceTests/inspector/performance-test.js#L35 [7] http://trac.webkit.org/browser/trunk/Source/WebCore/page/MemoryInfo.cpp#L143 [8] http://trac.webkit.org/browser/trunk/Source/WebCore/page/MemoryInfo.cpp#L90 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
GoogleURL seems Chromium-specific, i.e. WTF_USE_GOOGLEURL is only defined for Chromium in Source/WebCore/config.h. Regards, -Z On Thu, Apr 4, 2013 at 10:50 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Thursday 04 April 2013, Geoffrey Garen wrote: Hi folks. Since we no longer need to support the Chromium port, let's take the opportunity to streamline. Hopefully, this will make development easier and more coherent for everyone. Adam and Eric offered to do some of this cleanup, but I think it's healthier for people who will continue to be a part of WebKit to decide what gets cleaned up, and execute on the plan. Below is a high-level view of some improvements we're planning over the coming weeks. Concepts we plan to remove: Layering violations in WebCore/platform, where a Page* or Frame* is passed to a function Supplementable and Supplement #if USE(GOOGLEURL) #if USE(V8) #if !USE(JSC) #if PLATFORM(CHROMIUM) Skia DOMFileSystem WebLayer and its scrolling implementation Features #defines that haven't gained traction Unless you plan to scare more ports away, I would suggest double checking stuff to remove. As far as I know BlackBerry and EFL are using Skia, and I am sure there are ports using GoogleURL as well. For the record though I don't think Qt is using any of that those. Geoff posted the list in part because we'd like to know if any of the things above are used by other ports. We're not planning to remove things still in use. It would be good to know specifics. I could not find evidence of other ports using GoogleURL for instance. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: Web VHS API
On Mon, Apr 1, 2013 at 7:06 PM, Ryosuke Niwa rn...@webkit.org wrote: I'm also confused by the fact VHSOutput interface has a method, streamToYouTube, that specifically supports one website. Are we expecting to add methods like streamToDailyMotion, streamToUStream, etc...? I'd prefer coming up with a generic format and let author specify an URL to which the video is streamed. Why even incorporate such a specific functionality into the standard for a site/service that is about to be shut down? Regards, -Z ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files
On Thu, Mar 21, 2013 at 5:18 PM, Robert Hogan li...@roberthogan.net wrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan li...@roberthogan.netwrote: On Thursday, 21 March 2013, Ryosuke Niwa wrote: I used to pull results from the bots where possible but creating inconsistency between png/text results is not good. It is unfortunate but it's much better than losing the complete test coverage. If that's the case then I'm happy to land whatever garden-o-matic pulls in or I can sweep from the bots, even if it means that png results for Mac, Qt, et al. go bad as a result. I guess we will always have ports whose bots do not run pixel tests so if those ports are happy to live with the downsides of doing that then there really is no obstacle to authors owning the job of updating the baselines for all ports when they land a change. IMHO ports who don't run pixel tests would be better off deleting any png results they have in the tree. Is there a reason Mac hasn't done that? Don't you get lots of failures when you run pixel tests locally? Yes, but I'd argue that it's better than losing the test coverage. By the way, we can easily address this problem by always generating pixel results for unexpectedly failing tests. Namely, we can force --pixel when we're retrying tests. Perhaps NRWT could produce txt and png results for all tests marked with REBASELINE or similar in TestExpectations. That would avoid the need to turn the bots red on each platform for at least one build cycle. I like this specific proposal. There's already a similar expectation planned, 'NeedsRebaseline'. https://bugs.webkit.org/show_bug.cgi?id=100415 Or is that something we can live with? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Problems with lists.webkit.org?
Hi all, I'm experiencing problems when accessing https://lists.webkit.org - namely, opening the site reports that a bug was hit inside Mailman. Probably related, I'm not getting any traffic from the webkit-unassigned list since yesterday ~8:40 AM PDT. Luckily webkit-dev traffic seems unaffected. I reckon I'm not the only one seeing the issues? Regards, -Z ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform
On Thu, Feb 28, 2013 at 10:02 PM, Maciej Stachowiak m...@apple.com wrote: I think Adam's old plan for the Platform directory was to migrate from WebCore/platform piece-by-piece, starting with related groups of classes that are already free of layering violations. That seems like a sensible approach to me as it allows the work to happen incrementally. I like that approach. Hopefully people with knowledge of specific build systems can help by setting up the project files so the non-violating source code can start the migration. One suggestion when approaching this task was to use the Platform namespace for such code. This was already attempted in r104231[1] but that change later got rolled out. Is anyone opposed to doing this? [1] http://trac.webkit.org/changeset/104231 -Z ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform
On Fri, Mar 1, 2013 at 12:43 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote: Hi, 2013/2/28 Darin Adler da...@apple.com: To do this, we need to eliminate dependencies from the platform directory to the rest of WebCore. At this time, we are far from that. Many dependencies on the DOM and other such things have crept into the platform directory. I would be happy to help fixing this, Darin. Are the bugs blocking https://bugs.webkit.org/show_bug.cgi?id=21354 a good-enough to start list or is there something more urgent? Violations reported by those bugs are most likely still valid. There are of course probably other existing violations that haven't been reported yet. -Z Cheers, jesus ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Kickstarting the migration of platform-specific WebCore source code to Source/Platform
On Thu, Feb 28, 2013 at 6:31 PM, Darin Adler da...@apple.com wrote: There may be a misunderstand of what the “platform layer” is. We should not move all platform-specific files into the platform directory! Please do not make the changes in bug 110330 until we have discussed this. The idea is not that all platform-specific code is in the WebCore/platform directory. Instead, the idea is that WebCore/platform contains code that the rest of WebCore is built on top of that creates a platform independent abstraction. To do this, we need to eliminate dependencies from the platform directory to the rest of WebCore. At this time, we are far from that. Many dependencies on the DOM and other such things have crept into the platform directory. The real point of having a separate library for the platform directory is not to segregate all platform-specific code, but rather to have a coherent platform independence library that we can rely on for most platform-independence and minimize the need for platform-independent code. -- Darin Understood. Thanks for the explanation, much appreciated. Will held off the work for the GTK-specific files until appropriate. For the sake of clarity and if in anyone's interest, I'm linking two more bugs: https://bugs.webkit.org/show_bug.cgi?id=21354 - meta bug for platform layering violations https://bugs.webkit.org/show_bug.cgi?id=75664 - meta bug for the platform layer migration Regards, -Z ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel e...@webkit.org wrote: I wish it were easy to work on feature branches. We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I like the idea of developing larger features or multi-patch changes on a branch. Relating this with the next two wishes, I'd support this approach if the whole patchset would be tested on trunk for every port with every change that's made. The port maintainers (even those working on small ports) could then fix any build failures or make changes to the platform-specific code as necessary to make the merging of the branch a minimal annoyance for everyone. Similarly, when the work on the branch is deemed finished and there are still ports that would break upon merging, a sensible time frame, for instance 2 work days, would be given for the port maintainers to come up with fixes before merging the branch regardless of the consequences. The point I'd like to expose is that when using branches, landing broken branches on broken trunk leads nowhere. That's why it's important to maintain a building and working trunk, but give all the ports the possibility of fixing any outstanding issues in the branch before merging, so the trunk doesn't break (and the breakage loop is entered). Regards, -Z ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] PSA: Simplification of adding new features for the Autotools build system
Hi all, this is just a quick note about the recent changes to the Autotools build system (used by the GTK port) regarding the addition of new features. When adding feature defines to various build system-specific files, the Autotools build system now lists the feature defines in Source/WebCore/GNUmakefile.features.am.in[1]. The value for the feature define should default to 0 (i.e. the feature, most likely unstable or missing a port-specific implementation, will be disabled in release versions of WebKitGTK+). You're welcome to enable the feature for the GTK port in Tools/Scripts/webkitperl/FeatureList.pm[2] if the feature does not rely on any port-specific implementation and you'd like to get layout test coverage of the feature by the GTK port. Values used for the GTK port in this file override the values in the GNUmakefile.features.am.in when using build-webkit (so-called development builds, also performed on the BuildBot builders). Adding a new configuration flag to configure.ac *is not required* anymore. The only exception to this is a new feature implementation that relies on a (new) dependency. These guidelines are also located on the Trac wiki[3] in a slightly more detailed nature. Regards, -Ž [1] https://trac.webkit.org/browser/trunk/Source/WebCore/GNUmakefile.features.am.in [2] https://trac.webkit.org/browser/trunk/Tools/Scripts/webkitperl/FeatureList.pm [3] http://trac.webkit.org/wiki/AddingFeatures#ActivatingafeatureforAutotoolsbasedports ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] question about a changeset
The 1.10 branch doesn't enable CSS3 flexbox support by default. To use -webkit-flex you have to recompile WebKitGTK+ with CSS3 flexbox enabled, i.e. passing --enable-css3-flexbox to the configure script. http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.10/configure.ac#L1010 http://trac.webkit.org/browser/releases/WebKitGTK/webkit-1.10/Source/WebCore/css/CSSValueKeywords.in#L334 -Z On Mon, Dec 3, 2012 at 11:43 AM, Luka Napotnik luka.napot...@gmail.comwrote: Hello. For my development purposes I'm using the Gtk+ 3 port of WebKit (webkitgtk 1.10). I was trying to use 'display:-webkit-flex' feature which should be available in webkit sources at least 7 months now as of changeset:117385 [1] which is a patch to bug 86529 [2]. But as it seems that this changeset isn't available in the Gtk+ port. Can anyone please confirm this? Thanks [1] http://trac.webkit.org/changeset/117385 [2] https://bugs.webkit.org/show_bug.cgi?id=86529 -- Greets, Luka Napotnik, www: http://napotnik.info ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] do you want WK1 and WK2 keywords in the TestExpectations files?
On Tue, Nov 13, 2012 at 8:59 PM, Raphael Kubo da Costa rak...@webkit.orgwrote: Dirk Pranke dpra...@chromium.org writes: So, it seems like WK1 and WK2 keywords might be useful. However, I don't really want to add more divergence between ports, so it would be nice to have everyone agree to use it if we were to add it. What do you all think? Would you like this feature, and would you all use it ? At least on the EFL side I think things are good the way they are: we have platform/efl for common stuff and platform/efl-wk1 and platform/efl-wk2 for WK1- or WK2-specific stuff (not only TestExpectations files but also test results). If we got rid of those and put everything together in platform/efl, I think we'd end up with a very big TestExpectations file and don't know what we'd do with the occasional different results for WK1 and WK2. I'm pushing for the same hierarchy for the GTK port in https://bugs.webkit.org/show_bug.cgi?id=97562 I also agree that keeping all expectations in one TestExpectations file and using WK1/WK2 modifiers would bloat that file and considerably affect efficient work with it. Personally, I don't have any need for these additional modifiers, I'd rather see wk1- and wk2-specific fallback directories with their own TestExpectations. While not strictly related to this, I'd also like someday see Chromium port moving to a similar organisation of their baselines, in place of using many platform modifiers which could then be removed. -Z However, this is a little awkward and gets worse if you also need to support different expectations for multiple different configs (e.g., mac-lion vs mac-snowleopard vs mac-mountainlion). It wouldn't really solve this problem, right? -- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] The --test-list option behavior in NRWT
I'd propose an --ordering option, with three possible values: - random, randomizes the test list - natural, orders the test list in natural order, which is the current behavior - none, keeps the order that was specified in the arguments or test list, default (not certain about the name, though) The --randomized option would be kept for backwards compatibility, but perhaps deprecated. I'll build up a patch that's based on the consensus. -Z On Thu, Nov 8, 2012 at 10:43 AM, Balazs Kelemen kbal...@webkit.org wrote: On 11/08/2012 02:51 AM, Ojan Vafai wrote: On Wed, Nov 7, 2012 at 12:41 PM, Dirk Pranke dpra...@chromium.orgwrote: On Tue, Nov 6, 2012 at 11:58 PM, Žan Doberšek zandober...@gmail.com wrote: Hi WebKitties, I'd like to see in what scale the --test-list option in NRWT is used and whether anyone would object a change in how its usage behaves. Currently the test gathering takes into account any paths that were passed in through the command line and any paths listed in the file to which a possible --test-file option points[1]. These paths are then expanded if necessary (due to platform-specific tests and virtual test suites) and all the tests to which these paths apply are gathered[2]. All the gathered tests are then either sorted into a natural order or randomized (if the --randomize-order option is used)[3]. I'd like to propose a change in the behavior when using the --test-list option. When used, the tests would be gathered only from the paths listed in the file to which the option points. Also, the gathered tests would be sorted to follow the order of the paths in the test list file. For instance, consider the following two entries being placed in the test list file: c/d/e.html a/b/ The current behavior would gather all the tests to which these two paths apply and sort them in this order (on the premise that no other paths are passed through the command line arguments): a/b/1.html a/b/2.html c/d/e.html The new behavior would place the c/d/e.html test at the top of the list but sort the other two tests in order, like this: c/d/e.html a/b/1.html a/b/2.html The idea behind this is to be able to specify the exact order in which the tests should be run. I'm currently playing around with a tool that randomly chooses a certain number of tests, runs them and bisects down the first regression that occurs (if any) to the smallest possible ordered list of tests that reproduces that regression. The proposed change makes this a simple task from the test listing perspective and I'd argue that exact test ordering is the main point of an option such as --test-list. Currently I'm using an untested workaround of adding a new option that specifies the tests should be reordered back to the original order that the test list file provided, but I'd like to move on with implementing the change in behavior if everyone feels it's OK and won't tamper with his/her workflow. -Z [1] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/controllers/layout_test_finder.py#L46 [2] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/base.py#L576 [3] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py#L309 Hi, I have used the option from time to time, and I have also wanted from time to time the ability to run tests in a specific order. This change would be fine by me. If people want to ensure that tests run in the old order, they can always sort the test list. I have used this in the past to identify which test caused test flakiness (e.g. I have 100 tests and I know the last test depends on one of the other 99 to run first in order to pass). The problem with this last sentence is that it's hard to know what order run-webkit-tests would choose, so it's hard to replicate it. It would make that use-case a little harder if we made this change. Otherwise, I don't care either way. Exactly for the reason Ojan mentioned I think the best would be to add an option for defining the desired ordering behavior. Paths on command line and in --test-list should imply to use the ordering as it is passed but it would be possible to force the current method. I hope it would not add too much complexity. -kbalazs ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] The --test-list option behavior in NRWT
Hi WebKitties, I'd like to see in what scale the --test-list option in NRWT is used and whether anyone would object a change in how its usage behaves. Currently the test gathering takes into account any paths that were passed in through the command line and any paths listed in the file to which a possible --test-file option points[1]. These paths are then expanded if necessary (due to platform-specific tests and virtual test suites) and all the tests to which these paths apply are gathered[2]. All the gathered tests are then either sorted into a natural order or randomized (if the --randomize-order option is used)[3]. I'd like to propose a change in the behavior when using the --test-list option. When used, the tests would be gathered only from the paths listed in the file to which the option points. Also, the gathered tests would be sorted to follow the order of the paths in the test list file. For instance, consider the following two entries being placed in the test list file: c/d/e.html a/b/ The current behavior would gather all the tests to which these two paths apply and sort them in this order (on the premise that no other paths are passed through the command line arguments): a/b/1.html a/b/2.html c/d/e.html The new behavior would place the c/d/e.html test at the top of the list but sort the other two tests in order, like this: c/d/e.html a/b/1.html a/b/2.html The idea behind this is to be able to specify the exact order in which the tests should be run. I'm currently playing around with a tool that randomly chooses a certain number of tests, runs them and bisects down the first regression that occurs (if any) to the smallest possible ordered list of tests that reproduces that regression. The proposed change makes this a simple task from the test listing perspective and I'd argue that exact test ordering is the main point of an option such as --test-list. Currently I'm using an untested workaround of adding a new option that specifies the tests should be reordered back to the original order that the test list file provided, but I'd like to move on with implementing the change in behavior if everyone feels it's OK and won't tamper with his/her workflow. -Z [1] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/controllers/layout_test_finder.py#L46 [2] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/base.py#L576 [3] http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py#L309 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline
On Fri, Aug 24, 2012 at 4:35 AM, Dominik Röttsches dominik.rottsc...@intel.com wrote: Hi Dirk, On 08/22/2012 10:49 PM, Dirk Pranke wrote: The Chromium canaries now exit after 5000 failures or 1000 crashes/timeouts. Can the failure limit be increased to 1 for example? Levi/Emil were saying the rebaseline touches about 8000 cases. Otherwise we'd have to go through a more complicated process like Zan explains. Despite the testing exiting after a certain number of failures, the newly-registered failures would still be possible to rebaseline. So technically you could do three or four rebaseline cycles and get the bots back into a normal state. Dominik __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Subpixel layout - requesting help for big rebaseline
Perhaps one option of doing such a huge rebaseline might be the following: 1. Get the bots for the affected port into a green state. 2. Add temporary expectations for every LayoutTests/ subdirectory and perhaps for subdirectories of LayoutTests/fast, LayoutTests/svg and LayoutTests/editing as well[1]. This way the test runs wouldn't be exiting early due to too many test failures (though this might occur when removing expectation for just one subdirectory, for instance LayoutTests/tables). 3. Land the patch at the start of the daily period in which commit frequency is low (probably before the PST morning). This will ensure no actual regressions originating from other commits would get rebaselined or cause problems (crashes, for instance). 4. Remove expectations for subdirectories one by one, letting the bots to perform one cycle and report any failures in that subdirectory, and use the tools to perform the rebaseline. But it's still a huge task, especially for chromium as there are at least three flavors of the port that would require special attention. These bots are also running pixel tests, so there'll be large patches committed that AFAIK used to cause problems (for instance the Git tree went out of sync). [1] In Chromium's case, it would help to get the JSON output of the test run with the rounding patch applied just to know where to expect failures and how many of them. This would also help to better specify directory-specific expectations. On Wed, Aug 22, 2012 at 1:13 PM, Dominik Röttsches dominik.rottsc...@intel.com wrote: Hi Chromium folks, Levi and Emil did a great job in implementing SubPixel Layout. I was looking into enabling it on WebKit EFL. Unfortunately, the initial rebaseline for EFL would be huge. That's why I hesitated to enable it right away. Instead I started looking into what the reasons are. I found one case where rounding should be added, here's my patch: https://bugs.webkit.org/show_bug.cgi?id=89572 Landing this makes the rebaselining efforts for ports enabling subpixel layout smaller, so IMHO it'd accelerate adoption. On the other hand, landing this patch requires a rebaselining for Chromium in the area of several thousand testcases. I do feel the pain there. So I'd appreciate your help for getting this one landed. According to their comments on bugzilla, Emil and Levi approve the change. Thanks, Dominik -- Dominik Röttsches dominik.rottsc...@intel.com dominik.rottsc...@intel.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebDriver support in WebKit
On Mon, Jul 23, 2012 at 10:50 PM, Ken Kania kka...@chromium.org wrote: The WebDriver w3c spec http://www.w3.org/TR/2012/WD-webdriver-20120710/ was recently published as a first public working draft. The primary goal of the API is to enable website testing from a user's perspective (finding elements, typing, clicking). Like the WebKit Inspector, WebDriver hopes to aid developers in the process of developing/testing their website. Could it also be used in the layout tests? Looking through the spec there are APIs for mimicking mouse and keyboard interaction. This is pretty much what EventSender does, so could WebDriver replace the EventSender? Currently Chromium supports this API through a separately distributed binary. I wanted to get some feedback on the idea of supporting WebDriver in WebCore itself (perhaps as a WebCore module, or perhaps in a similar way as the WebKit Inspector). The main benefit of this would be that the WebDriver implementation could be shared among all interested WebKit ports. Continuing with the idea of WebDriver replacing the EventSender, I do wonder if it would be OK to bypass the native toolkit event handling and push the events straight into the WebCore's EventHandler. Also, the Capabilities and MutableCapabilities seem to do what is currently being done through either window.internals.settings or testRunner.overridePreference(), so this seems another thing for what the WebDriver implementation could be used instead of aforementioned object and method in layout tests. Thanks Ken ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] GTK+ port's help needed to get rid of FAIL test expectation
I think it would suffice to replace all the FAIL occurrences with TEXT, except for the failing reftests - those should have FAIL turned into IMAGE. Gtk bots don't run pixel tests yet so any other IMAGE failures could perhaps be addressed at later time. I'd like some approval on this from the senior maintainers, after that FAIL should disappear from Gtk's TestExpectations pretty soon. Regards, Zan On Sat, Jun 9, 2012 at 9:35 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sat, Jun 9, 2012 at 12:27 PM, Ojan Vafai o...@chromium.org wrote: Can you just expand out FAIL to it's equivalent longform? FAIL == TEXT IMAGE IMAGE+TEXT. I don't see a need to block the infrastructure change on this as the semantics are exactly the same. You can just find/replace every instance of FAIL. I could. But it appears that most entries in GTK+'s test expectations file has FAIL expectation so I'd rather make sure it's not intentional, etc... - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using ref tests for repaint bugs
On Fri, May 25, 2012 at 9:57 AM, Dominik Röttsches dominik.rottsc...@intel.com wrote: Andrei, On 05/25/2012 02:43 AM, Andrei Bucur wrote: Ojan, As Simon states, some repaint tests will likely not be possible to write correctly as ref tests, but some of them I think they fit very well in the happy-no-pixel-test bucket :). If people decide it's a direction worth investigating, I'll give the idea a spin. I'd be interested to hear about your progress. Recently I was facing a couple of similar issues: https://bugs.webkit.org/show_bug.cgi?id=73409 and then GTK decided to always do repaints before dumping pixel results: https://bugs.webkit.org/show_bug.cgi?id=86284 which might not be the right solution either - so if you come up with something more fine-grained - that'd be great. Here's why a repaint is forced for the Gtk port before dumping pixel results: Gtk port uses a backing store which is updated every 0.017 seconds, i.e. 60 times per second, a reasonable interval. The problem is that many tests are structured in the way that they make an alteration that produces a layout change and then immediately finish. This leaves no time for the backing store to be updated. It would also be ridiculous to go around fixing tests by delaying the finish by any amount of time. Because of that a repaint is forced just before dumping the pixel results so the dirty regions of the backing store (only those and not the complete backing store) are updated. Regards, Zan Dominik ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EditBugs permission
Hi, to keep the thread count low, I'll borrow this one and request for the EditBugs permission myself. The email address is zandober...@gmail.com Thanks in advance! On Fri, Apr 13, 2012 at 12:47 AM, Eric Seidel e...@webkit.org wrote: Done. % webkit-patch add-users-to-groups shezbaig...@gmail.com Add users matching shezbaig...@gmail.com which groups? 1. canconfirm 2. editbugs Enter one or more numbers (comma-separated), or all: Reading Keychain for bugs.webkit.org account and password. Click Allow to continue... Logging in as e...@webkit.org... Found 1 users matching shezbaig...@gmail.com: shezbaig...@gmail.com (17597) Are you sure you want add 1 users to groups ['canconfirm', 'editbugs']? (This action cannot be undone using webkit-patch.) [Y/n]: Adding shezbaig...@gmail.com to ['canconfirm', 'editbugs'] On Thu, Apr 12, 2012 at 3:17 PM, Shezan Baig shezbaig...@gmail.com wrote: Hello, When I submit a patch to bugzilla, I get an error that EditBugs is not set on my account. Can someone add this permission to my bugzilla account please? I sent a message to webkit-committ...@lists.webkit.org as instructed, but that doesn't get through. My login is: shezbaig...@gmail.com My patch submitted to: https://bugs.webkit.org/show_bug.cgi?id=80382 Thanks, Shezan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing Custom bindings for type array.
On Wed, Mar 14, 2012 at 1:30 PM, Vineet Chaudhary rgf...@motorola.comwrote: All of them returns type JSArray for (JS engine) and V8Arrays for the (V8 engine). I have wip attached in the bug ,modifying CodeGenerator for JS and V8 to auto generate bindings which works fine fine. But it fails for the Gtk because of the GObject bindings. The GObject bindings would probably use a GLib-specific array structure, the GArray, meaning some additional hacking would be required on CodeGeneratorGObject.pm. I can help with that once it is clear how the array type should be implemented in JS and V8 generators. To resolve this issue I am thinking of adding WebKitDOMArray.h and WebKitDOMArray.cpp to WebCore/bindings so that It can generate the appropriate binding. Can someone please advice if this the correct way of doing this or there is any other approach to do this. Thanks, Vineet ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Introducing run-perf-tests and Adding Performance Bots
On Thu, Mar 1, 2012 at 6:41 PM, Jesus Sanchez-Palencia je...@webkit.orgwrote: A Qt WebKit1 performance bot was added last week, sorry for the late announcement. If I'm not mistaken, currently run-perf-tests works with DRT only, but what if we would like to make it work with WTR as well so we could also have WebKit2 performance bots running? I'm not aware of the infrastructure provided by webkitpy (Drivers, etc) so I'm not sure about the amount of work needed... To get WKTR running the performance tests a '-2' switch must be added to PerfTestRunner and some refactoring is required in the WKTR itself to properly handle the '--no-timeout' switch when given. I've got a diff of these changes laying around I can transform into a patch if there isn't one yet, just point me to a bug (or let's create one). Best, Zan Cheers, jesus On Tue, Jan 31, 2012 at 8:16 PM, Ryosuke Niwa rn...@webkit.org wrote: FYI, I've added a wiki page describing how to write a new perf. test: https://trac.webkit.org/wiki/Writing%20Performance%20Tests On Fri, Jan 20, 2012 at 11:20 AM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 19, 2012 at 3:20 PM, Ryosuke Niwa rn...@webkit.org wrote: I didn't merge it into run-webkit-tests because performance tests don't pass/fail but instead give us some values that fluctuate over time. While Chromium takes an approach to hard-code the rage of acceptable values, such an approach has a high maintenance cost and prone to problems such as having to increase the range periodically as the score slowly degrades over time. Also, as you can see on Chromium perf bots, the test results tend to fluctuate a lot so hard-coding a tight range of acceptable value is tricky. While this isn't perfect, I still think it's worth doing. I'm afraid that the maintenance cost here will be too high. Values will necessarily depend on each bot so we'll need number of tests×number of bots expectations, and I don't think people are enthusiastic about maintaining values like that over time (even I don't want to do that myself). Turning the bot red when a performance test fails badly is helpful for finding and reverting regressions quickly, which in turn helps identify smaller regressions more easily (large regressions mask smaller ones). I agree. Maybe we can obtain the historical average and standard deviation and turn bots red if the value doesn't fall within some value between 1 and 2 standard deviations. In either case, we have to get the bots running the tests and work on getting reliable data first. After http://trac.webkit.org/changeset/106211, values for most tests have gotten very stable. They tend to vary within 5% range. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
