Re: [webkit-dev] EFL port?

[Anders Carlsson]

> On Feb 14, 2017, at 3:08 AM, Gustavo Sverzut Barbieri 
> <barbi...@profusion.mobi> wrote:
> 
> yes,
> 
> Sad, but as no big company is using the webkit-efl port at the time,
> we have no (or few?) guys paid to hack on it full time.
> 
> My company is rather small, so we need backing customers to continue
> our work... like the current patchset to come.
> 
> Not ideal, but if we could at least keep WebKit-EFL build bots and try
> to keep them green would be of great help for smaller users like us.

Having to keep a port building when nobody is available to work on it 
exclusively adds a lot of burden. We’ve had other in similar positions removed 
simply so we could move WebKit forward.

Konstantin Tokarev maintains a Qt port at https://github.com/annulen/webkit 
<https://github.com/annulen/webkit> - sounds like you could do something like 
that.

- Anders

> 
> 
> 
> On Tue, Feb 14, 2017 at 1:01 AM, Gyuyoung Kim <gyuyoung@webkit.org 
> <mailto:gyuyoung@webkit.org>> wrote:
>> Hi,
>> 
>> I agree that we should have enough people to keep EFL port on upstream.
>> 
>> Unfortunately I guess there will be no enough people to maintain EFL port
>> even If I've done my internal work.
>> So, If other maintainers or volunteers put their hand up for EFL port, it
>> seems to me that EFL port has a time to go downstream.
>> 
>> Gyuyoung.
>> 
>> 
>> On Tue, Feb 14, 2017 at 3:35 AM, Alex Christensen <achristen...@apple.com>
>> wrote:
>>> 
>>> Are there enough people working on EFL that we could ping someone with a
>>> desired architecture improvement and have them do significant code redesign
>>> in a reasonable amount of time?  We can add stubs and do minor things
>>> blindly, but sometimes bigger tasks require cooperation.  For example,
>>> https://bugs.webkit.org/show_bug.cgi?id=167096 should also be done on the
>>> EFL WebGL implementation.
>>> 
>>> On Feb 13, 2017, at 3:08 AM, Gustavo Sverzut Barbieri
>>> <barbi...@profusion.mobi> wrote:
>>> 
>>> Hi guys,
>>> 
>>> I have a small team working with WebKit-EFL as well, we're working on
>>> a different platform supported by EFL but not WebKit-EFL, so it's a
>>> series of minor patches to allow WebKit-EFL to run on Fbdev and
>>> without GL stack.
>>> 
>>> Patches will reach bugs.webkit.org soon.
>>> 
>>> 
>>> On Sat, Feb 11, 2017 at 2:10 AM, Joonghun Park <sypjh0...@hotmail.com>
>>> wrote:
>>> 
>>> Hi, Anders.
>>> 
>>> 
>>> You could count me as a member of EFL port too.
>>> 
>>> I couldn't get in touch with EFL port because of some internal works,
>>> 
>>> but I'm planning to work in it.
>>> 
>>> 
>>> Some other people of EFL port is in the same situation, but I think
>>> they'll
>>> get back sooner or later.
>>> 
>>> 
>>> 
>>> - Joonghun (jh718.p...@samsung.com)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> From: webkit-dev-boun...@lists.webkit.org
>>> <webkit-dev-boun...@lists.webkit.org> on behalf of Anders Carlsson
>>> <ander...@apple.com>
>>> Sent: Friday, February 10, 2017 6:21 PM
>>> To: Gyuyoung Kim
>>> Cc: WebKit-Dev Development
>>> Subject: Re: [webkit-dev] EFL port?
>>> 
>>> Hi,
>>> 
>>> Are you the only one working on the EFL port?
>>> 
>>> - Anders
>>> 
>>> On Feb 10, 2017, at 1:40 AM, Gyuyoung Kim <gyuyoung@webkit.org> wrote:
>>> 
>>> Hello,
>>> 
>>> To be honest, very few people have worked for EFL port recently. In my
>>> case
>>> it was hard to maintain EFL port because of internal work.
>>> However I have a plan to improve EFL port after I finish the work. Even I
>>> opened a website for EWebKit. http://www.ewebkit.org.
>>> Besides I released EWebKit 1.18 version[1] for EFL 1.18 official release.
>>> Could you give me more time for EFL port ?
>>> 
>>> Gyuyoung.
>>> 
>>> 
>>> [1] EWebKit 1.18 release announcement.
>>> 
>>> 
>>> https://phab.enlightenment.org/w/efl_and_elementary_1_18_release_announcement/
>>> 
>>> EWebkit
>>> 
>>> Together with this release we are happy to announce that the EWebkit team
>>> is
>>> doing a
>>> release with their work matching the efl 1.1

Re: [webkit-dev] EFL port?

[Anders Carlsson]

Hi,

Are you the only one working on the EFL port?

- Anders

> On Feb 10, 2017, at 1:40 AM, Gyuyoung Kim <gyuyoung@webkit.org> wrote:
> 
> Hello,
> 
> To be honest, very few people have worked for EFL port recently. In my case 
> it was hard to maintain EFL port because of internal work.
> However I have a plan to improve EFL port after I finish the work. Even I 
> opened a website for EWebKit. http://www.ewebkit.org 
> <http://www.ewebkit.org/>.
> Besides I released EWebKit 1.18 version[1] for EFL 1.18 official release. 
> Could you give me more time for EFL port ?
> 
> Gyuyoung.
> 
> 
> [1] EWebKit 1.18 release announcement.
> 
> https://phab.enlightenment.org/w/efl_and_elementary_1_18_release_announcement/
>  
> <https://phab.enlightenment.org/w/efl_and_elementary_1_18_release_announcement/>
> EWebkit
> Together with this release we are happy to announce that the EWebkit team is 
> doing a
> release <https://github.com/Gyuyoung/ewebkit/archive/ewebkit-1.18.zip> with 
> their work matching the efl 1.18.
> It contains various webkit core as well as EWebkit specific enhancements. See 
> the
> NEWS file <https://github.com/Gyuyoung/ewebkit/blob/ewebkit-1.18/NEWS> for 
> details and the http://www.ewebkit.org <http://www.ewebkit.org/> page for 
> further instructions on
> building. We hope to keep future releases of EWebkit aligned with the EFL 
> release schedule.
> 
> 
> 
> 
> 
> 
> 
> On Fri, Feb 10, 2017 at 9:42 AM, Anders Carlsson <ander...@apple.com 
> <mailto:ander...@apple.com>> wrote:
> Hello,
> 
> Looks like the EFL port isn’t really being worked on anymore. Is this true? 
> Can we rip it out?
> 
> - Anders
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> <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] EFL port?

[Anders Carlsson]

Hello,

Looks like the EFL port isn’t really being worked on anymore. Is this true? Can 
we rip it out?

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

Re: [webkit-dev] Terminate handler for WebKit

[Anders Carlsson]

On macOS and iOS, we already get this by setting NSApplicationCrashOnExceptions 
in our initialize function.

- Anders

> On Sep 9, 2016, at 10:14 AM, Michael Catanzaro  wrote:
> 
> Hi,
> 
> The GTK+ port currently has an interesting web process crash on exit:
> 
> pure virtual method called
> terminate called without an active exception
> 
> I found the easiest way to debug it was to rebuild with a terminate
> handler set:
> 
> std::set_terminate([] {
> CRASH();
> });
> 
> Even if such issues are very rare, I think it makes sense to set this
> up always, since a simple backtrace is a lot better than nothing in
> such cases. Are there any objections to always setting this terminate
> handler? For my debugging today, I put it in
> WebKit::ChildProcess::initialize, which seems like a decent place, but
> maybe not the best place. Are there any other suggestions for where to
> put this code? I presume this would be desired for all ports, but we
> could certainly do it somewhere platform-specific if that's not the
> case.
> 
> Michael
> ___
> 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] REQUEST_ANIMATION_FRAME on all ports?

[Anders Carlsson]

> On Jun 8, 2016, at 2:37 PM, Dean Jackson  wrote:
> 
> 
>> On Jun 8, 2016, at 2:23 PM, Konstantin Tokarev  wrote:
>> 
>> 
>> 
>> 08.06.2016, 23:59, "Dean Jackson" :
>>> Do the EFL and GTK ports always enable this feature? If so, I'm going to 
>>> remove the compile flag.
>> 
>> While I'm not opposed to this change, it looks like its maintenance cost is 
>> near zero.
> 
> I think we should remove guards for features that are (now) core to the Web.
> 
> Dean

I agree. Fewer flags in the code means fewer cases we have to think about.

- Anders

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

Re: [webkit-dev] KeyedEncoding: are decodeBytes() and encodeBytes() really needed?

[Anders Carlsson]

There are plans to use them in the future.

- Anders

> On Apr 28, 2016, at 10:24 AM, Konstantin Tokarev  wrote:
> 
> Hello,
> 
> It looks like that KeyedDecoder::decodeBytes() and 
> KeyedEncoder::encodeBytes() are not used anywhere in codebase. Are these 
> methods a dead code, or they exist for the sake of completeness? Are there 
> any plans to use them in future?
> 
> -- 
> Regards,
> Konstantin
> ___
> 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] Build slave for JSCOnly Linux MIPS

[Anders Carlsson]

> On Apr 19, 2016, at 12:21 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 19.04.2016, 22:11, "Anders Carlsson" <ander...@apple.com>:
>>>  On Apr 19, 2016, at 12:09 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
>>> 
>>>  19.04.2016, 21:38, "Anders Carlsson" <ander...@apple.com>:
>>>>  I’d like us to switch over to using C++14 in WebKit2 so we can get the 
>>>> new generalized lambda capture 
>>>> (https://isocpp.org/files/papers/N3648.html), so we can capture move-only 
>>>> types in lambdas. According to 
>>>> https://gcc.gnu.org/projects/cxx-status.html that would require GCC 4.9.
>>> 
>>>  This code compiles fine with GCC 4.8 with -std=c++1y flag:
>>> 
>>>  auto f(std::unique_ptr ptr)
>>>  {
>>> [value = std::move(ptr)] {return *value;};
>>>  }
>> 
>> GCC 4.8 has “partial” support, which may or may not be OK for our purposes. 
>> I’d rather be safe than sorry.
> 
> From https://gcc.gnu.org/gcc-4.9/changes.html#cxx:
> 
> "
> G++ supports C++1y lambda capture initializers:
> 
>[x = 42]{ ... };
> 
> Actually, they have been accepted since GCC 4.5, but now the compiler doesn't 
> warn about them with -std=c++1y, and supports parenthesized and 
> brace-enclosed initializers as well. 
> "
> 
> So it states pretty clearly what is supported only since 4.9

According do  https://gcc.gnu.org/projects/cxx-status.html 
<https://gcc.gnu.org/projects/cxx-status.html> (which I linked in original 
e-mail), GCC 4.5 has “partial” support.

- Anders

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

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Anders Carlsson]

