Mario Sanchez Prada | 21 May 2013 16:34

Moving WebCore/accessibility code into WebCore/platform/

Hi all,

Following the discussion in the contributors meeting about layering violations I was thinking about
moving all the accessibility stuff inside WebCore/accessibility into a new
WebCore/platform/accessibility directory.

My reasoning behind this could be summarized as this:

* Accessibility code is actually already platform dependant, as every port supporting this exposes the
accessibility hierarchy in slightly different ways (ATK flattens more the hierarchy than Mac, for instance).

* Besides the AccessibilityObject wrappers and partial platform-specific implementation files (e.g.
AccessibilityObjectMac.mm) present in places like WebCore/accessibility/[atk|mac], there are
other bits in WebCore/accessibility that are platform specific as well (e.g.
AccessibilityRenderObject). These bits are guarded with "#if PLATFORM" macros, which would still be
necessary to meet the different requirements of each port.

* The number of ports adding support for accessibility is increasing, some of them sharing code already
(e.g. EFL and GTK port, both use ATK), so I believe that would be a nice move to make.

Of course, we could always add an exception to the style checker, but I feel like relocating things would be a
better approach in this case, thinking of the long term.

What do you think?

Thanks,
Mario
Ryosuke Niwa | 21 May 2013 06:06
Favicon
Gravatar

Use BlinkMergeCandidate to merge/back port Blink changes

Hi,

We’ve added BlinkMergeCandidate keyword to Bugzilla to track any Blink changes we might want to merge.  Please add this keyword when you’re filing a bug or posting a patch to merge a Blink change.

- R. Niwa

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Simon Fraser | 21 May 2013 03:28
Picon
Favicon

Unprefixing Page Visibility

Does anyone object to supporting the Page Visibility API unprefixed?
https://bugs.webkit.org/show_bug.cgi?id=102340

Should we keep support for the prefixed version?

Simon
Geoffrey Garen | 21 May 2013 01:37
Picon
Favicon

Does anyone build with !ENABLE(LLINT)?

I'd like to remove the #ifdef, and make the interpreter an unconditional part of JSC.

It's sometimes hard to reason about the different execution engines if you can't assume that the
interpreter and its basic data structures exist.

Thanks,
Geoff
Anders Carlsson | 21 May 2013 00:15
Picon
Favicon

WebKit2 and ENABLE_PLUGIN_PROCESS

Hello,

is anyone building WebKit2 without ENABLE_PLUGIN_PROCESS set, running Netscape plug-ins in the web process?

The reason I’m asking is that having two code paths complicates things and I’d like to remove the
non-plug-in process code path.

- Anders
Brian Holt | 20 May 2013 16:48

[WIP][GTK] Memory leak detection

Memory leak detection is a recurrent topic on this mailing list [1-5] but at present there exists only support for the Mac leaks tool[6].  The de facto standard for memory checking and leak detection for Unix is Valgrind and the goal of this work is to launch the DRT under Valgrind to generate a xml file with details of leaks found, and then to parse this file and display this information.

 

Failures should result in the filing of memory bugs and adding the error to the suppression file.  Chromium has a fairly mature process[7] for this which can been taken as the starting point.

 

This work is being tracked under https://bugs.webkit.org/show_bug.cgi?id=116317.

 

This is a work in progress, but as a first attempt leak checking can be done using the existing run-webkit-tests script as follows:

 

$ Tools/Scripts/run-webkit-tests --gtk --leak --wrapper="valgrind" LayoutTests/accessibility/accessibility-node-memory-management.html

 

The wrapper argument is used as a workaround because the the existing hooks "check_for_leaks" and "print_leaks_summary" happen *after* the test has finished running, while we need to launch the test already under Valgrind. Valgrind options are passed by setting VALGRIND_OPTS, but could be changed to use a configuration file instead.

 

