Re: [webkit-dev] Ports not building as C++11?

2013-07-26 Thread Christophe Dumez - SISA
Hi,

FYI, since Oliver's change, the EFL port is now building as C++11.

Kr,
Christophe DUMEZ.


From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Anders Carlsson [ander...@apple.com]
Sent: Friday, July 26, 2013 19:04
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] Ports not building as C++11?

Hi everyone,

when Oliver landed his “let’s break everything” patches in JSC the other day, I 
noticed that some of the follow-up build fixes by other ports were removing use 
of C++11 features (mainly nullptr).

Are there any ports that aren’t building as C++11? If so, why not?

- 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] Touch operation corrupts screen when specifying other than overflow:visible in css

2013-07-12 Thread Christophe Dumez - SISA
Hi,

You need to CC relevant developers on bugzilla and possibly ping them on IRC.
This mailing list is not the right place to publicize bug reports.

Also note that the patch seems to be Windows-port specific.

Kr,
Christophe DUMEZ.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of HIDEKI YOSHIDA [yoshida-...@necst.nec.co.jp]
Sent: Friday, July 12, 2013 14:46
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] Touch operation corrupts screen when specifying other 
than overflow:visible in css

Hi,

Is there anyway to ask to review the patch I created?

I created a pacth to resolve
https://bugs.webkit.org/show_bug.cgi?id=99842
Bug 99842 - Touch operation corrupts screen when specifying other than 
overflow:visible in css

and registered it to the site putting following option.
 review?
 commit-queue?

However, no review has been proceeded for half a year.

If the option which I put on the patch is wrong, or if
I miss some procedure which I had to take, could
someone inform me?

  Hideki

***
  Hideki Yoshida
  Embedded Software Division
  NEC System Technologies, Ltd.
E-MAIL:yoshida-...@necst.nec.co.jp
***

___
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

2013-05-17 Thread Christophe Dumez - SISA
Great work guys. Can't wait to see this upstreamed.

Kr,
Christophe Dumez.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Luciano Wolf [luciano.w...@openbossa.org]
Sent: Friday, May 17, 2013 15:41
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] 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: n...@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] 

[webkit-dev] Global constructors attributes

2013-04-17 Thread Christophe Dumez - SISA
Hi,

According to the Web IDL specification [1] (still valid in the latest Editor 
Draft [2]), global constructors should have the following attributes:
{ [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }

Quoting from the specification:


For every interfacehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-interface that:

  *   is a callback 
interfacehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-interface that 
has constantshttp://dev.w3.org/2006/webapi/WebIDL/#dfn-constant declared on 
it, or
  *   is a non-callback 
interfacehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-interface that is not 
declared with the 
[NoInterfaceObject]http://dev.w3.org/2006/webapi/WebIDL/#NoInterfaceObject 
extended 
attributehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-extended-attribute,

a corresponding property must exist on the ECMAScript global object. The name 
of the property is the 
identifierhttp://dev.w3.org/2006/webapi/WebIDL/#dfn-identifier of the 
interface, and its value is an object called theinterface object.

The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, 
[[Configurable]]: true }. The characteristics of an interface object are 
described in section 
4.4.1http://dev.w3.org/2006/webapi/WebIDL/#interface-objectbelow.