> On Apr 19, 2016, at 12:09 PM, Konstantin Tokarev <annu...@yandex.ru> wrote:
> 
> 
> 
> 19.04.2016, 21:38, "Anders Carlsson" <ander...@apple.com>:
>> I’d like us to switch over to using C++14 in WebKit2 so we can get the new 
>> generalized lambda capture (https://isocpp.org/files/papers/N3648.html), so 
>> we can capture move-only types in lambdas. According to 
>> https://gcc.gnu.org/projects/cxx-status.html that would require GCC 4.9.
> 
> This code compiles fine with GCC 4.8 with -std=c++1y flag:
> 
> auto f(std::unique_ptr ptr)
> {
>[value = std::move(ptr)] {return *value;};
> }

GCC 4.8 has “partial” support, which may or may not be OK for our purposes. I’d 
rather be safe than sorry.

- Anders

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

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Anders Carlsson]

I’d like us to switch over to using C++14 in WebKit2 so we can get the new 
generalized lambda capture (https://isocpp.org/files/papers/N3648.html 
), so we can capture move-only 
types in lambdas. According to https://gcc.gnu.org/projects/cxx-status.html 
 that would require GCC 4.9.

- Anders

> On Apr 19, 2016, at 11:14 AM, Filip Pizlo  wrote:
> 
> I did a quick look over the trac query of GCC 4.8 changes that you provided.  
> None of the ones I looked at were scary but they were annoying.  They seemed 
> to be things like:
> 
> - Sometimes saying { } to initialize a variable doesn’t work.
> - Sometimes you need to say “const”.
> - Sometimes you need to play with variables to get around internal compiler 
> errors.
> 
> I didn’t find any cases of GCC 4.8 not supporting a language feature that we 
> want to use.  Do you think that’s correct?
> 
> -Filip
> 
> 
>> On Apr 19, 2016, at 11:02 AM, Michael Catanzaro  
>> wrote:
>> 
>> Hi,
>> 
>> On Mon, 2016-04-18 at 17:27 -0700, Filip Pizlo wrote:
>>> I am sympathetic to the principle that we should support the
>>> compilers that ship on the most popular versions of Linux.
>> 
>> Great. :)
>> 
>>> I’d like to understand if that argument is sufficient to support GCC
>>> 4.8.
>>> 
>>> Can you clarify, is it the case that if I installed the latest stable
>>> Fedora, I’d get GCC 4.8?
>> 
>> No, all currently-supported versions of Fedora include GCC 5 (only).
>> Different distros have very different release cycles and policies for
>> compiler upgrades. Fedora releases roughly every six months, and each
>> release is supported for roughly 13 months. GCC releases once per year.
>> The GCC developers coordinate with Fedora release planning to time GCC
>> releases to coincide with spring Fedora releases; in the winter before
>> a new GCC release, we rebuilt all of Fedora with the GCC beta so the
>> GCC developers can collect bug reports. So we will never have issues
>> with Fedora, as the oldest Fedora will be at most one year behind
>> upstream GCC. (Note that I co-maintain the WebKitGTK+ package there and
>> I'm making sure all supported Fedoras get updates.)
>> 
>> But Fedora is exceptional in this regard. Other distros are supported
>> for much longer than 13 months (5 years for Ubuntu LTS and newly also
>> for Debian, 10 years for enterprise distros) and therefore have much
>> older compilers. The question is where do we draw the line. We
>> obviously cannot support a 10 year old distro; those are maintained by
>> rich corporations, and if they cared about WebKit security, they could
>> take responsibility for that. We could handle 5 years, but do we really
>> want to? (It's clear Apple doesn't.) It's really inconvenient to not
>> have access to newer dependencies or language features for so long. We
>> might start by saying that we only support the latest release of [list
>> of major distros that have recently been shipping WebKit updates]. Most
>> of these distros are currently built using GCC 4.9, though they might
>> have GCC 5 or GCC 6 packaged as well, but not used by default. The big
>> one still using GCC 4.8 is openSUSE.
>> 
>> We don't *need* to consider Ubuntu right now, because they rarely ever
>> take our updates, nor Debian, because they never take our updates. I
>> think WebKit updates for Debian is all but totally a lost cause, but
>> I'm kinda still hopeful for Ubuntu, so I'd like to keep them in mind.
>> 
>> Also, different distros have different policies on using alternative
>> compilers. E.g. in Fedora we are usually required to always use
>> Fedora's GCC, and only one version is available at a time... but if a
>> package *really* has no chance of being built with GCC, we're allowed
>> to use Fedora's Clang instead. I'm not sure what the policies are for
>> Debian and Ubuntu, but they always have available a newer GCC than is
>> used for building packages, and until recently were using Clang to
>> build Chromium, so alternative compilers must be permitted at least in
>> exceptional cases. I was trying to convince the openSUSE folks to use
>> Clang to build WebKit, to avoid the GCC 4.8 issue, but they were not
>> enthusiastic. (But consider that all these distros will have older
>> versions of Clang as well.)
>> 
>> Now, whether openSUSE is important enough on its own to justify holding
>> back or lowering our GCC requirement... maybe not. But anyway, since we
>> have significant contributors like Konstantin stuck with GCC 4.8, and
>> since this doesn't require giving up on any significant language
>> features, I think it's OK. If it's only a little work to support that
>> compiler (on the level we already have in trunk), I think it's a good
>> idea.
>> 
>> But there is another problem here. openSUSE seems to have no intention
>> of upgrading to a newer GCC anytime soon, because they have started to
>> inherit core 

Re: [webkit-dev] Build slave for JSCOnly Linux MIPS

[Anders Carlsson]

I also don’t think we should require different versions of GCC for different 
projects. 

- Anders

> On Apr 18, 2016, at 12:50 PM, Filip Pizlo  wrote:
> 
> I don't want a buildbot for MIPS. It's not a relevant architecture anymore. I 
> don't think that JSC developers should have to expend effort towards keeping 
> this architecture working.
> 
> -Filip
> 
>> On Apr 18, 2016, at 12:36 PM, Konstantin Tokarev  wrote:
>> 
>> Hello,
>> 
>> I'd like to run build slave for MIPS port of JSC (with JSCOnly port on 
>> Linux). On the first iteration it will just ensure that compilation is not 
>> broken, afterwards I'm planning to add running tests on target.
>> 
>> However, I'm planning to use cross-toolchain based on GCC 4.8.4 (for now, 
>> the latest one supplied by Broadcom), and unmodified tree won't build 
>> because of GCC version check in Source/WTF/wtf/Compiler.h.
>> 
>> Are there any objections for lowering GCC requirement from 4.9.0 to 4.8.4 
>> (only for JavaScriptCore without B3)? I'm going to fix arising compilation 
>> errors myself.
>> 
>> -- 
>> Regards,
>> Konstantin
>> ___
>> 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] Improving the flexibility of the cookie manager

[Anders Carlsson]

Hello,

I don’t think we want to have clients of WebKit2 manage cookies themselves - 
that’s something the networking stack should do.

- Anders

> On Apr 17, 2016, at 5:57 AM, Drew DeVault  wrote:
> 
> I'm looking into making a few patches that make the cookie manager more
> flexible, and I'm stopping by the ML to see if anyone has
> concerns/advice about this first. I'm using WebKitGTK, and in webkit1,
> it was possible to have the UA manage the cookie store for more subtle
> behaviors that aren't in the scope of webkit. In webkit2, the cookie
> manager was introduced and is much less flexible with respect to cookie
> policies and manipulating the cookie store. There's also issues with
> sharing cookies between processes in a multiprocess browser.
> 
> I have a two ideas around strategies to improve this:
> 
> 1. Make WebKitCookieManager subclassable and have the UA provide their
> own implementation if they need more flexibility.
> 2. Add sufficient signals and APIs to WebKitCookieManager to allow the
> UA to effectively manage cookies themselves.
> 
> I'm leaning towards the second option. Would like to hear your thoughts.
> 
> --
> Drew DeVault
> ___
> 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] Proposal: Use #pragma once instead of header guards

[Anders Carlsson]

Yeah, I agree.

- Anders

> On Mar 9, 2016, at 6:46 PM, Michael Catanzaro <mcatanz...@igalia.com> wrote:
> 
> On Wed, 2016-03-09 at 17:27 -0800, Anders Carlsson wrote:
>> Hi floks,
>> 
>> Currently we use 
>> 
>> #ifndef Header_h
>> #define Header_h
>> 
>> … 
>> 
>> #endif
>> 
>> I propose that we instead start using
>> 
>> #pragma once
>> 
>> which does the same thing.
> 
> I think it's fine for the GTK port in general, but it would be nice to
> keep this out of our public headers. That is mostly just GTK-specific
> headers, but also the public JavaScriptCore headers JavaScript.h,
> JSBase.h, JSContextRef.h, JSObjectRef.h, JSStringRef.h, JSValueRef.h,
> and WebKitAvailability.h.
> 
> Michael

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

Re: [webkit-dev] Proposal: Use #pragma once instead of header guards

[Anders Carlsson]

I think we should put it where we currently have the header guard. I think the 
pragma is easier to understand than a #ifndef/#define.

- Anders

> On Mar 9, 2016, at 5:33 PM, Brian Burg <bb...@apple.com> wrote:
> 
> Cool! It sounds like something good for new headers and drive-by cleanups, to 
> start.
> To clarify, it would always go after the license block? Is the pragma name 
> stable and understandable enough to paste everywhere?
> 
>   -Brian
> 
>> On Mar 9, 2016, at 17:27, Anders Carlsson <ander...@apple.com> wrote:
>> 
>> Hi floks,
>> 
>> Currently we use 
>> 
>> #ifndef Header_h
>> #define Header_h
>> 
>> … 
>> 
>> #endif
>> 
>> I propose that we instead start using
>> 
>> #pragma once
>> 
>> which does the same thing. It can be faster on some compilers, is less error 
>> prone and is one line instead of three! All compilers we use support #pragma 
>> once.
>> 
>> Thoughts?
>> - 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

[webkit-dev] Proposal: Use #pragma once instead of header guards

[Anders Carlsson]

Hi floks,

Currently we use 

#ifndef Header_h
#define Header_h

… 

#endif

I propose that we instead start using

#pragma once

which does the same thing. It can be faster on some compilers, is less error 
prone and is one line instead of three! All compilers we use support #pragma 
once.

Thoughts?
- Anders

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

Re: [webkit-dev] Removing ENABLE(DATA_TRANSFER_ITEMS)

[Anders Carlsson]

While we do understand the value for your port in keeping these classes, WebKit 
has never had any obligations to downstream ports and forks. Nothing is 
stopping you from copying these files to your repository.

Gyuyoung, since nobody else has objected I think it’s fine to remove this.

- Anders


> On Jan 26, 2016, at 2:04 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 22.12.2015, 09:02, "Gyuyoung Kim" :
>> Hello,
>> 
>> It looks like no ports have used a data transfer items feature. Even the 
>> feature hasn't been updated since 2011. If anyone doesn't have a plan to use 
>> it in future, I plan to remove it. Any objections ?
> 
> In Qt port (I'm working on it downstream) we have implementations of 
> DataTransferItem and DataTransferItemList, please don't remove them.
> 
> 
> -- 
> Regards,
> Konstantin
> ___
> 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] PSA: WTF::move has been renamed to WTFMove

[Anders Carlsson]

Hi Andy,

see my comment in the bug.

- Anders