At present only minimal changes have been made to the Mac-specific leak code.  In a subsequent bug, perhaps the run-leaks perl script that checks for leaks on Mac can be refactored into a "wrapper" that chooses which platform-dependent script to run, so there could be a run-gtk-leaks, run-mac-leaks, with run-leaks picking the right one.

 

Comments and feedback welcome!

 

Regards

Brian

 

[1] https://lists.webkit.org/pipermail/webkit-dev/2009-April/007269.html

[2] https://lists.webkit.org/pipermail/webkit-gtk/2010-March/000162.html

[3] https://lists.webkit.org/pipermail/webkit-gtk/2011-February/000406.html

[4] https://lists.webkit.org/pipermail/webkit-gtk/2010-November/000346.html

[5] https://lists.webkit.org/pipermail/webkit-gtk/2010-September/000330.html

[6] http://cocoadev.com/wiki/TheLeaksTool

[7] http://dev.chromium.org/developers/tree-sheriffs/sheriff-details-chromium/memory-sheriff#TOC-Filing-good-memory-bugs

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
TAMURA, Kent | 19 May 2013 23:15

Using ENABLE_INPUT_MULTIPLE_FIELDS_UI and/or ENABLE_CALENDAR_PICKER

Is any port interested in using ENABLE_INPUT_MULTIPLE_FIELDS_UI and/or ENABLE_CALENDAR_PICKER ?

Don't you know what they are? Please look at [1]. These flags provide date/time input controls like desktop Google Chrome.
These flags were enabled only in Chromium port, and they are dead code in WebKit for now. If no port has a plan to use them, we had better remove them.


[1] http://trac.webkit.org/wiki/EnableFormFeatures

--
TAMURA Kent
Software Engineer, Google


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Anders Carlsson | 19 May 2013 20:36
Picon
Favicon

ENABLE(PAGE_POPUP) in WebCore

Hi everyone,

I was looking at the PagePopup code and it seems to be BlackBerry specific. Furthermore, it seems to only be
called from inside BlackBerry WebKit.

Would it be possible to just move the code into WebKit/blackberry instead? I think someone with access to a
BlackBerry build environment could do it in ~30 minutes or so. 

Thanks,
- Anders
Ryosuke Niwa | 17 May 2013 21:58
Favicon
Gravatar

Don’t add entries to TestExpectations just to rebaseline tests later

Every time I look at TestExpectations, I find few dozen entries with # NeedsRebaseline.
e.g. http://trac.webkit.org/changeset/150290 (there are still a ton left after this changeset)

Please stop reducing our test coverage.

Reviewers, please don’t r+ these patches.  The ratio of people who end up not following up with their promise to rebaseline tests is way too high.

- R. Niwa

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Luciano Wolf | 17 May 2013 14:41
Gravatar

Announcing new port: Nix

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 switch to libcurl.

:: Past and Future ::

- 2012 -
- August/September: Lab phase, lots of experiments;
- October/November: Branching;
- late November: test infrastructure running;
- 2013 -
- January: public repository[2];
- May: comments/discussions/objections -> upstreaming;
-June & beyond: maintenance, expand test coverage, focus on the web
platform (contributing to WebCore).

:: Where can you find it? ::

website: webkitnix.openbossa.org
buildbots: webkitnix.openbossa.org/build/
code: https://github.com/WebKitNix/webkitnix
contact: nix <at> openbossa.org
IRC: #webkitnix at freenode

Best regards,
Nix/openBossa team

[1] http://webkitnix.openbossa.org/build/
[2] https://github.com/WebKitNix/webkitnix
[3] http://trac.webkit.org/wiki/SuccessfulPortHowTo
[4] https://github.com/WebKitNix/nix-rpi-sdk
Ryosuke Niwa | 17 May 2013 02:00
Favicon
Gravatar

CQ was stuck; fixed

Hi,

CQ was stuck for the last 18 hours or so due to some test failures.  I've fixed it but expect it to take another 4-5 hours to catch up.

- R. Niwa
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Gmane