Currently, global constructors have the following attributes in WebKit, which 
is not according to spec:
{ [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: false }

This is causing some W3C compliance tests to fail, such as this one [3].

Behavior of other browsers:
- Firefox follows the specification
- Blink does not follow the specification
- IE9 follows partly the spec:
  * global constructors are not enumerable (according to spec)
  * global constructors are not deletable (not according to spec)

I don't think it is likely web sites rely on those global constructors being 
enumerable considering that they are not enumerable in both IE9 and Firefox. 
Making them deletable seems low risk to me as well.

I uploaded a patch proposal to bugzilla [4] to make WebKit follow this part of 
the spec. I would appreciate feedback from the rest of the community as this is 
a web-exposed behavior change.

Kr,
Christophe DUMEZ

[1] http://www.w3.org/TR/2012/CR-WebIDL-20120419/#es-interfaces
[2] http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces
[3] 
http://w3c-test.org/webapps/ProgressEvents/tests/submissions/Ms2ger/interface.html
 (2 last tests)
[4] https://bugs.webkit.org/show_bug.cgi?id=110573

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Global constructors attributes

2013-04-17 Thread Christophe Dumez - SISA
Hi,

The code change is actually really small. This is basically, 2/3 lines in the 
bindings generator.

Alternatively, we could add [NotEnumerable, Deletable] before each *Constructor 
attribute in DOMWindow.idl but it seemed easier the patch the generator 
considering the number of such attributes in DOMWindow. Also, there is a risk 
of someone adding a new constructor attribute without the needed extended 
attributes.

Either way though, it seems easily reversible.

Kr,
Christophe DUMEZ.


From: ryosuke.n...@gmail.com [ryosuke.n...@gmail.com] on behalf of Ryosuke Niwa 
[rn...@webkit.org]
Sent: Wednesday, April 17, 2013 21:36
To: Christophe Dumez - SISA
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Global constructors attributes

This seems like a worthwhile change and I do support it but is it possible to 
make this fix behind a build flag or make it self-contained such that we can 
revert easily if needed?

While I do agree with you that the compatibility risk is probably small, I'd 
like to make sure we have an option of being able to revert the change or 
disabling the fix if we did find a compatibility issue later.

On Wed, Apr 17, 2013 at 11:32 AM, Christophe Dumez - SISA 
ch.du...@partner.samsung.commailto:ch.du...@partner.samsung.com wrote:
Hi,

According to the Web IDL specification [1] (still valid in the latest Editor 
Draft [2]), global constructors should have the following attributes:
{ [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }

Quoting from the specification:


For every interfacehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-interface that:

  *   is a callback 
interfacehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-callback-interface that 
has constantshttp://dev.w3.org/2006/webapi/WebIDL/#dfn-constant declared on 
it, or
  *   is a non-callback 
interfacehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-interface that is not 
declared with the 
[NoInterfaceObject]http://dev.w3.org/2006/webapi/WebIDL/#NoInterfaceObject 
extended 
attributehttp://dev.w3.org/2006/webapi/WebIDL/#dfn-extended-attribute,

a corresponding property must exist on the ECMAScript global object. The name 
of the property is the 
identifierhttp://dev.w3.org/2006/webapi/WebIDL/#dfn-identifier of the 
interface, and its value is an object called theinterface object.

The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, 
[[Configurable]]: true }. The characteristics of an interface object are 
described in section 
4.4.1http://dev.w3.org/2006/webapi/WebIDL/#interface-objectbelow.



Currently, global constructors have the following attributes in WebKit, which 
is not according to spec:
{ [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: false }

This is causing some W3C compliance tests to fail, such as this one [3].

Behavior of other browsers:
- Firefox follows the specification
- Blink does not follow the specification
- IE9 follows partly the spec:
  * global constructors are not enumerable (according to spec)
  * global constructors are not deletable (not according to spec)

I don't think it is likely web sites rely on those global constructors being 
enumerable considering that they are not enumerable in both IE9 and Firefox. 
Making them deletable seems low risk to me as well.

I uploaded a patch proposal to bugzilla [4] to make WebKit follow this part of 
the spec. I would appreciate feedback from the rest of the community as this is 
a web-exposed behavior change.

Kr,
Christophe DUMEZ

[1] http://www.w3.org/TR/2012/CR-WebIDL-20120419/#es-interfaces
[2] http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces
[3] 
http://w3c-test.org/webapps/ProgressEvents/tests/submissions/Ms2ger/interface.html
 (2 last tests)
[4] https://bugs.webkit.org/show_bug.cgi?id=110573


___
webkit-dev mailing list
webkit-dev@lists.webkit.orgmailto: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] Cleaning House

2013-04-04 Thread Christophe Dumez - SISA
Hi,

EFL port is using Cairo, not Skia.

Kr,
Christophe DUMEZ.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Allan Sandfeld Jensen [k...@carewolf.com]
Sent: Thursday, April 04, 2013 11:39
To: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Cleaning House

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.

Regards
`Allan
___
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] build.webkit.org is down?

2013-02-16 Thread Christophe Dumez - SISA
Hi,

build.webkit.org appears to be down:
http://www.downforeveryoneorjustme.com/build.webkit.org

kr,
Christophe DUMEZ.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] build.webkit.org is down?

2013-02-16 Thread Christophe Dumez - SISA
Indeed. Thanks!

Christophe DUMEZ.


From: Mark Rowe [mr...@apple.com]
Sent: Saturday, February 16, 2013 10:26
To: Christophe Dumez - SISA
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] build.webkit.org is down?


On 2013-02-16, at 00:12, Christophe Dumez - SISA 
ch.du...@sisa.samsung.commailto:ch.du...@sisa.samsung.com wrote:

build.webkit.orghttp://build.webkit.org appears to be down:
http://www.downforeveryoneorjustme.com/build.webkit.org

I’ve fixed it.

- Mark

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] sln files with wrong line endings

2013-02-13 Thread Christophe Dumez - SISA
Hi,

The same thing has just happened to me. I managed to get rid of the changes to 
this file by doing:
git reset --hard

Kr,
Christope Dumez.

From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] 
on behalf of Eric Seidel [e...@webkit.org]
Sent: Thursday, February 14, 2013 08:23
To: WebKit Development
Subject: [webkit-dev] sln files with wrong line endings

We've had this come up before, but I figure I should ask on webkit-dev
to see if we have a solution. :)

Right now the Tools/DumpRenderTree/DumpRenderTree.vcxproj/DumpRenderTree.sln
file is in some sort of bad state such that my Git checkout can't seem
to not-modify the file.

I'm not sure if it's a Git bug, or a repository config bug.

But it means I can't seem to produce patches w/o modifying this file. :(

https://bugs.webkit.org/attachment.cgi?id=188263action=review

Thoughts?
___
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