> On Jan 2, 2016, at 2:28 AM, Andy Estes  wrote:
> 
> Hi folks,
> 
> As of , WTF::move has been removed 
> and replaced with a macro named WTFMove. This allows us to take advantage of 
> some new warnings in clang while still retaining the checks provided by 
> WTF::move. More details can be found in 
> .
> 
> Happy new year!
> Andy
> ___
> 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] Support registerProtocolHandler in WebKit2

[Anders Carlsson]

 On May 20, 2015, at 11:32 PM, Benjamin Poulain benja...@webkit.org wrote:
 
 Looks llke nobody objects. 

That’s not true. From the bug:

Sam Weinig mailto:s...@webkit.org 2015-05-15 10:12:54 PDT
Support for navigator.registerProtocolHandler/unregisterProtocolHandler is not 
something we want to support in WebKit2 at this time as we are not confident it 
is a good Web API. This might be a good conversation for webkit-dev.


I agree with Sam.

- Anders


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

Re: [webkit-dev] [Proposal] Remove support for 'multipart/x-mixed-replace' main resources

[Anders Carlsson]

 On Apr 23, 2015, at 1:19 PM, Brady Eidson beid...@apple.com wrote:
 
 
 On Apr 23, 2015, at 1:11 PM, Chris Dumez cdu...@apple.com 
 mailto:cdu...@apple.com wrote:
 
 
 
 On Apr 23, 2015, at 1:07 PM, Brady Eidson beid...@apple.com 
 mailto:beid...@apple.com wrote:
 
 
 On Apr 21, 2015, at 3:39 PM, Chris Dumez cdu...@apple.com 
 mailto:cdu...@apple.com wrote:
 
 Hi,
 
 I would like to suggest we remove support for 'multipart/x-mixed-replace’ 
 main resources while keeping support for multipart images.
 
 Based on Chrome usage data, this feature is extremely rarely used by Web 
 sites (less than 0.1% of page loads) [1]. This feature adds complexity 
 to the loader and is a source of (security) bugs (e.g. [2] recently), 
 current support also seems buggy.
 
 Current support in Safari / WebKit:
 - Support is not great is WebKit. If you load a Motion JPEG main resource 
 for example, it will keep creating a new ImageDocument and all its DOM 
 tree for every frame (tested on Safari / Mac).
 - It looks like support is broken on Safari on iOS (I tried a Motion JPEG 
 main resource on iOS8, I see the first frame then a blank page that never 
 finishes loading).
 
 Other browsers:
 - Never supported by IE (including IE11) for any resource
 - Chrome already dropped support for this (main resources only) almost 2 
 years ago [3].
 - Firefox 37 still supports this based on local testing.
 
 Again, I am only proposing dropping support for main resources. For e.g., 
 having an IMG element in a page whose src attribute points to a Motion 
 JPEG would still work as intended.
 
 I think it’s fine to drop support for multipart main resources besides 
 MPJEG.
 
 I think loading MJPEG as a main resource and having it be displayed as an 
 ImageDocument is a valuable feature, and I object to dropping support for 
 it. I’m not sure if that’s what you’re proposing, since it’s both a main 
 resource and a multipart image.
 
 Yes, my proposal would break MJPEG as main resource. MJPEG is the main user 
 of 'multipart/x-mixed-replace’ I believe. If we do want to keep supporting 
 it, then we should probably fix support on both Mac (keeps recreating the 
 ImageDocument) and iOS (Only shows the first frame).
 
 I think fixing those two known and obvious issues is a great idea. If there’s 
 bugzillas on them I’d like to be CC’ed (same for Radars)
 
 Thanks,
  Brady

Given that so few browsers support this I think we should get rid of this 
feature; it would let us simplify the loader code significantly.

- Anders


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

Re: [webkit-dev] WebCore/platform standalone library

[Anders Carlsson]

 On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
 This almost makes me want to suggest a jokey name for Platform. I can’t off 
 the top of my head think of a good expansion of OMG, though. Or BBQ.

I think putting platform code in a separate namespace would be a good first 
step. Then we can weed out the layering violations and ultimately move 
everything to a separate library.

- Anders (who’s not going to propose any namespace names)


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

Re: [webkit-dev] WorkQueue for Windows?

[Anders Carlsson]

I think we used to have a WorkQueue implementation for Windows WK2 - anyone 
should be able to dig it up.

(Alternatively, we can just make an implementation using std::thread).

- Anders

 On Mar 6, 2015, at 10:46 AM, Antti Koivisto koivi...@iki.fi wrote:
 
 Hi,
 
 I'd like to start using WTF::WorkQueue abstraction in WebCore code. However 
 we are currently missing a Windows implementation (WorkQueue used to be part 
 of WK2). Anyone interested in making one? I assume it wouldn't be a difficult 
 task for someone who knows the platform.
 
 
antti
 ___
 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] Move WebKit Objective-C code to ARC?

[Anders Carlsson]

ARC doesn’t work on 32-bit Intel. It also doesn’t work with GC.

- Anders

 On Feb 24, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote:
 
 Hi folks.
 
 I believe that WebKit tip of tree on the Cocoa platforms now supports 
 platforms with a new-enough version of the Objective-C runtime that we could 
 move our Objective-C code to use ARC instead of manual retain/release. Does 
 anyone know of a reason we couldn’t start making this change to WebKit? I 
 thought of this when I saw recent patches Joe did to fix retain/release 
 mistakes with RetainPtr on Objective-C objects. Those mistakes would be 
 nearly impossible if we moved to ARC.
 
 — Darin
 ___
 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] Removing Web SQL Database support in workers

[Anders Carlsson]

Hello,

I’d like to remove support for Web SQL databases in workers. 

The whole specification has been deprecated (see 
http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/webdatabase/) and 
ditching the worker related database code will allow us to simplify the code a 
lot. 

FWIW, it looks like support has already been removed in Blink (and they 
deprecated the feature in July 2014 - see 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2SWnbXAL7Wg 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2SWnbXAL7Wg).

Unless anyone objects I’m going to start removing this next week.

- Anders

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

Re: [webkit-dev] Disk cache

[Anders Carlsson]

 On Nov 3, 2014, at 12:22 AM, Benjamin Poulain benja...@webkit.org wrote:

 I believe it would be better to enable the network process for all process 
 models. Maintaining multiple configurations for marginal gains is not 
 sustainable, especially in the network stack.

I agree 100%. Not to mention that we also want to get rid of the “single web 
process” code path, and just make it a special case of having multiple web 
processes with a maximum process cap of 1.

- Anders

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

[webkit-dev] PSA: WebKit2.framework - WebKit.framework

[Anders Carlsson]

Hi floks!

Tomorrow I’m going to land a patch that renames WebKit2.framework to 
WebKit.framework on OS X. (Only the framework, not the project or svn 
directory).

This is probably going to break the EFL and GTK+ ports because a bunch of 
header includes will become #include WebKit2/… instead of #include 
WebKit/…, but it shouldn’t be too hard to fix.

- Anders

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

[webkit-dev] Clearing out the review queue

[Anders Carlsson]

Hi floks!

In an attempt to get the review queue under control, hopefully leading to more 
and faster patch reviews, Andreas and I have been clearing the review flag on 
patches created before 2014.

If you have a patch whose review flag was clear and you still want it to be 
reviewed, please make sure that the patch still applies to trunk before 
re-requesting review.

Regards,
- Anders and Andreas


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

Re: [webkit-dev] Clearing out the review queue

[Anders Carlsson]

On Feb 5, 2014, at 11:22 AM, Anders Carlsson ander...@apple.com wrote:

 Hi floks!
 
 In an attempt to get the review queue under control, hopefully leading to 
 more and faster patch reviews, Andreas and I have been clearing the review 
 flag on patches created before 2014.

We decided to change this to patches created earlier than April 2013.

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

[webkit-dev] Subject: Windows CE port in WebKit: status, future work

[Anders Carlsson]

Hi floks,

looks like the last legitimate commit to the Windows CE port was on November 
3rd November 2013, almost 3 months ago.

I also seem to remember that there’s no version of MSVC for Windows CE that can 
handle the C++11 features that we now use in WebKit. (Correct me if I’m wrong 
on this!)

With this in mind, does it make sense to keep the Windows CE port in the tree 
or should we remove it?

Regards,
- Anders

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

Re: [webkit-dev] Subject: Windows CE port in WebKit: status, future work

[Anders Carlsson]

On Jan 31, 2014, at 1:36 PM, Patrick Gansterer par...@paroga.com wrote:

 On 31.01.2014, at 22:10, Anders Carlsson ander...@apple.com wrote
 
 looks like the last legitimate commit to the Windows CE port was on November 
 3rd November 2013, almost 3 months ago.
 
 What's the minimum upstream interval for downstream fixes to show ongoing 
 activity?

I don't think we've ever discussed such a thing, but when a project has no 
activity for three months people are going to start to wonder; it's happened in 
the past without anyone responding so thanks for doing that!

 I also seem to remember that there’s no version of MSVC for Windows CE that 
 can handle the C++11 features that we now use in WebKit. (Correct me if I’m 
 wrong on this!)
 
 Windows Embedded Compact 2013 updated the compiler for CE.

That's great news.

 
 With this in mind, does it make sense to keep the Windows CE port in the 
 tree or should we remove it?
 
 Does it hurt somebody in the daily workflow? If yes, where exactly?

I don't think it has affected anybody's daily workflow seriously. If it does in 
the future we can cross that bridge when we get to it.

Thanks,
- Anders

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

Re: [webkit-dev] GTK+ EWS bot lagging behind

[Anders Carlsson]

On Jan 28, 2014, at 3:43 AM, Gustavo Noronha Silva g...@gnome.org wrote:

 
 I was looking into it yesterday but had to drop it 'till today, it
 should be up and running in a couple hours, I think I managed to find
 the main issue.

Yeah, it seems to be chugging along nicely now. Thanks!

- Anders

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

Re: [webkit-dev] Make accelerated compositing mandatory

[Anders Carlsson]

On Jan 28, 2014, at 7:49 AM, Martin Robinson mrobin...@webkit.org wrote:

 Yes, GTK+ on Windows does not use accelerated compositing.

This begs the question: How widely used is the GTK+ port of WebKit on Windows? 
Do enough people use it that it's worth the maintenance burden for the other 
ports that use accelerated compositing?

- Anders

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

Re: [webkit-dev] Make accelerated compositing mandatory

[Anders Carlsson]

On Jan 28, 2014, at 10:19 AM, Martin Robinson mrobin...@webkit.org wrote:

 On Tue, Jan 28, 2014 at 10:00 AM, Anders Carlsson ander...@apple.com wrote:
 This begs the question: How widely used is the GTK+ port of WebKit on
 Windows? Do enough people use it that it's worth the maintenance burden for
 the other ports that use accelerated compositing?
 
 An example of a browser that uses WebKitGTK+ on Windows is Midori:
 http://midori-browser.org/download/choose/

Is this the only project using WebKitGTK+ on Windows? How many people do you 
think use it?

 If it is at-all helpful, we don't have WebKit2 support for the GTK+
 port on Windows. So if the majority of the maintanance burden is in
 WebKit2, there should be no problem with removing the non-AC code in
 WebKit2.

I don’t think we’ve ever had a problem with accelerated compositing being 
disabled in WebKit2. (I don’t know if anyone ever built without it).

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.

(FWIW, for the last two years or so WebKit2 on Mac has been running with 
accelerated compositing on always, and I strongly suspect this is the general 
direction other ports are taking too).

- Anders

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

Re: [webkit-dev] Make accelerated compositing mandatory

[Anders Carlsson]

On Jan 28, 2014, at 10:47 AM, Martin Robinson mrobin...@webkit.org wrote:

 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.

Great! I’d be happy to review any patches to do this.

Since we don’t have any WebKitGTK+/Windows buildbots or EWS bots, I think 
Andrei should go ahead and remove the flag and then the GTK+ maintainers can 
fix WebKitGTK+ for Windows. Does that sound like a reasonable approach?

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

[webkit-dev] PSA: COMPILE_ASSERT_MATCHING_ENUM is a bad idea

[Anders Carlsson]

Hi floks!

I noticed that both the EFL port and GTK+ port use a 
COMPILE_ASSERT_MATCHING_ENUM macro to make sure that WebCore enum values map to 
API enum values correctly, for example:

COMPILE_ASSERT_MATCHING_ENUM(WEBKIT_WEB_NAVIGATION_REASON_LINK_CLICKED, 
NavigationTypeLinkClicked);

This means that we can’t add new enums declarations (unless they’re added at 
the end) without breaking the build.

Instead of doing this (and then just blindly casting between the API layer and 
WebCore enum types), use conversion functions, like this (taken from WebKit2):

 inline WebCore::PageVisibilityState 
 toPageVisibilityState(WKPageVisibilityState wkPageVisibilityState)
 {
 switch (wkPageVisibilityState) {
 case kWKPageVisibilityStateVisible:
 return WebCore::PageVisibilityStateVisible;
 case kWKPageVisibilityStateHidden:
 return WebCore::PageVisibilityStateHidden;
 case kWKPageVisibilityStatePrerender:
 return WebCore::PageVisibilityStatePrerender;
 }
 
 ASSERT_NOT_REACHED();
 return WebCore::PageVisibilityStateVisible;
 }

I plan to audit the Mac and Windows ports and look for places where we cast 
between API enum types and WebCore enum types, and I filed 

https://bugs.webkit.org/show_bug.cgi?id=127800 WebKitGTK+ should stop using 
COMPILE_ASSERT_MATCHING_ENUM macros
https://bugs.webkit.org/show_bug.cgi?id=127801 EFL port should stop using 
COMPILE_ASSERT_MATCHING_ENUM macros

for the Mac and EFL ports respectively. I’m happy to answer any questions about 
this.

- Anders

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

[webkit-dev] GTK+ EWS bot lagging behind

[Anders Carlsson]

Hello,

there are currently 93 patches in the GTK+ EWS patch queue, is it stuck?

If it’s not, I think it’s completely unreasable to expect committers to wait 
for 93 patches to be processed before landing. (This lead to a problem this 
weekend where I removed code from WebCore that was used by GTK+ WebKit and I 
couldn’t tell because the patch was never processed!)

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

[webkit-dev] OVERRIDE and FINAL are GONE

[Anders Carlsson]

Hi floks!

Since all compilers we require now support the real override and final 
keywords, we’ve gone ahead and removed the uppercase macros. From now on, just 
use  the lowercase keywords!

Thanks,
- Anders

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

Re: [webkit-dev] Rename PLATFORM(MAC) to PLATFORM(COCOA)?

[Anders Carlsson]

On Jan 11, 2014, at 2:47 PM, Darin Adler da...@apple.com wrote:

 So, is PLATFORM(COCOA) an acceptable new name for what is currently named 
 PLATFORM(MAC)? If not, what’s a better choice?

I agree with Dan, I think PLATFORM(COCOA) is acceptable.

 Lets do this soon. It’s hard for me to remember that in WebKit, PLATFORM(MAC) 
 means “the Mac and iOS ports”.

One downside is that we won’t be able to make PLATFORM(MAC) mean “the Mac port” 
before all the uses have been audited and converted to PLATFORM(COCOA). I don’t 
know a good solution to that problem.

- Anders

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

Re: [webkit-dev] Rename PLATFORM(MAC) to PLATFORM(COCOA)?

[Anders Carlsson]

On Jan 11, 2014, at 3:19 PM, Darin Adler da...@apple.com wrote:

 
 On Jan 11, 2014, at 3:12 PM, Anders Carlsson ander...@apple.com wrote:
 
 
 One downside is that we won’t be able to make PLATFORM(MAC) mean “the Mac 
 port” before all the uses have been audited and converted to 
 PLATFORM(COCOA). I don’t know a good solution to that problem.
 
 My proposal is:
 
 1) Add PLATFORM(COCOA).
 2) Change PLATFORM(MAC) to PLATFORM(COCOA) quickly and mechanically before 
 making other changes.
 3) Add a PLATFORM(MAC) that is false for iOS.
 
 Then we can change various PLATFORM(COCOA) back to PLATFORM(MAC) if they 
 really meant PLATFORM(MAC), but that can be done gradually over time.

Sounds good!

- Anders

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

Re: [webkit-dev] How did Apple build libicucore.dylib?

[Anders Carlsson]

On Jan 10, 2014, at 1:45 PM, Eric Wing ewmail...@gmail.com wrote:

 (I tried webkit-help but didn't get any responses, so I thought maybe
 this list might be more appropriate for this question. Sorry for the
 duplicate if otherwise.)
 
 I am attempting to build JavaScriptCore for my own embedded
 application use. I noticed that Mac and iOS JavaScriptCore have a
 dependency on a library called libicucore.
 
 When I build ICU myself from the , I get a handful of different icu
 libraries, but nothing named core”.

Hi Eric,

the version of the source code shipped on OS X is available from 
http://www.opensource.apple.com/source/ICU/ICU-511.25/ so you can see how it’s 
done there.

Hope this helps,
- Anders

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

Re: [webkit-dev] Guideline for nullptr

[Anders Carlsson]

On Jan 6, 2014, at 12:01 PM, Dan Bernstein m...@apple.com wrote:

 
 
 Sent from my iPad
 
 On Jan 6, 2014, at 11:55 AM, Darin Adler da...@apple.com wrote:
 
 I suggest we use nullptr, rather than of 0 or NULL, for all pointer nulls in 
 WebKit C++ sources. I don’t see any advantage to using 0 or NULL over 
 nullptr, and nullptr has multiple advantages. Three obvious ones: Compile 
 time error if accidentally passed to something expecting an integer, can be 
 distinguished from an integer in function overloading, can tell it’s a 
 pointer.
 
 Any objections?

I think this is a great idea and something I’ve been doing ever since nullptr 
became available to us.

 
 — Darin
 
 PS: Maybe even instead of nil in WebKit Objective-C++ code?
 
 In Objective-C++, nil is nullptr, so I suggest that we stick with the 
 language convention of writing it as nil.

I agree. (Also, using Nil for null classes).

- Anders

___
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

[Anders Carlsson]

On Dec 9, 2013, at 2:43 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:

 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

I’m about to land a patch that will require variadic templates, and I plan to 
do the same thing for range-based for loops. These are both supported by GCC 
4.6.

Going forward I’d really like us to start using template aliases, which is a 
4.7 feature. If that’s a problem we can hold off that for the time being.

- Anders

___
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

[Anders Carlsson]

On Dec 6, 2013, at 4:15 PM, Brent Fulgham 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

Re: [webkit-dev] Range based loops

[Anders Carlsson]

On Nov 10, 2013, at 6:17 AM, Van Den Berghe, Vincent 
vincent.vandenber...@bvdinfo.com wrote:

 Hello,
 
 I sincerely hope that the move to whatever version of Visual Studio will not 
 break compatibility with Visual Studio 2010.
 I'm usually the last person to cling to old versions, but the economic 
 reality is that for many shops, including mine, upgrading to the latest and 
 greatest Visual Studio makes little technological sense and even less 
 economic sense. Just saying but there's increased C++ compatibility and 
 oh-look-at-these-new-features doesn't convince the people holding the purse 
 strings.  And they are holding them very tightly indeed. With good reason.

We’d like to move to Visual Studio 2013 because it has many new useful C++11 
features that 2010 doesn’t have. It’s pretty obvious that by using these 
features we’re breaking compatibility with older versions.

(It should also be said that all the other compilers we use already support 
these features, and that VS is holding us back here).

 The faster release cadence (2-3 years post VS2010) between versions and the 
 unwillingness of Microsoft to provide support beyond a single service pack 
 (which they will chop up and rename to updates) made upgrading a very hard 
 sell for us developers.

As usual, the people contributing to the project get to decide this and 
everyone is very positive and excited about being able to make WebKit better by 
using these new features.

Regards,
- Anders

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

Re: [webkit-dev] [AppleMac] : HTML5 Video tag is enabled by MacOsX. But how does it work = and with which player by default ?

[Anders Carlsson]

Hello,

this series of mailing list threads seems more appropriate for the webkit-help 
list instead of webkit-dev.

Thanks,
- Anders

On Oct 15, 2013, at 6:37 AM, gstreamer MACOSX gstreamermac...@gmail.com wrote:

 First, thanks a lot for your useful tips, Konstantin, Hugo. 
 
 Second, let's assume I expect to change player:
 - from natural default solution = 
 Source/WebCore/platform/graphics/mac/MediaPlayerPrivateQTKit.*
 - to another one that is GSTREAMER
 
 What would be the trick to evolve properly from Quicktime to Gst ?
 Hugo told us about 
 Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
 but invited us to read 
 http://hackerslab.eu/blog/2013/01/migration-to-gstreamer-1-x-for-webkit/ as a 
 pre-requisite 
 
 However, I dare here to request safe and clear procedure to migrate properly, 
 efficiently.
 
 -- gstreamerForEver
 
 
 On Tue, Oct 15, 2013 at 2:22 PM, Konstantin Tokarev annu...@yandex.ru wrote:
 
 15.10.2013, 16:06, Hugo Machefer hugo.mache...@gmail.com:
  Precision: ENABLE_VIDEO seems to be set (by default) on MacOsX according to 
  rules defined within Tools/Scripts/webkitperl/FeatureList.pm
  Correct ?
 
 Actually, it is controlled by --[no-]video option of build-webkit (default 
 dependens on WebKit port chosen).
 
 --
 Regards,
 Konstantin
 
 ___
 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] Status of the Blackberry port

[Anders Carlsson]

Hi Eli,

I’m not sure what “still being maintained” means.

Looking in WebKit/blackberry, I see 9 changes from BlackBerry people since July 
and 24 changes from non-BlackBerry people. I’m also not sure that what’s in the 
WebKit repository even builds (which makes it really frustrating to make 
changes that touch BlackBerry code).

Looking forward to an update,
- Anders

On Oct 7, 2013, at 7:04 AM, Eli Fidler efid...@blackberry.com wrote:

 Yes, it's still being maintained by the folks here at BlackBerry.
 
 Eli
 
 
 
 On 13-10-05 7:12 PM, Sam Weinig wei...@apple.com wrote:
 
 Hello,
 
 Can anyone comment on the status of the Blackberry port?  Is it still
 being maintained?
 
 -Sam
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received this transmission in error, 
 please immediately reply to the sender and delete this information from your 
 system. Use, dissemination, distribution, or reproduction of this 
 transmission by unintended recipients is not authorized and may be unlawful.
 
 ___
 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] Heads-up: ENABLE_GESTURE_EVENTS removal

[Anders Carlsson]

Hello,

I’m planning to remove the ENABLE_GESTURE_EVENTS ifdef and related code. It was 
used by Chromium (and perhaps to some extent Qt) as well as WebKit2 for 
trackpad events before we switched over to wheel events (which is the 
recommended way to do things). From what I can see all the code in both WebKit2 
and WebCore is dead.

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

Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl

[Anders Carlsson]

On Oct 2, 2013, at 10:28 AM, Brent Fulgham bfulg...@apple.com wrote:

 Hi Anders,
 
 On Oct 1, 2013, at 6:19 PM, Anders Carlsson ander...@apple.com wrote:
 
 I just wanted to let everyone know that we (Apple) are moving away from 
 DrawingAreaImpl and always using our tiled drawing area. Longer term we’d 
 like to remove DrawingAreaImpl completely since it was designed back when we 
 didn’t run in accelerated compositing mode all the time.
 
 I believe that this only effects WebKit2, correct? If so, this will have no 
 impact on the Windows port or the WinCairo port.
 

Yup, it’s WebKit2 only.

- Anders

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

Re: [webkit-dev] PSA: WebKit2 and DrawingAreaImpl

[Anders Carlsson]

On Oct 1, 2013, at 11:29 PM, Sergio Villar Senin svil...@igalia.com wrote:

 On 02/10/13 03:19, Anders Carlsson wrote:
 Hello,
 
 I just wanted to let everyone know that we (Apple) are moving away from 
 DrawingAreaImpl and always using our tiled drawing area. Longer term we’d 
 like to remove DrawingAreaImpl completely since it was designed back when we 
 didn’t run in accelerated compositing mode all the time.
 
 It’s my understanding that all the other non-mac ports use coordinated 
 graphics now, and so the logical step would be to create a special 
 DrawingArea subclass for coordinated graphics and move the relevant code 
 there. That’d allow us to remove DrawingAreaImpl and LayerTreeHost.
 
 GTK is not using coordinated graphics, we do WebProcess compositing.

I see. Are you ever not in accelerated composited mode?

- Anders


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

[webkit-dev] PSA: WebKit2 and DrawingAreaImpl

[Anders Carlsson]

Hello,

I just wanted to let everyone know that we (Apple) are moving away from 
DrawingAreaImpl and always using our tiled drawing area. Longer term we’d like 
to remove DrawingAreaImpl completely since it was designed back when we didn’t 
run in accelerated compositing mode all the time.

It’s my understanding that all the other non-mac ports use coordinated graphics 
now, and so the logical step would be to create a special DrawingArea subclass 
for coordinated graphics and move the relevant code there. That’d allow us to 
remove DrawingAreaImpl and LayerTreeHost.

I’d be more than happy to review any patches to do this, and answer any 
questions.

Thanks,
- Anders



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

Re: [webkit-dev] Announcing new port: Nix

[Anders Carlsson]

On 13 sep 2013, at 01:58 em, Hugo Lima hugo.l...@openbossa.org wrote:

 On Fri, Sep 13, 2013 at 4:31 PM, Antonio Gomes toniki...@webkit.org wrote:
 So will you advocate your users to use your external GitHub version or
 the one in
 WebKit?
 
 Please consider not being half upstream.
 
 It wont be half upstream, but the github repository will be for
 example a fallback for a working bleeding edge Nix just in case of
 WebCore changes that break Nix on webkit.org. We can also push things
 first there then on webkit.org if a faster development pace if needed,
 as all Nix developers use git this also means that experimental
 feature branches will exists on github repo too (don't tell me about
 create svn branches).

Please correct me if I’m misunderstanding this, but:

- You are OK with WebCore changes breaking the Nix port
- You are going to have a “stable fork” of Nix in another repository (GitHub).

If this is the case, what benefit does having the code upstream provide to the 
WebKit project as opposed to having it live out of tree and upstream changes 
that are of high value to the WebKit project itself. Note that I’m not against 
the Nix port, but maybe this would be a good way for a port to “prove that 
it’s worthy of being upstreamed. I don’t remember when the last port was added 
to WebKit, but I’m pretty sure it was many years ago and the project has 
changed significantly since then.

(I’m also a bit confused about why the Nix “Platform” layer needs to live in 
the WebKit repository - we don’t have Windows or AppKit headers in the 
repository and I don’t understand why Nix is different).

Thanks,
- Anders

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

Re: [webkit-dev] Plugin Process

[Anders Carlsson]

Hi Murali,

building Webkit2 with plug-in support but without the plug-in process is not 
supported anymore.

- Anders

On Sep 18, 2013, at 4:25 AM, murali billa muralibi...@gmail.com wrote:

 Hi,
 I want to know where plugin process is enabled by default in webkit2  for 
 multiprocess.Pls help me.
 
 Regds,
 Murali
 ___
 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] Plugin Process

[Anders Carlsson]

FWIW, I went ahead and removed the ENABLE_PLUGIN_PROCESS #define that may have 
caused some confusion.

- Anders

On Sep 18, 2013, at 10:09 AM, Anders Carlsson ander...@apple.com wrote:

 Hi Murali,
 
 building Webkit2 with plug-in support but without the plug-in process is not 
 supported anymore.
 
 - Anders
 
 On Sep 18, 2013, at 4:25 AM, murali billa muralibi...@gmail.com wrote:
 
 Hi,
 I want to know where plugin process is enabled by default in webkit2  for 
 multiprocess.Pls help me.
 
 Regds,
 Murali
 ___
 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] Announcing new port: Nix

[Anders Carlsson]

On Sep 12, 2013, at 1:58 PM, Hugo Lima hugo.l...@openbossa.org wrote:

 On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa rn...@webkit.org wrote:
 Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
 remember correctly, that layer had to be modified constantly as
 WebCore/WebKit code was refactored so I'm a bit worried about this.
 
 Yes, in fact we got some API from them.

This is my biggest concern with the Nix port; that it will end up exposing 
implementation details of our platform layer, making it harder for us to 
perform sweeping changes to said layer (for example, like what Darin is doing 
with his pasteboard cleanup patches).

In fact, it reminds me of the WebKit2 situation (before we instituted the build 
policy) where some changes that should in theory take days would end up taking 
weeks because of:

- Churn waiting for the EWS bots to do their thing.
- Churn due to patches being rolled out for breaking other ports (due to 
certain build flags being enabled in said ports).
- Churn due to patches being rolled out for breaking other ports (due to 
misconceptions about the correct WebKit2 semantics in said ports).

Maybe we would need a similar build policy for WebCore?

 But it sounds like you're suggesting that Nix port's maintainers will be
 responsible for making any code changes necessary to support
 WebCore/WebKit/WebKit2 refactoring?
 
 Yes, this is the idea, is our concern to keep our code working.

I am glad to hear that. Does that mean that we’re allowed to break the Nix port 
without having patches rolled out by members of the Nix team?

- Anders

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

Re: [webkit-dev] Can we disable control reaches end of non-void function warning on Qt?

[Anders Carlsson]

On Sep 12, 2013, at 4:45 PM, Allan Sandfeld Jensen k...@carewolf.com wrote:

 Don't worry we are still here, just in fewer numbers, and with fewer things 
 to 
 support. 

Hi Allan,

reading the article it seems to me like Qt WebKit is going into maintenance 
mode. Is this true?

Does this mean that you’ll create a svn branch and only backport certain 
patches (security fixes comes to mind) or will you still follow trunk?

Regards,
- Anders___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposed feature: Network Service Discovery

[Anders Carlsson]

I agree.

This also seems like it’s something that could be implemented by a client 
application using our JS object extension hooks without touching WebKit at all.

- Anders

On Sep 6, 2013, at 10:30 AM, Simon Fraser simon.fra...@apple.com wrote:

 Perhaps before we spend any more time discussing the security implications of 
 Network Service Discovery, we should decide whether it fits with the goals of 
 the WebKit project:
 
 https://www.webkit.org/projects/goals.html
 
 It’s not at all clear to me that it does.
 
 Simon
 
 On Sep 6, 2013, at 9:59 AM, Oliver Hunt oli...@apple.com wrote:
 
 
 On Sep 6, 2013, at 9:44 AM, youenn fablet youe...@gmail.com wrote:
 
 Hi Ryosuke,
 
 The two points you are mentioning make sense to me.
  
 
 For starters, most of users wouldn't even know what a local network is; let 
 alone what discovering media sources, etc... mean.
 
 Most users may not be able to understand what means “discover local network 
 DACP servers”.
 But if a user is requested to grant/deny access to “Bob music library” 
 service (the service being a DACP server), the situation seems getting 
 better.
 The spec is a work in progress and may be improved.
 
 For the sake of argument let's say this discovery is allowed to occur.  
 How do you talk to Bob music library without the web page sending raw data 
 to/from the DACP server?
 
 --Oliver
 ___
 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] Ports not building as C++11?

[Anders Carlsson]

On Jul 30, 2013, at 9:23 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:

 No, I don't have objections. :) I absolutely support switching to c++11,
 and I'm happy to add back the removed nullptrs and scoped enum values
 _after_ all ports switched to c++11.
 
 - cmake port did the switch by http://trac.webkit.org/changeset/153315
 - GTK did the switch by http://trac.webkit.org/changeset/150445
 - Qt and Win confirmed that they are going to do the switch, but I'm
 not sure if they already did it or not. Let the EWS bots notice us. :)
 
 Patch is coming soon in https://bugs.webkit.org/show_bug.cgi?id=119266

Excellent!

 But I suprised how c++11 became mandatory. If you had announced it
 before pushing the FTL patches, we would have easily avoid the tons of
 buildfixes removing c++11 features.

To clarify, this decision isn’t final yet - and has not yet been announced.

I sent this e-mail because I was under the impression that most/all ports were 
already building as C++11 and it came a surprise to find that this was not the 
case.

Regards,
- Anders

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

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

[Anders Carlsson]

On Jul 30, 2013, at 10:52 AM, Brent Fulgham bfulg...@apple.com wrote:

 I realize that CE 5, 6, and 7 are probably not top priorities for the 
 community, but these changes will basically force dropping support for those 
 platforms. We do have some interest in keeping WebKit working for our 
 downstream build, so if it’s possible to make this change over to using 
 C++11 in a way that can allow for building without the new features that 
 would be ideal. If there is anything we can do that help make this happen 
 let me know.
 
 I think the goal is to (at least initially) conditionalize the use of various 
 C++11 idioms.  But I think we will soon reach a critical mass where we will 
 assume the compiler supports the newer language constructs.

We’re already using C++11 features conditionally in WebKit. The plan is to move 
forward and make some features a requirement.

Patrick, given the broad support for this proposal from other 
ports/contributors we are going to ahead and move forward with it.

Regards,
- Anders

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

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

[Anders Carlsson]

Hello,

so it looks like we’re in a pretty decent shape when it comes to C++11 capable 
compilers. 

If we limit ourselves to GCC 4.6, MSVC 2010 and a fairly recent version of 
clang (Whatever comes with Xcode 4.6), we should be able to make use of a nice 
chunk of C++11 features. (See 
http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport for more details).

I think a good set of initial features to require is auto, nullptr, move 
semantics and not having to add a space after angle brackets in templates.

Unless anyone objects, I’ll prepare a patch for Compiler.h that adds the 
correct WTF_COMPILER_SUPPORTS #ifdefs, and adds an #error if any of 
WTF_COMPILER_SUPPORTS_CXX_AUTO, WTF_COMPILER_SUPPORTS_CXX_NULLPTR, 
WTF_COMPILER_SUPPORTS_CXX_RVALUE_REFERENCES are not defined.

Regards,
- Anders

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

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

[Anders Carlsson]

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

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

[Anders Carlsson]

On Jul 26, 2013, at 8:09 PM, Allan Sandfeld Jensen k...@carewolf.com wrote:

 On Friday 26 July 2013, Anders Carlsson wrote:
 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?
 
 Yes, and because C++11 is not supported on all the platforms we support.

Could you please elaborate? What compilers are you using?

 We don't all have the option to not care about the platforms of a certain 
 fruit 
 themed vendor's 1 or 2 year old operating systems.

I don’t think this comment adds anything constructive.

Thanks,
- Anders___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] ENABLE(PAGE_POPUP) in WebCore

[Anders Carlsson]

On May 20, 2013, at 5:00 AM, Carlos Garcia Campos carlo...@webkit.org wrote:

 El lun, 20-05-2013 a las 10:51 +0200, arvid2.nils...@gmail.com escribió:
 Hi there!
 
 
 This seems like a very reasonable request, the popups (used by the
 BlackBerry port to implement various pickers) seem to be mostly a
 WebKit concern, and we don't really seem to use any of the PAGE_POPUP
 related plumbing in WebCore.
 
 Yeah, I'm working on it, I hope to have something soon, not in 30
 minutes though :-)

That’s awesome, thanks much!

- Anders

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

[webkit-dev] WebKit2 and ENABLE_PLUGIN_PROCESS

[Anders Carlsson]

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

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

[webkit-dev] ENABLE(PAGE_POPUP) in WebCore

[Anders Carlsson]

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

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

Re: [webkit-dev] More C++11 in WebKit2!

[Anders Carlsson]

Hello,

that was not my intention. I was under the (wrong) impression that range-based 
for existed in VS2010. I'll back that change out.

- Anders

On Apr 28, 2013, at 1:26 PM, Hausmann Simon simon.hausm...@digia.com wrote:

 Hi,
 
 Just for clarification: This means dropping support for Visual Studio 2010 
 and requiring 2012 (released about a year ago).
 
 Simon
 
 Anders Carlsson ander...@apple.com wrote:
 
 
 Hello everyone,
 
 just a friendly heads-up that I intend to land 
 https://bugs.webkit.org/show_bug.cgi?id=115259 soon, which makes use of three 
 more C++11 features, namely:
 
 - Not requiring a space between right angle brackets in templates.
 - Range-based for loops
 - Auto.
 
 Looks like the EFL and Qt ports need to start building as C++11! The rest of 
 the ports are fine.
 
 Thanks,
 - 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

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

Re: [webkit-dev] What do we do with various Web component features?

[Anders Carlsson]

On Apr 27, 2013, at 2:38 PM, Benjamin Poulain benja...@webkit.org wrote:

 On Fri, Apr 26, 2013 at 9:46 PM, Ryosuke Niwa rn...@webkit.org wrote:
 There appears to be a lot of Web component related features in WebKit that 
 used to be maintained by Chromium contributors; specifically those related to 
 Shadow DOM and node distributions.
 
 What do we do with them? The specification is still under the construction 
 and our implementation is getting outdated day by day.
 
 I certainly see the value of the proposed specification, and I would like it 
 to be shipped by WebKit browsers. However, having unmaintained code that is 
 this invasive in WebCore is very harmful in short term.
 
 Is anyone stepping up to maintain the code, or should we consider removing 
 them for the time being?
 
 All that unmaintained code has a cost we should not have to pay.
 
 I am in favor of removing it and bring the code back later when someone 
 decide to support that spec.

+1

From what I’ve heard, the Shadow DOM changes have negatively impacted the 
packability of the DOM code which is unfortunate. I’m all for removing it.

- Anders


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

Re: [webkit-dev] More C++11 in WebKit2!

[Anders Carlsson]

On Apr 28, 2013, at 1:00 PM, Geoffrey Garen gga...@apple.com wrote:

 Hi Mikhail.
 
 In continuation of the topic I'd like also to know people's opinion about 
 Pass*Ptr types deprecation:
 
 I don't think this is appropriate until the compilers on all our major target 
 platforms support C++11. I believe Windows is currently the primary barrier.
 
 Once we have C++11 on all our major target platforms, I think it would great 
 to adopt C++11 idioms throughout the project. 
 
 I believe that part of our reasoning for deploying C++11 idioms in WebKit2 is 
 that it meets this criterion.

I agree.

In WebKit2 we have much more freedom to do C++11 experimentation, both due to 
not having to think about Windows but also due to the fact that WebKit2 is 
about one fifth the size of WebCore when it comes to number of lines of code.

When we come up with successful C++11 design patterns and idioms in WebKit2, we 
can apply them to WebCore when the time is ready. (One thing I’m playing with 
in WebKit2 is to stop using PassOwnPtr and just using std::move instead).

- Anders

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

[webkit-dev] More C++11 in WebKit2!

[Anders Carlsson]

Hello everyone,

just a friendly heads-up that I intend to land 
https://bugs.webkit.org/show_bug.cgi?id=115259 soon, which makes use of three 
more C++11 features, namely:

- Not requiring a space between right angle brackets in templates.
- Range-based for loops
- Auto.

Looks like the EFL and Qt ports need to start building as C++11! The rest of 
the ports are fine.

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

Re: [webkit-dev] Cleaning House

[Anders Carlsson]

On Apr 4, 2013, at 2:01 AM, Raphael Kubo da Costa rak...@webkit.org wrote:

 Geoffrey Garen gga...@apple.com writes:
 
 Also:
  Adopt libc++
 
 My FreeBSD hat appreciates that, but can you elaborate? Is there
 something specific to libc++ not present in, say, libstdc++, that is
 going to be used?

I think this should be “require libc++ on Mac”. The Chromium port used 
libstdc++ since it had to build on Snow Leopard as well IIRC.

- Anders


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

[webkit-dev] Heads-up: C++11 and WebKit2

[Anders Carlsson]

Hello everyone,

Some time ago we started using C++11 in the Mac port of WebKit2. In the near 
future we’re going to expand our use of C++11 in the WebKit2 codebase. 
Specifically, we’d like to make use of rvalue references and move semantics in 
our IPC code to avoid needlessly copying data and to give some serializable 
objects (such as Mach ports) better semantics. 

If you’re a port that is building WebKit2, you're probably already building 
with a compiler that supports rvalue references; according to 
http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport, support for move 
semantics exists in Visual Studio 2010 and later, as well as GCC 4.3 and later 
(and any reasonable modern version of clang).

- Anders

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

[webkit-dev] WebKit2/Mac and C++11

[Anders Carlsson]

Hello!

This is just a friendly heads-up that the Mac specific parts of WebKit2 will 
soon start requiring C++11 features (move semantics and variadic templates 
being the two most important).

Any recent version of Xcode (4.2 or later) should support this, and we're 
already building all of WebKit2 as C++11 on Mac anyway.

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

Re: [webkit-dev] String::operator+= considered harmful

[Anders Carlsson]

On Sep 4, 2012, at 5:52 PM, Benjamin Poulain benja...@webkit.org wrote:

 On Tue, Sep 4, 2012 at 4:22 PM, Adam Barth aba...@webkit.org wrote:
 Removing operator+= will likely require changes to a number of
 port-specific files.  I'll do my best to remove these, but I might
 need some help from maintainers of individual ports.  If you're
 interested in helping out, please let me know.
 
 You did an amazing work cleaning WebKit. I'll help on you finish on the Mac 
 port. I will look at that today.
 
  If operator+= cannot be made sufficiently efficient, we could always leave 
  the operator there, but have it ASSERT with a message saying to use 
  StringBuilder.
 
 That's a nice idea with a compile-time failure. It would be a new error-based 
 documentation system :)

You could just keep the operator+= declaration, but omit the definition (and 
explicitly mark it deleted when building with a compiler that supports that 
part of the C++11 spec).

- Anders

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

Re: [webkit-dev] Tab focus order for plugins

[Anders Carlsson]

Hi Fady,

I went ahead and reviewed this.

- Anders

On Jun 26, 2012, at 10:28 AM, Fady Samuel fsam...@chromium.org wrote:

 Oops, lost the link in the email: 
 https://bugs.webkit.org/show_bug.cgi?id=88958
 
 On Tue, Jun 26, 2012 at 1:26 PM, Fady Samuel fsam...@chromium.org wrote:
 Hi all,
 
 ap@ is away until July 18, and I was hoping to get some feedback on this 
 change for the WebCore changes.
 
 In a nutshell, we'd like certain plugins in chromium to participate in tab 
 focus. My understanding from a recent thread in whatwg is that which controls 
 participate in the tab focus cycle is up to the UA.
 
 This change plumbs this decision out of WebCore to allow the WebKit embedder 
 to decide whether or not to allow a plugin to participate in tab order on a 
 per-plugin basis.
 
 Are there any thoughts or objections to this patch?
 
 By default, nothing changes. However certain plugins can choose to 
 participate in the tab focus order, if they support it.
 
 Thanks,
 
 Fady
 
 ___
 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 namespace std

[Anders Carlsson]

On May 17, 2012, at 12:33 PM, Peter Kasting pkast...@chromium.org wrote:

 On Thu, May 17, 2012 at 12:02 PM, Ryosuke Niwa rn...@webkit.org wrote:
 It appears to me using fully qualified names (e.g. std::max(~) at call site) 
 is far superior to using directive for individual symbols (e.g. using 
 std::max).
 
 It sounds in general like a number of people have been in favor of this, and 
 there hasn't been any opposition.
 
 Should we say that the rule for things in std:: is to qualify at the callsite 
 rather than use either form of a using directive?  Is there any disagreement 
 with doing that?

Go for it!

- Anders


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

Re: [webkit-dev] Using namespace std

[Anders Carlsson]

On May 16, 2012, at 9:31 AM, Darin Adler da...@apple.com wrote:

 On May 16, 2012, at 9:20 AM, Allan Sandfeld Jensen wrote:
 
 there is another conflict which is entirely our own fault. It is between 
 WTF::bind and the new std::bind from C++11
 
 We should find a good solution for this. I’d suggest talking with Anders 
 Carlsson about it.

I've run into this and had to use the fully qualified WTF::bind in those cases.

FWIW, I don't think we really need using directives for the std namespace - the 
fully qualified name is short enough and I like the additional clarity that 
we're calling something in the standard library.

- Anders
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How do I turn off timeout for unresponsive plug-ins, to allow long debug sessions

[Anders Carlsson]

Hi Rudi,

in if you're running Safari with a WebKit nightly, you can disable the timeout 
using

defaults write com.apple.Safari WebKitDisablePluginProcessMessageTimeout YES

Hope this helps,
Anders

On Oct 7, 2011, at 2:59 PM, Rudi Sherry wrote:

 Is there a way to have Safari (or webkit) have an infinite timeout waiting 
 for the plugin process?  I need this for effective debugging.
 
 
 Since Safari creates the plugin process, loads my plugin and starts it up 
 when I click on a link, I can't pre-attach or pre-launch the plugin process.  
 So I go through the following:
 
 * Have a sleep loop in NP_GetEntryPoints in my plugin
 * Launch Safari
 * Click on a link to a file that will invoke my plugin
 (Safari will create PluginProcess)
 * In Xcode, attach to my plugin
 * Manually jump past the sleep-loop
 
 ...so far, so good.  Now my plug-in loads a very substantial framework where 
 I have some breakpoints set, so I want Xcode to load the symbols.
 
 The problem is that it takes so long for Xcode to load the framework and 
 process the symbols, that Safari appears to time out and kill the plugin 
 process so I can't debug.
 
 So is there a way to keep Safari from doing this?
 
 Thanks,
 Rudi
 
 
 ___
 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] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)

[Anders Carlsson]

Hi Fady,

so if I'm understanding correctly, in the context of rubber-band scrolling, 
this padding would be between the content and the overhang area?

As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it and 
just have two scroll functions, one that constrains to the content edge and one 
that doesn't.

- Anders

On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote:

 Hi all,
 
 We'd like to provide a general mechanism in WebKit for embedders to scroll 
 page content so that it is not hidden by embedder-provided UI elements that 
 overlap the page. 
 
 In some cases, if a floating UI element overlaps the edge of the page, we'd 
 like to allow the embedder to scroll beyond the edge of the page to allow the 
 hidden content to move to an area that isn't overlapped by UI elements. This 
 feature is orthogonal to rubber band scrolling.
 
 One approach we considered taking is to allow the platform to set scroll 
 padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of 
 the page. 
 
 As a more concrete example, one can imagine a persistent Chromium extension 
 that floats above the edge of the page. A link may lie behind the floating 
 window.  That link would be inaccessible unless the page is allowed to scroll 
 beyond its edge. 
 
 An experimental and incomplete implementation of this idea can be found here: 
 https://bugs.webkit.org/show_bug.cgi?id=68184
 
 After some additional consideration since this patch was posted, I don't 
 believe scroll padding should interact with 
 ScrollView::constrainsScrollingToContentEdge the way it does in the patch. 
 Instead, I feel that scroll padding should be ignored if 
 constrainsScrollingToContentEdge is false. That way rubber band scrolling is 
 not affected at all by this.
 
 What are your thoughts and suggestions? Is this feature sufficiently general 
 to be implemented in WebCore? What are your thoughts about its interaction 
 with ScrollView::constrainsScrollingToContentEdge?
 
 Thanks,
 Fady
 ___
 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] Adding Scroll Padding to allow scroll beyond the edge of the page (within some bounds)

[Anders Carlsson]

Do you envision this being useful on overflow:scroll regions as well or is it 
just frames? If it's just frames, then it seems like something we could keep in 
ScrollView? (I haven't looked at the patch yet).

- Anders

On Oct 6, 2011, at 10:41 AM, Fady Samuel wrote:

 Hi Anders,
 
 Thanks for your reply.
 
 Yes, you are correct. This padding would be between the content and the 
 overhang area.
 
 Thanks,
 
 Fady
 
 On Thu, Oct 6, 2011 at 1:32 PM, Anders Carlsson ander...@apple.com wrote:
 Hi Fady,
 
 so if I'm understanding correctly, in the context of rubber-band scrolling, 
 this padding would be between the content and the overhang area?
 
 As far as constrainsScrollingToContentEdge goes, I'd like to get rid of it 
 and just have two scroll functions, one that constrains to the content edge 
 and one that doesn't.
 
 - Anders
 
 On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote:
 
 Hi all,
 
 We'd like to provide a general mechanism in WebKit for embedders to scroll 
 page content so that it is not hidden by embedder-provided UI elements that 
 overlap the page. 
 
 In some cases, if a floating UI element overlaps the edge of the page, we'd 
 like to allow the embedder to scroll beyond the edge of the page to allow 
 the hidden content to move to an area that isn't overlapped by UI elements. 
 This feature is orthogonal to rubber band scrolling.
 
 One approach we considered taking is to allow the platform to set scroll 
 padding to a FrameView/ScrollableArea to allow scrolling beyond the edge of 
 the page. 
 
 As a more concrete example, one can imagine a persistent Chromium extension 
 that floats above the edge of the page. A link may lie behind the floating 
 window.  That link would be inaccessible unless the page is allowed to 
 scroll beyond its edge. 
 
 An experimental and incomplete implementation of this idea can be found 
 here: https://bugs.webkit.org/show_bug.cgi?id=68184
 
 After some additional consideration since this patch was posted, I don't 
 believe scroll padding should interact with 
 ScrollView::constrainsScrollingToContentEdge the way it does in the patch. 
 Instead, I feel that scroll padding should be ignored if 
 constrainsScrollingToContentEdge is false. That way rubber band scrolling is 
 not affected at all by this.
 
 What are your thoughts and suggestions? Is this feature sufficiently general 
 to be implemented in WebCore? What are your thoughts about its interaction 
 with ScrollView::constrainsScrollingToContentEdge?
 
 Thanks,
 Fady
 ___
 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] Features defines: Platform.h vs build system

[Anders Carlsson]

Speaking of macros, 

I'd like to add a COMPILER_SUPPORTS macro, so we can use it for incrementally 
introducing C++11 features such as variadic templates and rvalue references…

- Anders

On Oct 3, 2011, at 9:53 AM, Darin Adler wrote:

 On Oct 3, 2011, at 8:23 AM, Adam Roben wrote:
 
 I think the plan is outlined here: 
 http://trac.webkit.org/wiki/Porting%20Macros%20plan.
 
 That’s it! I really want to do it!
 
 I noticed that one thing the plan doesn’t state is where the includes of the 
 PortXXX.h files go.
 
-- Darin
 
 ___
 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] Webkit handling of plug-ins out-of-process on the mac

[Anders Carlsson]

On Mar 10, 2011, at 10:22 AM, Rudi Sherry wrote:

 One of the specifics is: is there a separate process for each object/document 
 controlled by a given plug-in, or are all objects controlled by that plug-in 
 in the same extra process, or is it a mix?

All instances of the same plug-in will be in a single process; if you have two 
browser windows open with a Flash plug-in in each window, they'll both run in 
the same process. 

If you have a page with two different plug-in types (QT and Flash for example), 
they will each be in a separate process.

- Anders

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

Re: [webkit-dev] A proposal for Platform Mechanisms

[Anders Carlsson]

On Jun 17, 2010, at 2:04 PM, Jeremy Orlow wrote:

 Overall, looks great!!
 
 
 On Wed, Jun 16, 2010 at 6:05 PM, Anders Carlsson ander...@apple.com wrote:
  Also, PlatformMechanism is a Factory, and should be named accordingly. Or 
  maybe it's a Source of clients/mechanisms.
 
 
 Good point, it is a factory.
 
 Is it a factory?  If so, I'd expect it to return PassOwnPtrs rather than *'s. 
  With *'s I'd expect the class to retain ownership (and destroy them when 
 it's destroyed).
 

Currently I just called the class PlatformPolicies. It is kind of a factory but 
it will only create singletons that are never intended to be destroyed.

 
 On Wed, Jun 16, 2010 at 8:34 PM, Darin Fisher da...@chromium.org wrote:
 2- This looks a lot like WebKitClient in the Chromium WebKit API, except that 
 WebKitClient is defined at the API layer and not at the WebCore/platform 
 layer.  Related point:  WebCore::ChromiumBridge is just a bunch of static 
 functions because it seems wasteful to define intermediate virtual functions 
 at the WebCore level.  Note:  There is a plan to rename ChromiumBridge to 
 PlatformBridge because the Android port wishes to share some of the same 
 infrastructure.  There is already a typedef in place.
 
 I'm pretty sure the solution proposed in this thread would work fine for 
 Android as well.
 

Cool!

 
 On Thu, Jun 17, 2010 at 10:31 AM, Darin Fisher da...@chromium.org wrote:
 Makes sense.  By the way, there are more modules other than WebCore/platform 
 that will require this kind of separation.  WebCore/storage has several 
 examples of this.  Jorlow already modified the LocalStorage implementation to 
 support this kind of separation.  It'd be nice if whatever model is adopted 
 for WebCore/platform can also be applied to these other modules.  (Doesn't 
 sound like it will be an issue.)
 
 Note that you only need this if you have multiple renderer/web processes.  If 
 you only have one and aren't doing sandboxing, you don't need anything 
 special.  If you're doing sandboxing you could either use LocalStorage the 
 way chromium does or you could proxy the raw FS/SQL VFS.  (The former would 
 probably be easier and cleaner.)
 
 Note that the same should be true of IndexedDB.
 

In the future we definitely want to be able to use multiple render processes, 
so designing for that is a good idea.

 It's not so much about performance.  There's a cognitive cost to having so 
 many layers.  But, given (c) above, I understand that you really don't have a 
 choice.
 
 FWIW: I can confirm that the cognitive cost of even the existing number of 
 layers in Chromium is high and surprisingly taxing.  It's definitely 
 something to keep in mind and work to avoid when possible when designing 
 stuff for WebKit2.
 

That's a good point and something that we should definitely try to avoid.


 On Thu, Jun 17, 2010 at 12:50 PM, Maciej Stachowiak m...@apple.com wrote:
 ClipboardStrategy -- abstract class
 ClipboardProxyStrategy (or ProxyClipboardStrategy) -- class that provides 
 the details of clipboard functionality by proxying to a privileged process
 ClipboardDirectStrategy -- class that implements clipboard functionality 
 directly.
 
 For what it's worth, DOM Storage and IndexedDB uses the following naming 
 scheme:
 
 StorageArea - abstract class
 StorageAreaImpl - actual implementation
 StorageAreaProxy - proxy implementation
 
 I'm not entirely sure the Strategy suffix would make these more usable, but 
 otherwise it seems to match up with what I've been doing already.
 

I'm only using the Strategy name for the abstract base classes right now. 

 
 On Thu, Jun 17, 2010 at 12:53 PM, Geoffrey Garen gga...@apple.com wrote:
  Cracking my Design Patterns book (or at least my memory of it), another 
  idea that comes up is Strategy.
 
 On IRC, Anders mentioned Manager as an alternative to Strategy.
 
 I disagree.  Manager is such an overloaded/overused word in CS that it has 
 pretty much no meaning.  Strategy is at least unique.  (Though I'm not 
 completely convinced such a suffix is required...especially for the 
 non-platform code like LocalStorage and IndexedDB.) 
 

Good point.

- Anders

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

Re: [webkit-dev] A proposal for Platform Mechanisms

[Anders Carlsson]

On Jun 16, 2010, at 8:34 PM, Darin Fisher wrote:

 Hi, this is of course a very interesting topic!
 

Yes, and I really appreciate your feedback on this!

 Some comments:
 
 1- Why do you see the need for these interfaces to be virtual?  Will there be 
 multiple implementations?
 Some possible answers that come to mind:
 a) Yes, there could be a proxy implementation used to marshal calls to the 
 real implementation that lives in the main process.  Both should implement 
 the same interface.

 b) Just following the {Chrome,FrameLoader,*}Client convention.
 c) So that WebCore can still be built as a DLL/DYLIB.
 

Mostly a) and c). This is correct. For current WebKit, we won't have a proxy 
implementation, but for WebKit2 we will. We'd like both of these WebKit 
frameworks to be able to use the same WebCore framework.

 2- This looks a lot like WebKitClient in the Chromium WebKit API, except that 
 WebKitClient is defined at the API layer and not at the WebCore/platform 
 layer.  Related point:  WebCore::ChromiumBridge is just a bunch of static 
 functions because it seems wasteful to define intermediate virtual functions 
 at the WebCore level.  Note:  There is a plan to rename ChromiumBridge to 
 PlatformBridge because the Android port wishes to share some of the same 
 infrastructure.  There is already a typedef in place.

These functions are virtual because they are intended to be implemented by 
WebKit. Also, none of these functions are really called that often (and if they 
ever are, we should consider caching the result or other performance fixes).

 
 3- Not all of the WebCore/platform classes are well suited for a 
 straightforward delegation.  In some cases, delegation back through 
 ChromeClient is actually better.  See the extra methods on 
 ChromeClientChromium, which extends ChromeClient.  I believe that at least a 
 few methods on ChromiumBridge should be re-routed in this manner.

I definitely agree that we shouldn't just pile things on to these new classes. 
(I also don't see why the ChromeClientChromium functions couldn't be added to 
ChromeClient directly).

 
 4- There are numerous concrete types (e.g., for cursors, icons, images, etc.) 
 that end up being defined very differently at the port layer for a 
 multi-process port.  This may be a non-factor though, but perhaps we should 
 think about how to share these definitions too.
 

As we move forward and get more and more of WebKit2 in place, this will 
definitely be something to think about.

Thanks for your feedback!

- Anders

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

[webkit-dev] A proposal for Platform Mechanisms

[Anders Carlsson]

Hi everyone,

We've now reached the point in WebKit2 development where we need to be able to 
override some global calls in WebCore so that we can funnel them through to 
another process, in a similar way to what Chromium does. We also need to be 
able to override the calls at run-time, so that we can use the same WebCore 
framework with both current WebKit and WebKit2.

Here's a proposal for something I call Platform mechanisms that I hope can be 
used by other ports as well as replacing the Chromium bridge long term:

The design pattern we use in WebCore for when a port wants to override 
functionality is the abstract client class pattern. We have a 
FrameLoaderClient per frame, a ChromeClient per Page etc. Some functionality is 
global, and doesn't really belong to a specific object, for example:

* Clipboard handling
* File access
* Plug-ins.

I propose that we create an abstract class, PlatformMechanism which acts as 
the starting point for accessing such functionality, something like:

class PlatformMechanism {
 virtual ClipboardMechanism* clipboardMechanism() = 0;
 virtual FileAccessMechanism* fileAccessMechanism() = 0;
 virtual PluginMechanism* pluginMechanism() = 0;
};

class PluginMechanism {
   virtual void refreshPlugins() = 0;
   virtual void getPluginInfo(VectorPluginInfo) = 0;
};

The various ports would subclass PlatformMechanism, implement the various 
mechanism classes and then call into WebCore to set the PlatformMechanism. This 
approach gives a natural separation of the functionality. (There's of course 
nothing stopping you from having a single class inherit from all of the 
mechanism classes). We could also consider adding some functions to 
PlatformMechanism directly, for example if a mechanism class would end up with 
just a single function. 

The advantage of having a single PlatformMechanism aggregator class is that 
we don't need lots of setFooMechanism calls that ports would need, and if 
someone adds a new mechanism class, ports will fail to build instead of 
mysteriously crash when it turns out someone has forgotten to add a call to set 
the mechanism.

We would also provide WebCore implementations of the various mechanisms, so 
that ports that don't want to override anything would just return the WebCore 
mechanisms. We could even have a WebCorePlatformMechanism class that you could 
set as the default class. This would enable ports to pick where WebCore should 
be used.

I would very much appreciate any comments on this, and if I don't hear any 
major objections I will start landing parts of this, conditionally compiled by 
a WTF_USE_PLATFORM_MECHANISM define that's turned on for Mac WebKit.

Thanks,
Anders

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

Re: [webkit-dev] A proposal for Platform Mechanisms

[Anders Carlsson]

On Jun 16, 2010, at 5:55 PM, Darin Adler wrote:

 Sounds reasonable to me. We already follow pointers and use virtual functions 
 for all these things, so I don’t see them adding a lot of overhead.
 
 Would these Mechanism classes replace all the current Client classes?

Like Kenneth said, these are more like global clients. I don't see the 
benefit of replacing our current Client classes.

 Would the mechanism objects be obtained once and cached globally? How is the 
 initial PlatformMechanism object created?

My current design is a bit different from the example I gave in my original 
mail. The getter functions are not virtual, but the functions to create the 
various mechanisms are. Something like:

class PlatformMechanism {
public:
PluginMechanism* pluginMechanism()
{
if (!m_pluginMechanism)
m_pluginMechanism = createPluginMechanism();
return m_pluginMechanism;
}

private:
virtual PluginMechanism* createPluginMechanism() = 0;

PluginMechanism* m_pluginMechanism;
};

 How is the initial PlatformMechanism object created?

WebKit will create a class that derives from PlatformMechanism. In the WebKit 
initialization code we'll create an instance of this class and set it as the 
platform mechanism using a setPlatformMechanism call.

- Anders
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Announcing WebKit2

[Anders Carlsson]

On Apr 8, 2010, at 5:58 PM, Maciej Stachowiak wrote:

 - Does your new framework require any significant changes in WebCore?
 Could you briefly summarize them?
 
 No WebCore changes are required - it works with the existing WebCore.
 

Right now WebCore needs to be built with some different flags 
(ENABLE_EXPERIMENTAL_SINGLE_VIEW_MODE=1 
and WTF_USE_WEB_THREAD=1), but the goal is that the same WebCore should be able 
to support both WebKit and WebKit2 (and on the mac, both WebKit frameworks will 
link against the same WebCore framework).

- Anders

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

[webkit-dev] Announcing WebKit2

[Anders Carlsson]

Hello everyone,

This is a heads-up that we will shortly start landing patches for a new WebKit 
framework that we at Apple have been working on for a while. We currently call 
this new framework WebKit2.

WebKit2 is designed from the ground up to support a split process model, where 
the web content (JavaScript, HTML, layout, etc) lives in a separate process. 
This model is similar to what Google Chrome offers, with the major difference 
being that we have built the process split model directly into the framework, 
allowing other clients to use it.

Some high-level documentation is available at 
http://trac.webkit.org/wiki/WebKit2

Currently WebKit2 is available for Mac and Windows, and we would gladly accept 
patches to add more ports.

We're more than happy to answer any questions you might have, and we hope that 
this will be a topic of discussion at the WebKit Contributors Meeting.

Thanks,
Anders Carlsson and Sam Weinig.

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

Re: [webkit-dev] Volunteers to run commit-queue?

[Anders Carlsson]

I rolled that patch out.

Anders

On Aug 12, 2009, at 12:51 PM, Oliver Hunt wrote:


Looks to be due to r47110?

--Oliver

___
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] NPP_GetValue with 'NPPVpluginScriptableNPObject' is not invoked automatically in XHTML content for a NS Plugin embedded object.

[Anders Carlsson]

On Oct 30, 2008, at 3:35 AM, Deshpande, Raghavendra wrote:


I have embedded an NS plugin object using object /object .

When the page is served as XHTML, the NS plugin  scriptable object  
is NOT instantiated, even when the plugin implements NPP_Get()  
forNPPVpluginScriptableNPObject . Whereas, if the same page is  
served as HTML content, then, the scriptable object gets instantiated.


I also noticed that, in xhtml content , the scriptable NS plugin  
object gets instantiated only upon first call to ‘getElementById’.  
Thus making ‘getElementById’ mandatory for Javascript binding to the  
embedded object.


XHTML specification doesn’t specify any rules related to ‘auto  
instantiation’ of NS Pligin object. But, the behavior should not  
vary from HTML to XHTML.


So, Is it a bug?



Yes, this sounds like a bug. Please file it at http://bugs.webkit.org

Thanks,
Anders

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

Re: [webkit-dev] HTML5 Application Cache

[Anders Carlsson]

9 sep 2008 kl. 20.42 skrev Michael Nordman:

 What is the status of the work-in-progress around the HTML5 AppCache  
 that is in the repository? Is anybody actively working on that now?  
 I'm interested in incorporating support for this feature into Chrome  
 is why I'm asking.

 Michael

Hey Michael!

As far as the specification goes, the two big parts that aren't  
implemented are opportunistic entries, and dynamic entries.

Also, all I/O is currently synchronous which is of course something  
that we'd like to avoid. The relevant code is (as you probably already  
know) in WebCore/loader/appcache, but also elsewhere in the loader,  
surrounded by #if ENABLE(OFFLINE_WEB_APPLICATIONS).

The code hasn't received a lot of testing (given that the spec is  
fairly new and in flux). Some regression tests are in LayoutTests/http/ 
tests/appcache.

Any feedback/comments you have is of course much appreciated!

Anders
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Directory for Safari 3 for Windows plugins that isn't in Program Files?

[Anders Carlsson]

22 aug 2007 kl. 16.29 skrev MILIANO Vitorio:

I've filed it in both Apple Radar (5430584) and WebKit Bugzilla  
(15053).

Quickly poking through Trac, addPluginsFromRegistry() in
PluginDatabaseWin.cpp looks to be the culprit; it's definitely only
looking at HKEY_LOCAL_MACHINE.

Thanks everyone for the help.

Thanks,
Vitorio Miliano



Hi!

Thank you for your bug report. I just committed a fix

http://trac.webkit.org/projects/webkit/changeset/25193

and it should be available shortly in a nightly build - see http:// 
nightly.webkit.org


Regards,
Anders


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

Re: [webkit-dev] Directory for Safari 3 for Windows plugins that isn't in Program Files?

[Anders Carlsson]

On Jul 6, 2007, at 4:33 PM, MILIANO Vitorio wrote:


Hello, the Apple web-dev list suggested I post this question here:

I'm an NPAPI plugin author looking for some help on where Safari 3 for
Windows likes its plugins.

For Windows users without administrator access, there's no way to  
write

files into the Program Files directory, so no way to install plugins
into Program Files\Safari\Plugins.

Is there an alternate directory location available, or will there be?
Application Data\Apple Computer\Safari\Plugins, perhaps?  I haven't
found a location that's worked.

Thanks,
Vitorio Miliano



Hi Vitorio!

It won't matter where you install your plug-in as long as you add a  
registry entry for it as described in http://developer.mozilla.org/en/docs/Plugins:_The_first_install_problem


Anders

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