Re: [webkit-dev] Deprecate webkit_web_page_get_main_frame?

[Carlos Garcia Campos via webkit-dev]

El mar, 23-07-2024 a las 12:51 -0600, Alex Christensen escribió:
> We definitely have a lot of work to do, but the plan is to make UI
> process driven replacements for all uses of the injected bundle. 
> It’s a large problem without a currently completely known solution,
> but we’re working on it and welcome collaboration from people working
> on webkit-based browsers on other platforms.  I’m pushing to
> deprecate things to discourage further adoption of things we are
> planning to remove, even before we have a complete replacement plan.
> 

Ok, sounds good to me. We are of course happy to collaborate on this,
so count on us for whatever we can do to help.

> > On Jul 22, 2024, at 4:31 AM, Carlos Garcia Campos via webkit-dev
> >  wrote:
> > 
> > Hi Alex, 
> > 
> > sorry for the delay to reply, I was on vacation last week. 
> > 
> > So, we mainly use the frame object to get its javascript context,
> > so
> > what's the plan for that? I mean, it's only the api to get the main
> > frame what's going to be deprecated or the frame object entirely?
> > In
> > most of the cases we get the frame from the script world on the
> > window-
> > object-cleared event, so we can probably deprecate
> > get_main_frame(). I
> > think it's only used in epiphany and evolution, but I would need to
> > check how it's used there.
> > 
> > El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit-
> > dev
> > escribió:
> > > In https://github.com/WebKit/WebKit/pull/30763 I’m deprecating
> > > injected bundle frame access interfaces as part of the site
> > > isolation
> > > development.  Would glib API maintainers be willing to deprecate
> > > webkit_web_page_get_main_frame to discourage its adoption and
> > > indicate plans to remove it at some point in the future?  I’ve
> > > kept
> > > the functionality for now because we are still moving off it, but
> > > at
> > > some point that will be complete and it would be nice to remove
> > > bundle frame access together.
> > > ___
> > > webkit-dev mailing list
> > > webkit-dev@lists.webkit.org
> > > https://lists.webkit.org/mailman/listinfo/webkit-dev
> > 
> > -- 
> > Carlos Garcia Campos
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 

-- 
Carlos Garcia Campos


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deprecate webkit_web_page_get_main_frame?

[Carlos Garcia Campos via webkit-dev]

Hi Alex, 

sorry for the delay to reply, I was on vacation last week. 

So, we mainly use the frame object to get its javascript context, so
what's the plan for that? I mean, it's only the api to get the main
frame what's going to be deprecated or the frame object entirely? In
most of the cases we get the frame from the script world on the window-
object-cleared event, so we can probably deprecate get_main_frame(). I
think it's only used in epiphany and evolution, but I would need to
check how it's used there.

El vie, 12-07-2024 a las 16:19 -0600, Alex Christensen via webkit-dev
escribió:
> In https://github.com/WebKit/WebKit/pull/30763 I’m deprecating
> injected bundle frame access interfaces as part of the site isolation
> development.  Would glib API maintainers be willing to deprecate
> webkit_web_page_get_main_frame to discourage its adoption and
> indicate plans to remove it at some point in the future?  I’ve kept
> the functionality for now because we are still moving off it, but at
> some point that will be complete and it would be nice to remove
> bundle frame access together.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Carlos Garcia Campos


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Replacing Cairo in WebKit with Skia

[Carlos Garcia Campos via webkit-dev]

Hi WebKittens,

At Igalia we have spent some time exploring different options to
replace the Cairo 2D rendering library in the GTK and WPE ports (we
even tried rolling our own library). Recently we decided to try Skia
and we have successfully integrated it in the WPE port. Right now we
can compile WebKit with Skia linked statically, as part of the CMake
build, and run a number benchmarks. This has allowed us to compare the
Skia GPU and CPU renderers with the existing Cairo one in different
devices.

The results are very promising: benchmarks are faster than Cairo's CPU
rendering, specially with Skia's GPU renderer. The improvement varies
for each device, but in any case it is already clear that the change is
a net positive on every configuration we have tested. Additionally, the
integration in the build system is well isolated: importing Skia under
Source/ThirdParty there is no need for any additional dependencies,
patching Skia has not been needed, and the changes in WebKit are
limited to code from the WPE port.

After talking to teams from Google, Sony, Apple and RedHat during this
week, everyone thinks using Skia will be a great improvement for the
GTK, WPE, PlayStation and WinCairo ports. Therefore, we would like to
start upstreaming what we have to the WebKit repository and continue
the work there.

Points we need to consider:

- Skia is licensed under the BSD 3-Clause “New” license, which
should be compatible with WebKit's.

- The Skia source tree would add about 170MiB to the repository
under Source/ThirdParty. For the sake of comparison, libwebrtc weighs
367MiB and ANGLE 73MiB.

- We plan to update Skia frequently following Google's
recommendation. We have already agreed with the Skia maintainers to
stay in contact and will explore integrating an automated system to
test updates. We have also discussed Skia's security policy with
Google, and we will have a procedure in place to incorporate security
fixes, the latest when we start making releases using Skia.

- We cannot promise a timeline at the moment but expect refactors
in the GTK and WPE ports after the initial integration. We have big
plans for rearchitecting the rendering pipeline to better take
advantage of GPUs, and we hope we can get rid of some complex code
while at it.

Please let us know if you have any questions, we plan to do this job
sooner rather than later if there are no objections. We are very
excited about this move since we really think it will be a great step
ahead for the non Apple ports of WebKit, allowing the project to grow
even bigger and stronger.

Best regards,

- The Igalia team

-- 
Carlos Garcia Campos


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] InjectedBundle deprecation

[Carlos Garcia Campos via webkit-dev]

Here is the list of features in GTK and WPE ports exposed using
injected bundle.

JavaScript extensions
-

Used by apps to expose current JavaScript APIs using the JSC API. This
includes:

 - WebKitScriptWorld: The window-object-cleared signal is the initial
point for injecting JavaScript. It allows allows to create isolated
worlds.
 - WebKitFrame: To get the JS context. It also allows to get the JS
value for a node handle.
 - WebKitDOMNode: To associate a DOM node to its JSCValue.

We still need a way to run code in the JavaScript process.


Requests handling
-

This is send-request signal to expose willSendRequest. It allows to
modify every request before it's sent or even cancel it. This was used
by epiphany to implement the adblocker before the content filter api
existed. Other apps still use it to modify the uri of requests before
being sent.

This is not easy to migrate because going to the UI process for every
load would be too much.


Context Menu


This is the same API we have in the UI process to provide more
information and be able to build the menu based on the DOM node. For
example epiphany uses it to determine if the context menu was opened
over a node that is editable or a password input field. It's also used
to get the currently selected text. All that info is set as user data
that is passed to the context menu signal in the UI process.

I think nowadays most of this information is already in
WebHitTestResultData and we can add whatever is missing, so this should
be easy to migrate.


Form autofilling


We expose a signal to notify when form controls are associated to a
frame. This is used by epiphany to auto fill password fields.

This could probably be moved to the UI process or implemented entirely
using JavaScript.


Password manager


Related with previous one we have a signal to notify when a form is
going to be submitted. Used by epiphany to remember the passwords.

This could probably be moved to the UI process or implemented entirely
using JavaScript.


Console messages


API to notify the user when a console message is sent.

This could be easily moved to the UI process, but I think nobody is
currently using this API so it can be just removed instead.


Editor
--

Expose the selection changed signal.

This could be implemented with JavaScript. I'm not sure this is
currently used by any application.


Resources load
--

This is internal implementation used to implement the UI process API
for resources.

There's APIResourceLoadClient now, so we could probably switch to use
that or add whatever is missing.


Page snapshot
-

This is also internal implementation for the UI process API for page
snapshots.

We could expose this without using injected bundle at all.


User messages
-

API to send custom messages between UI and web process.

We might need this depending on how we migrate other features.




El dom, 14-08-2022 a las 09:25 +0200, Carlos Garcia Campos via webkit-
dev escribió:
> El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev
> escribió:
> > Hello WebKit developers! We are ramping up to do some serious work
> > on
> > Site Isolation which includes putting cross-origin iframes in a
> > different process than the parent frame. Similar efforts have been
> > done in other browser engines and some related work has already
> > been
> > done in WebKit, but not enough.
> > 
> > This will do strange things to the InjectedBundle APIs, which have
> > fundamental assumptions that the whole DOM is in one process and
> > that
> > communication only happens with one process at a time. We have
> > never
> > exposed InjectedBundle APIs as public API, but some other
> > distributors of WebKit have. As we make progress on this project,
> > we
> > anticipate that anything in
> > Source/WebKit/WebProcess/InjectedBundle/API is subject to
> > deprecation
> > and removal.  This will also allow us to tighten the sandbox on the
> > web process, resolve security and performance issues, and have
> > cleaner code.
> > 
> > Would the maintainers of the GTK and WPE APIs be willing to assist
> > in
> > migrating from those APIs and designing replacements in the UI
> > process?
> > 
> 
> Sure. I think the most important feature we expose from injected
> bundle
> is JavaScript extensibility using the JSC API.
> 
> Next week I can write a summary of the features we currently expose
> from injected bundle and  possible alternatives.
> 
> > Alex Christensen
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo

Re: [webkit-dev] InjectedBundle deprecation

[Carlos Garcia Campos via webkit-dev]

El vie, 12-08-2022 a las 13:40 -0700, Alex Christensen via webkit-dev
escribió:
> Hello WebKit developers! We are ramping up to do some serious work on
> Site Isolation which includes putting cross-origin iframes in a
> different process than the parent frame. Similar efforts have been
> done in other browser engines and some related work has already been
> done in WebKit, but not enough.
> 
> This will do strange things to the InjectedBundle APIs, which have
> fundamental assumptions that the whole DOM is in one process and that
> communication only happens with one process at a time. We have never
> exposed InjectedBundle APIs as public API, but some other
> distributors of WebKit have. As we make progress on this project, we
> anticipate that anything in
> Source/WebKit/WebProcess/InjectedBundle/API is subject to deprecation
> and removal.  This will also allow us to tighten the sandbox on the
> web process, resolve security and performance issues, and have
> cleaner code.
> 
> Would the maintainers of the GTK and WPE APIs be willing to assist in
> migrating from those APIs and designing replacements in the UI
> process?
> 

Sure. I think the most important feature we expose from injected bundle
is JavaScript extensibility using the JSC API.

Next week I can write a summary of the features we currently expose
from injected bundle and  possible alternatives.

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

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3



signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] 7 Days Until Retiring Subversion

[Carlos Garcia Campos via webkit-dev]

El jue, 16-06-2022 a las 16:11 -0700, Jonathan Bedard via webkit-dev
escribió:
> Hey folks,
> 
> The time has come! On Thursday, June 23rd, we are planning on
> stopping all commits to the Subversion repository hosted
> on https://svn.webkit.org, all future commits will at that point be
> made on https://github.com/WebKit/WebKit. If the following is true
> about your development workflow:
> 

We still depend on svn for the stable branches of GTK and WPE ports.
Would it be possible to migrate our branches to github before removing
svn?

> - You use github.com/WebKit/WebKit as the remote for your git
> checkout of WebKit
> - You commit with Commit-Queue, Merge-Queue or Unsafe-Merge-Queue
> 
> Then you do not need to change anything about your workflow. Changes
> which are being processed during the transition will be routed to the
> correct place by Commit and Merge Queue. I would like to specifically
> note that `webkit-patch` and the patch workflow in general will
> continue to work after Subversion is frozen. You can check which
> remote your checkout uses with ‘git remote -v’. Please see the
> migration guide below for details.
> 
> If you are still reliant off of git.webkit.org remotes (either
> WebKit-https.git or WebKit.git), or if you still have a checkout
> based on https://svn.webkit.org, it’s time to migrate those
> checkouts. See https://github.com/WebKit/WebKit/wiki/Migration for
> details on how to migrate from an existing checkout
> or https://github.com/WebKit/WebKit/wiki/Contributing#checking-out-We
> bKit for starting fresh. We intend to keep our defunct remotes
> available for a few weeks to ease the transitions, but starting
> Thursday, these 3 remotes will not be receiving new commits.
> 
> Please reach out if you have any issues,
> 
> Jonathan Bedard
> WebKit Continuous Integration
> ___
> 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] Miguel Gomez is now WebKit reviewer

[Carlos Garcia Campos via webkit-dev]

Hi,

I'm happy to announce that Miguel Gomez is now WebKit reviewer. Miguel
has a lot of experience in WebKitGTK and WPE graphics, so he is the
perfect reviewer now for graphics related patches for GTK/WPE.

Please join me in congratulating Miguel!

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

Re: [webkit-dev] Step 1 of Plugin removal: Deleting NPAPI (and thus Flash support)

[Carlos Garcia Campos]

El mar, 14-01-2020 a las 05:06 +1100, Dean Jackson escribió:
> 
> 
> > On 13 Jan 2020, at 20:14, Carlos Garcia Campos  > > wrote:
> > 
> > El lun, 13-01-2020 a las 05:30 +1100, Dean Jackson escribió:
> > > Dear Non-Apple ports,
> > > 
> > > Running Flash has been more difficult over the past few years as
> > > part
> > > of a (semi-) coordinated effort by browsers and Adobe. The plan
> > > is to
> > > remove support for Flash + NPAPI by the end of this year. See the
> > > links below. 
> > > 
> > > I'd like to remove our NPAPI code soon, but I want to make sure
> > > the
> > > other ports are ok with this. Please speak up if you have a
> > > reason to
> > > keep it in.
> > 
> > WPE has never supported NPAPI plugins and the GTK port removed the
> > support for GTK2 plugins (flash) already in our current stable
> > version.
> > Plugins not using GTK at all (or using GTK3) are still supported by
> > GTK
> > port (some of them only under X11, though). I'm ok with removing
> > the
> > NPAPI plugins support in the GTk port, but we are at the end of the
> > release cycle, so I prefer if we remove the feature right after we
> > branch for the next stable version (scheduled for the 1st
> > February). I
> > could even branch earlier if needed.
> 
> Waiting until February is totally ok with me. Good luck with your
> release.

We have already branched, so we can start removing NPAPI plugins from
trunk :-)

> Dean
> 
> > > [Note that we will still have some plugin code e.g. our internal
> > > PDFPlugin, just no support for externally installed plugins]
> > > 
> > > Dean
> > > 
> > > * Adobe's end of life for Flash - 
> > > https://theblog.adobe.com/adobe-flash-update/
> > > * Chrome removing Flash support by end of 2020 - 
> > > https://sites.google.com/a/chromium.org/dev/flash-roadmap
> > > * Google removing support for Flash by end of 2020 - 
> > > https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/
> > > * Mozilla removing NPAPI by end of 2020 - 
> > > https://developer.mozilla.org/en-US/docs/Plugins/Roadmap
> > > * Mozilla only uses NPAPI for Flash - 
> > > https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
> > > 
> > 
> > Thanks!
> > 
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 

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

Re: [webkit-dev] Step 1 of Plugin removal: Deleting NPAPI (and thus Flash support)

[Carlos Garcia Campos]

El lun, 13-01-2020 a las 05:30 +1100, Dean Jackson escribió:
> Dear Non-Apple ports,
> 
> Running Flash has been more difficult over the past few years as part
> of a (semi-) coordinated effort by browsers and Adobe. The plan is to
> remove support for Flash + NPAPI by the end of this year. See the
> links below. 
> 
> I'd like to remove our NPAPI code soon, but I want to make sure the
> other ports are ok with this. Please speak up if you have a reason to
> keep it in.

WPE has never supported NPAPI plugins and the GTK port removed the
support for GTK2 plugins (flash) already in our current stable version.
Plugins not using GTK at all (or using GTK3) are still supported by GTK
port (some of them only under X11, though). I'm ok with removing the
NPAPI plugins support in the GTk port, but we are at the end of the
release cycle, so I prefer if we remove the feature right after we
branch for the next stable version (scheduled for the 1st February). I
could even branch earlier if needed.

> [Note that we will still have some plugin code e.g. our internal
> PDFPlugin, just no support for externally installed plugins]
> 
> Dean
> 
> * Adobe's end of life for Flash - 
> https://theblog.adobe.com/adobe-flash-update/
> * Chrome removing Flash support by end of 2020 - 
> https://sites.google.com/a/chromium.org/dev/flash-roadmap
> * Google removing support for Flash by end of 2020 - 
> https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/
> * Mozilla removing NPAPI by end of 2020 - 
> https://developer.mozilla.org/en-US/docs/Plugins/Roadmap
> * Mozilla only uses NPAPI for Flash - 
> https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
> 

Thanks!

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

[webkit-dev] WebKit2 owners help for GTK and WPE

[Carlos Garcia Campos]

Hi, 

this week we reach our feature/API freeze in both GTK+ and WPE release
schedules, and we have a few bug adding new features/API blocked on
WebKit2 owner approval for several weeks. We would appreciate if some
WebKit2 owner could take a look at the patches to review the cross-
platform changes. 

[GTK][WPE] Add content extensions support in WKTR and unskip layout tests
https://bugs.webkit.org/show_bug.cgi?id=193622

[WPE] Add API for webview background color configuration
https://bugs.webkit.org/show_bug.cgi?id=192305

[GTK][WPE] Need a function to convert internal URI to display ("pretty") URI
https://bugs.webkit.org/show_bug.cgi?id=174816

[GTK][WPE] Add web extensions API to whitelist access to a security origin
https://bugs.webkit.org/show_bug.cgi?id=193489

Thanks!

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

Re: [webkit-dev] OWNERS policy

[Carlos Garcia Campos]

El jue, 22-02-2018 a las 00:19 -0800, Maciej Stachowiak escribió:
> > On Feb 21, 2018, at 11:06 PM, Carlos Garcia Campos  > .org> wrote:
> > 
> > El mié, 21-02-2018 a las 13:49 -0800, Ryosuke Niwa escribió:
> > > If there was any confusion, WebKit2 Owner's policy is still
> > > active
> > > and in effect.
> > 
> > And maybe it's time to get rid of it? I never liked the idea, but I
> > have to admit it made sense at the time it was done. The WebKit2
> > development was on fire and wk2 developers couldn't spend time
> > dealing
> > with build failures on other ports that would slow down the
> > development
> > pace. Nowadays, WebKit2 doesn't really exist, it's WebKit again,
> > and
> > the old WebKit is considered legacy. We no longer need a policy.
> > Removing the policy doesn't mean not owners will do any kind of
> > changes, I think we all know when to ask other developers for a
> > second
> > review or approval. The same we have always done in other
> > components
> > jsc, WebCore, WTF that don't have an owners policy.
> 
> Some of us at Apple have discussed changing it, but nothing to
> announce yet.
> 
> I do think we have problems with people reviewing things that they
> aren't fully qualified to review, but that happens throughout the
> whole tree. So that logically leads to the conclusion of either no
> OWNERS or OWNERS everywhere.

Well, I don't think the current owners policy is about being qualified
to review patches, because non-apple developer are not allowed to be
there. That would mean there aren't non-apple reviewers qualified to
review patches under WebKit directory. Who is better qualified than
Brian, Joe or me to review Automation patches? None of us are WebKit2
owners, though.

I don't think an owners policy would solve the problem of people
reviewing patches without being fully qualified. If we actually have a
problem with that, I guess they are very few cases, so we should be
able to handle them individually. We could simply rollout the offending
commit and discuss the situation with the reviewer in the reviewers
list. Common sense is the best policy here. If needed we could even set
a procedure to remove reviewer status to someone if we think he/she is
not behaving as expected by a WebKit reviewer.

> > 
> > > In the case you aren't sure of the right reviewer, you can send a
> > > bulk email to all of us. I get cc'ed on every WebKit bug with Mac
> > > EWS/CQ failure, and as such, I ignore all WebKit bugs I'm cc'ed
> > > unless the bug title is of my interest.
> > > 
> > > - R. Niwa
> > > 
> > > On Wed, Feb 21, 2018 at 1:27 PM, youenn fablet  > > >
> > > wrote:
> > > > Hi Don,
> > > > 
> > > > I am not sure there is a well defined policy.
> > > > If we want to continue with owners, it would indeed be good to
> > > > make
> > > > it clearer and more functional.
> > > > 
> > > > Here is my current understanding.
> > > > The multi-process architecture is now well in place so things
> > > > like
> > > > updating IPC encoders/decoders might no longer require a
> > > > dedicated
> > > > owner scrutiny.
> > > > Exposing the right WK2 APIs is more sensitive on the other
> > > > hand.
> > > > 
> > > >   Y
> > > > 
> > > > Le mer. 21 févr. 2018 à 12:52,  a écrit
> > > > :
> > > > > Hi WebKittens,
> > > > > 
> > > > > As you know we're working on getting WinCairo running on
> > > > > modern
> > > > > WebKit. We're working through a backlog of patches we have to
> > > > > upstream and are sometimes running into issues where we can't
> > > > > find reviewers for our code.
> > > > > 
> > > > > Here are some bugs with attachments that have been hanging
> > > > > out
> > > > > for over 5 days.
> > > > > 
> > > > > https://bugs.webkit.org/show_bug.cgi?id=182870
> > > > > https://bugs.webkit.org/show_bug.cgi?id=182869
> > > > > https://bugs.webkit.org/show_bug.cgi?id=182751
> > > > > 
> > > > > One thing we're unclear on is the OWNERS policy. The list
> > > > > itself
> > > > > is pretty small and has no guidance on who might be the right
> > > > > person(s) to assi

Re: [webkit-dev] OWNERS policy

[Carlos Garcia Campos]

El mié, 21-02-2018 a las 13:49 -0800, Ryosuke Niwa escribió:
> If there was any confusion, WebKit2 Owner's policy is still active
> and in effect.

And maybe it's time to get rid of it? I never liked the idea, but I
have to admit it made sense at the time it was done. The WebKit2
development was on fire and wk2 developers couldn't spend time dealing
with build failures on other ports that would slow down the development
pace. Nowadays, WebKit2 doesn't really exist, it's WebKit again, and
the old WebKit is considered legacy. We no longer need a policy.
Removing the policy doesn't mean not owners will do any kind of
changes, I think we all know when to ask other developers for a second
review or approval. The same we have always done in other components
jsc, WebCore, WTF that don't have an owners policy.

> In the case you aren't sure of the right reviewer, you can send a
> bulk email to all of us. I get cc'ed on every WebKit bug with Mac
> EWS/CQ failure, and as such, I ignore all WebKit bugs I'm cc'ed
> unless the bug title is of my interest.
> 
> - R. Niwa
> 
> On Wed, Feb 21, 2018 at 1:27 PM, youenn fablet 
> wrote:
> > Hi Don,
> > 
> > I am not sure there is a well defined policy.
> > If we want to continue with owners, it would indeed be good to make
> > it clearer and more functional.
> > 
> > Here is my current understanding.
> > The multi-process architecture is now well in place so things like
> > updating IPC encoders/decoders might no longer require a dedicated
> > owner scrutiny.
> > Exposing the right WK2 APIs is more sensitive on the other hand.
> > 
> >Y
> > 
> > Le mer. 21 févr. 2018 à 12:52,  a écrit :
> > > Hi WebKittens,
> > >  
> > > As you know we're working on getting WinCairo running on modern
> > > WebKit. We're working through a backlog of patches we have to
> > > upstream and are sometimes running into issues where we can't
> > > find reviewers for our code.
> > >  
> > > Here are some bugs with attachments that have been hanging out
> > > for over 5 days.
> > >  
> > > https://bugs.webkit.org/show_bug.cgi?id=182870
> > > https://bugs.webkit.org/show_bug.cgi?id=182869
> > > https://bugs.webkit.org/show_bug.cgi?id=182751
> > >  
> > > One thing we're unclear on is the OWNERS policy. The list itself
> > > is pretty small and has no guidance on who might be the right
> > > person(s) to assign a bug to when touching shared code. It feels
> > > like we're just guessing on reviewers which doesn't seem like it
> > > helps anything move along.
> > >  
> > > There also seem to be commits that were reviewed by non-owners
> > > that are touching common code. We're not sure if unfamiliarity
> > > with Windows might prevent some owners from looking over a patch
> > > as we move further along in our implementation.
> > >  
> > > Basically we'd like to get some clarification here so we can keep
> > > landing patches for modern WebKit on Windows.
> > >  
> > > Thanks!
> > > Sony WebKit Team
> > > ___
> > > 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Move to NavigationClient

[Carlos Garcia Campos]

El vie, 20-10-2017 a las 13:30 -0700, Alex Christensen escribió:
> Right now we have an API::LoaderClient, API::PolicyClient and an
> API::NavigationClient.  We intend to remove the first two in the
> future in favor of the API::NavigationClient.  I have been working to
> add calls to the NavigationClient to make it a replacement for the
> LoaderClient and PolicyClient.  The linux ports, however, have
> WebKitPolicyClient and WebKitLoaderClient.  Could someone working on
> Linux replace these with an implementation of API::NavigationClient?

WIP patch and questions in:
https://bugs.webkit.org/show_bug.cgi?id=178720


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

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Carlos Garcia Campos]

El mar, 27-06-2017 a las 18:19 +0200, Carlos Garcia Campos escribió:
> El vie, 16-06-2017 a las 09:43 -0700, Brady Eidson escribió:
> [...]
> > > > If not, I can get rid of it right now
> > > > 
> > > > If so, then I need a GTK maintainer to come up with a plan
> > > > soon.
> > > 
> > > How soon is soon? :-) We are approaching the end of our release
> > > cycle,
> > > it would be good for us if we could do any changes related to
> > > this
> > > after we branch for 2.18. Of course I can branch earlier if
> > > needed.
> > > According to our schedule we should branch the first week of
> > > August. Is
> > > that late?
> > 
> > That’s much later than the soon I was targeting.
> > 
> > Hoping to do this by the end of June.
> 
> Ok, I've found time today to work on this. I don't have time to re-
> implement WebKitFaviconDatabase using a different database model, so
> I've copied IconDatabase from WebCore to WebKit and used it directly
> from WebKitFaviconDatabase. I've switched the client implementation
> to
> API::IconLoadingClient too. So, I think you can just remove all the
> WebCore and WebKit2 code after the patch lands.
> 
> https://bugs.webkit.org/show_bug.cgi?id=173877

I forgot to say that copying IconDatabase is just a temporary solution,
because I don't have time for a proper solution now, so during our next
release cycle I'll try to either improve or replace it with a new
implementation that allows to store multiple icons and sizes for the
same page, etc.

> 
> Regards, 
> ___
> 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] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Carlos Garcia Campos]

El vie, 16-06-2017 a las 09:43 -0700, Brady Eidson escribió:
[...]
> > > If not, I can get rid of it right now
> > > 
> > > If so, then I need a GTK maintainer to come up with a plan soon.
> > 
> > How soon is soon? :-) We are approaching the end of our release
> > cycle,
> > it would be good for us if we could do any changes related to this
> > after we branch for 2.18. Of course I can branch earlier if needed.
> > According to our schedule we should branch the first week of
> > August. Is
> > that late?
> 
> That’s much later than the soon I was targeting.
> 
> Hoping to do this by the end of June.

Ok, I've found time today to work on this. I don't have time to re-
implement WebKitFaviconDatabase using a different database model, so
I've copied IconDatabase from WebCore to WebKit and used it directly
from WebKitFaviconDatabase. I've switched the client implementation to
API::IconLoadingClient too. So, I think you can just remove all the
WebCore and WebKit2 code after the patch lands.

https://bugs.webkit.org/show_bug.cgi?id=173877


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

Re: [webkit-dev] Intent to remove the WebCore::IconDatabase (GTK needs to make a decision)

[Carlos Garcia Campos]

El jue, 15-06-2017 a las 17:11 -0700, Brady Eidson escribió:
> Hi all,
> 
> The IconDatabase in WebCore is the source of crashes, spins, and
> complexity. Additionally it’s not flexible enough to acknowledge that
> there’s multiple types of site icons in use on the modern web, nor to
> adapt to the embedding client’s need for customization.
> 
> I recently introduced the “_WKIconLoadingDelegate” model to
> WebKit2Cocoa.
> 
> WebCore gathers all of the candidate icon URLs and asks the embedding
> app for each one whether or not it wants to load them.
> If the app says yes, the icon will be loaded as a subresource in the
> current document and the data will be handed off to the client.

Do we have any cache here? would we use the disk cache like with any
other subresource?

> From Apple’s perspective:
> 
> The new model is powerful and flexible enough that Safari has adopted
> it.
> In WebKit1, the “WebIconDatabase” class was never API and is
> currently unused.
> In WebKit2, the C-API support was never API and is currently unused.
> 
> Therefore we intend to remove the current WebCore IconDatabase from
> the project soon.

This is great news.

> Starting in on this task, I of course noticed GTK’s API has exposed
> “WebKitFaviconDatabase”
> 
> Is that something that’s published API and that is used?

Yes, it is part of our public API, so we need to keep backwards
compatibility.

> If not, I can get rid of it right now
> 
> If so, then I need a GTK maintainer to come up with a plan soon.

How soon is soon? :-) We are approaching the end of our release cycle,
it would be good for us if we could do any changes related to this
after we branch for 2.18. Of course I can branch earlier if needed.
According to our schedule we should branch the first week of August. Is
that late?

> The icon load delegate mechanism is powerful enough to rebuild an
> IconDatabase on top of, so if GTK needs to keep this API functional
> they can do so - maintaining the actual IconDatabase code themselves
> up in their API layer.

I have to look at it in detail. If I can use the new mechanism to
reimplement WebKitFaviconDatabase, I'll definitely do that. But if
there's no longer a database of favicons, I wouldn't mind to deprecate
it and provide a new better API. But in any case, I need to keep
WebKitFaviconDatabase working, whether using new way or moving the
current IconDatabase to wk2gtk.

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

Re: [webkit-dev] Commits in branches triggering build in the bots now

[Carlos Garcia Campos]

El jue, 04-05-2017 a las 09:51 -0700, Alexey Proskuryakov escribió:
> Hi Carlos,
> 
> Could you please file a bug, and include the relevant links to
> investigate the issue?

Sure. https://bugs.webkit.org/show_bug.cgi?id=171727 

> - Alexey
> 
> 
> > 4 мая 2017 г., в 0:46, Carlos Garcia Campos 
> > написал(а):
> > 
> > I don't know what have changed, but now, commits in other branches
> > are
> > triggering builds in the bots. I have just realized after merging a
> > couple of commits in GTK+ stable branch. This didn't happen before,
> > those commits didn't show in the bots at all. 
> > 
> > Any idea why is this happening now? I don't see any relevant change
> > in
> > the buildbot config. For now I'll stop merging commits because I
> > don't
> > want the bots to waste the time building and running tests when
> > nothing
> > has actually changed.
> > 
> > Thanks, 
> > Carlos Garcia Campos
> > ___
> > 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] Commits in branches triggering build in the bots now

[Carlos Garcia Campos]

I don't know what have changed, but now, commits in other branches are
triggering builds in the bots. I have just realized after merging a
couple of commits in GTK+ stable branch. This didn't happen before,
those commits didn't show in the bots at all. 

Any idea why is this happening now? I don't see any relevant change in
the buildbot config. For now I'll stop merging commits because I don't
want the bots to waste the time building and running tests when nothing
has actually changed.

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

Re: [webkit-dev] !!Tests for equality comparison

[Carlos Garcia Campos]

El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:
> Hello C++ fans!
> 
> The C++ style check currently say:
> Tests for true/false, null/non-null, and zero/non-zero should all be
> done without equality comparisons
> 
> I totally agree for booleans and pointers… but not for integers. I
> know it’s pretty much the same thing, but I it takes me slightly
> longer to process code like this:
> 
> int numTestsForEqualityComparison = 0:
> // Count ‘em!
> // …
> if (!numTestsForEqualityComparison)
>   printf(“Good job!”);
> 
> I read it as “if not number of tests for equality comparison”. That's
> weird. It takes me every slightly longer to think about, and I’ve
> gotten it wrong a bunch of times already. I’m not trying to check for
> “notness", I’m trying to say “if there were zero tests for equality
> comparison”, a.k.a.:
> 
> if (numTestsForEqualityComparison == 0)
>   printf(“Good job!”);
> 
> So how about the C++ style let me just say that? I’m not suggesting
> we advise using that style for integers everywhere, I’m just saying
> it should be acceptable to check zero/non-zero using equality
> comparison.

I agree, it's also quite confusing when using strcmp, because !strcmp
means the strings are equal. It's not only more difficult to read, I've
seen patches with wrong strcmp checks because of that.

> 
> !!Thanks (i.e. many thanks),
> 
> JF
> 
> p.s.: With you I am, fans of Yoda comparison, but for another day
> this will be.
> ___
> 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: upstream the WPE port

[Carlos Garcia Campos]

El dom, 23-04-2017 a las 22:12 -0700, Brady Eidson escribió:
> > On Apr 22, 2017, at 6:21 AM, Michael Catanzaro  > om> wrote:
> > 
> > I think Carlos's plan to reuse the non-GTK+ bits of the GTK+ API
> > would be much better for us.
> 
> I as long as the GTK and WPE ports like this plan (it appears they
> both are) and are both committed to see it to fruition (it appears
> they both are), then I fully support this.
> 
> I do *not* support adding another client of the C API, even in the
> interim.

It would be easier for us to move to the new API after the port is
upstream, since it will require refactorings in both ports GTK+ and WPE
. So, we can simply remove from the current patch anything added to the
C API (except the web view implementation or whatever is needed by WTR)
and then work on moving to the new API in follow up patches.

Are you ok with that?

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

Re: [webkit-dev] Proposal: upstream the WPE port

[Carlos Garcia Campos]

El sáb, 22-04-2017 a las 08:09 -0500, Michael Catanzaro escribió:
> On Sat, Apr 22, 2017 at 1:14 AM, Carlos Garcia Campos 
>  wrote:
> > The easiest way would be to reuse the GTK+ API. WPE has the same
> > dependencies than the GTK+ port except for GTK+ itself. The GTK+
> > API 
> > of
> > course depend on GTK+, but only for the WebView, and a few other
> > fallback implementations like the file chooser, color chooser,
> > printing, etc, that are, in any case, optional. So, we could move
> > 95%
> > of the GTK+ API to a common glib dir and reuse all that in WPE,
> > only
> > adding a WebView implementation for WPE.
> 
> I'm sure reimplementing WebKitWebView without GTK+ will be a lot of 
> work, and I'm pretty sure it's a lot more than 5% of the current
> API. 

I don't know why you are so sure. The idea is exactly the same to what
the C API was, a cross-platform API where ports only need to provide a
WebView implementation. WPE should already have one for the C API. Note
that I'm not proposing that WPE uses exactly the same WebKitWebView API
than the GTK+ port, but that they provide their own one. Only the
shared part of the API will be exactly the same, of course.

> But I like this plan. It will result in a dramatically better API
> for 
> WPE than what we have now. The cross-platform C API is not very
> good. 
> Our GObject-based GTK+ API is. Why didn't we consider this before? :)

Because everybody involved in WPE, devs and users, were/are happy with
the C API.

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

Re: [webkit-dev] Proposal: upstream the WPE port

[Carlos Garcia Campos]

El vie, 21-04-2017 a las 16:01 -0700, Geoffrey Garen escribió:
> I think the biggest consideration here is the problems we’ve noticed
> in the C API that have produced poor designs that we don’t intend to
> support going forward.
> 
> Does the WPE port’s API need to be backwards-compatible in a source
> or binary way?
> 
> Is it practical for the WPE port’s API to mirror the ObjC API?

The easiest way would be to reuse the GTK+ API. WPE has the same
dependencies than the GTK+ port except for GTK+ itself. The GTK+ API of
course depend on GTK+, but only for the WebView, and a few other
fallback implementations like the file chooser, color chooser,
printing, etc, that are, in any case, optional. So, we could move 95%
of the GTK+ API to a common glib dir and reuse all that in WPE, only
adding a WebView implementation for WPE.

> Thanks,
> Geoff
> 
> > On Apr 21, 2017, at 2:24 PM, Alex Christensen  > om> wrote:
> > 
> > This is exciting news, Zan!  I’m happy to see innovative new uses
> > of WebKit.
> > 
> > What kind of groups hope to use this new port?  What kind of groups
> > hope to maintain this new port?  Will it be beneficial to the
> > WebKit community to have their cooperative work?  I see having more
> > groups motivated to organize things in a supportable way as
> > positive.
> > 
> > I don’t think we should just use the C API as it is.  We want to
> > eventually remove it completely.  If we do upstream WPE, I propose
> > doing something like one of the following:
> > 1. We could make a new C API that more closely mirrors the Cocoa
> > API, to which we only add things we have committed to
> > support.  This should be done in collaboration with the existing
> > API owners.
> > 2. We could mark parts of the existing C API as part of the API we
> > have committed to maintaining.  There is a lot of messy stuff in
> > the existing C API we eventually want to remove even before we
> > remove the whole thing (old client versions, testing-only
> > functions, private functions that access things we want to
> > eventually organize differently, etc.).  For example, a lot of the
> > things in WKContextPrivate.h should be moved from a multi-process-
> > global approach to a WKWebView/WKPage-based organization.  The
> > basic concepts are here to stay, though.
> > 3. Have third parties who use the API just deal with whatever
> > changes we throw at them.  This could be viable if there were only
> > a few small groups using the API, but it would hinder innovative
> > use of the API.  We might want to reserve the right to make API
> > breaking changes anyway, though.
> > 
> > > On Apr 21, 2017, at 4:48 AM, z...@falconsigh.net wrote:
> > > 
> > > Hi,
> > > 
> > > the WebKit team at Igalia would like to propose upstreaming the
> > > WPE port
> > > of WebKit, taking on the duty to maintain it alongside the GTK+
> > > port.
> > > 
> > > The WPE port started in 2014 as the 'WebKit for Wayland' project
> > > inside
> > > Igalia [1].  The port was derived from the GTK+ port, but avoided
> > > dependency on any GUI toolkit.  It relied on the Wayland display
> > > protocol for on-screen presentation.  That dependency was later
> > > dropped
> > > in favor of using generic interfaces to adapt to different
> > > platform-specific presentation systems.  This allows any vendor
> > > to
> > > simply provide the necessary backend implementations that are
> > > tailored
> > > to their platform.
> > > 
> > > The port is intended to be the Web platform engine of choice for
> > > embedded Linux systems.  Since late 2014 Igalia has been
> > > sponsored by
> > > Metrological to further develop the WPE port, targeting primarily
> > > various set-top box platforms.  Miguel Gomez blogged about this
> > > effort
> > > back in December [2].  The port can also address other embedded
> > > use
> > > cases, for instance in-vehicle infotainment or digital signage.
> > > 
> > > The GTK+ and WPE ports mostly have the same dependencies except
> > > for the
> > > GTK+ toolkit library.  That enables the two ports to already
> > > share a lot
> > > of code.  The biggest difference between the two is that the WPE
> > > port
> > > exposes the WebKit2 C API, while the GTK+ port exposes a GObject-
> > > based
> > > API.  Apart from that, the maintainers' plan is to further align
> > > the two
> > > ports as much as possible, ideally simply stacking the GTK+ port
> > > on top
> > > of WPE, with only a few additional tweaks for GTK+
> > > integration.  This
> > > would lessen the maintenance burden for both ports and the
> > > project as a
> > > whole.
> > > 
> > > The WebKit team at Igalia thinks this port is on stable footing
> > > and has
> > > solid prospects for the future.  That's why we'd like to join the
> > > upstream community and continue our work there.
> > > 
> > > The patch with the port changes is in bug #171110 [3].  We have
> > > existing
> > > x86_64 buildbot configurations [4] that we would have to port
> > > over to
> > > the webkit.org 

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

[Carlos Garcia Campos]

El mar, 10-01-2017 a las 21:24 -0800, Myles C. Maxfield escribió:
> After 18 months of no progress, Don Olmstead and I are getting the
> band back together!

Great news. 

> We’ve uploaded a patch
> to https://bugs.webkit.org/show_bug.cgi?id=143358 which incorporates
> feedback from many different stakeholders (and as such, the direction
> is a little different than where I was going with this in the
> beginning).
> 
> First of all, this isn’t a new project; instead, it’s a new target
> inside the WebCore project. The target creates a static library which
> gets linked into WebCore, which means that the enforcement mechanism
> can’t be done by the linker. Instead, the layering will be enforced
> by a Python script, triggered as an extra build step, which checks
> the symbol names inside the .a file as well as #include directives in
> source code.

So, will it be possible to link to PAL but not the rest of WebCore?

> We opted for WebCore to include files using “#include ”
> instead of just including Foo.h. Similarly, we are putting symbols
> inside the PAL namespace, which is a child of the WebCore namespace.
> Therefore, inside WebCore, you use PAL things by specifying
> “PAL::Foo”.

And WebCore::PAL::Foo when used outside WebCore namespace, right?

> The first thing to move into PAL is the “crypto” subfolder, which is
> a good candidate because it’s small, simple, yet also has platform-
> dependent implementations.
> 
> We would love your feedback on this approach to help make the dream a
> reality!

I'm not sure I agree with the approach because I don't know the reasons
 to make it a target inside WebCore, could you elaborate more on that,
please?

> Thanks,
> Myles and Don
> 
> > On Mar 22, 2015, at 4:40 PM, Gavin Barraclough  > om> wrote:
> > 
> > > On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak 
> > > wrote:
> > > 
> > > Web Abstraction Toolbox (it’s hard to tell the difference between
> > > wat and WTF sometimes…)
> > 
> > +1
> > 
> > 
> > ___
> > 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] WebKit GPU rendering possibility

[Carlos Garcia Campos]

El jue, 03-11-2016 a las 07:50 +, Rogovin, Kevin escribió:
> Adding a new GraphicsContext is what I want to do as it seems the
> path of least pain and suffering. However, all the other things of a
> backend I do not need to do. I do not know how to add a
> GraphicsContext backend in terms of makefile magicks and
> configuration. I also do not know the plumbing for making it active.
> In theory, FastUIDraw's GraphicsContext will work on any platform
> that does OpenGL 3.3 or OpenGL ES 3.0. What is the plumbing to do
> this? Years ago I remember that the build configuration is what
> governed what backend was built... and I usually just piggy packed
> onto another... years ago I remember there was like an SDL style
> backend that did not require a large toolkit, just SDL.. is that
> still alive? where is it? I could piggy back the work there if it
> still is alive...
> 
> Also, to get permission to do this work, I need significant community
> enthusiasm otherwise I will not be able to justify the large amount
> of work needed. This is another area where I need a great deal of
> help.

The community enthusiasm will depend on how this performs in the end in
 web browser benchmarks, as others said in this thread. But to check
that you need to implement GraphicsContext first, so that's a bit
chicken-egg problem. 

What I can say as the GTK+ port maintainer is that we are very
interested in this. We are actually looking for a cairo replacement,
because unfortunately cairo is nowadays pretty much unmaintained. So,
if FastUIDraw can be used by the GTK+ port to replace cairo, and the
performance improvement is so impressive we would definitely switch.

You could start working on it on branch, we can help you with the
WebKit internal details (#webkitgtk+ on freenode, or webkit-gtk@lists.w
ebkit.org). And once you have something working we will also help you
to upstream your changes.

> Best Regards,
>  -Kevin Rogovin
> 
> -Original Message-
> From: Carlos Garcia Campos [mailto:carlo...@webkit.org] 
> Sent: Thursday, November 3, 2016 9:43 AM
> To: Rogovin, Kevin ; Myles C. Maxfield  fi...@apple.com>
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> 
> El jue, 03-11-2016 a las 07:35 +, Rogovin, Kevin escribió:
> > Hi,
> > 
> >  The main issue of making a Cairo backend to FastUIDraw is
> > clipping.
> > Cairo tracks the clipping region in CPU and does things that are
> > fine 
> > for CPU-based rendering (i.e. span based rendering) but are
> > absolutely 
> > awful for GPU rendering (from my slides, one sees that GL backed 
> > QPainter and Cairo do much worse than CPU backed). FastUIDraw only 
> > supports clipIn and clipOut and pushes all the clipping work to
> > the 
> > GPU with almost no CPU work. It does NOT track the clipping region
> > at 
> > all. I can give more technical details how it works (and those
> > details 
> > are why FastUIDraw cannot be used a backend for Cairo).
> > For those interested in where the code is located for clipping in 
> > FastUIDraw, it is located at src/fastuidraw/painter/painter.cpp,
> > methods clipInRect, clipOutPath and clipInPath. Their
> > implementations 
> > are very short and simple and are quite cheap on CPU.
> 
> I see. Then I guess adding a new GraphicsContext for FastUIDraw is
> the easiest and best way to try this out in WebKit. Would it be
> possible to  just add a new GraphicsContext implementation? or would
> you also need to change other parts of the graphics implementation or
> the GraphicsContext API itself?
> 
> > Best Regards,
> > -Kevin
> > 
> > -Original Message-
> > From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
> > Sent: Thursday, November 3, 2016 9:27 AM
> > To: Rogovin, Kevin ; Myles C. Maxfield
> >  > fi...@apple.com>
> > Cc: webkit-dev@lists.webkit.org
> > Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> > 
> > El jue, 03-11-2016 a las 06:58 +, Rogovin, Kevin escribió:
> > > Hi!
> > >  
> > > Question answers:
> > > 1.  Currently FastUIDraw has a backend to OpenGL 3.3 and
> > > OpenGL 
> > > ES 3.0. One of its design goals is to make it not terribly awful
> > > to 
> > > write a backend to different 3D API’s.
> > > 2.  I think I was unclear in my video. I have NOT migrated
> > > ANY 
> > > UI rendering library to use Fast UI Draw. What I have done is
> > > made a 
> > > demo
> > > (painter-cells) and ported that demo to Fast UI Draw, Cairo,
> > > Qt’s 
> > > QPainter and SKIA. The

Re: [webkit-dev] WebKit GPU rendering possibility

[Carlos Garcia Campos]

El jue, 03-11-2016 a las 07:35 +, Rogovin, Kevin escribió:
> Hi,
> 
>  The main issue of making a Cairo backend to FastUIDraw is clipping.
> Cairo tracks the clipping region in CPU and does things that are fine
> for CPU-based rendering (i.e. span based rendering) but are
> absolutely awful for GPU rendering (from my slides, one sees that GL
> backed QPainter and Cairo do much worse than CPU backed). FastUIDraw
> only supports clipIn and clipOut and pushes all the clipping work to
> the GPU with almost no CPU work. It does NOT track the clipping
> region at all. I can give more technical details how it works (and
> those details are why FastUIDraw cannot be used a backend for Cairo).
> For those interested in where the code is located for clipping in
> FastUIDraw, it is located at src/fastuidraw/painter/painter.cpp,
> methods clipInRect, clipOutPath and clipInPath. Their implementations
> are very short and simple and are quite cheap on CPU.

I see. Then I guess adding a new GraphicsContext for FastUIDraw is the
easiest and best way to try this out in WebKit. Would it be possible to
 just add a new GraphicsContext implementation? or would you also need
to change other parts of the graphics implementation or the
GraphicsContext API itself?

> Best Regards,
> -Kevin
> 
> -Original Message-
> From: Carlos Garcia Campos [mailto:carlo...@webkit.org] 
> Sent: Thursday, November 3, 2016 9:27 AM
> To: Rogovin, Kevin ; Myles C. Maxfield  fi...@apple.com>
> Cc: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] WebKit GPU rendering possibility
> 
> El jue, 03-11-2016 a las 06:58 +, Rogovin, Kevin escribió:
> > Hi!
> >  
> > Question answers:
> > 1.  Currently FastUIDraw has a backend to OpenGL 3.3 and OpenGL
> > ES 
> > 3.0. One of its design goals is to make it not terribly awful to
> > write 
> > a backend to different 3D API’s.
> > 2.  I think I was unclear in my video. I have NOT migrated ANY
> > UI 
> > rendering library to use Fast UI Draw. What I have done is made a
> > demo 
> > (painter-cells) and ported that demo to Fast UI Draw, Cairo, Qt’s 
> > QPainter and SKIA. The diffs between the ports is almost trivial
> > (it 
> > really is just using those different rendering API’s).
> 
> That makes me wonder, would it be possible to add a new cairo backend
> based on FastUIDraw? That would make very easy to try it out with the
> current GraphicsContext cairo backend.
> 
> > 3.  There are a few areas:
> > a.  Reduce some render to offscreen buffers. When I worked
> > with 
> > WebKit YEARS ago, I saw a few instances of rendering to texture
> > that 
> > are unnecessary and even harm performance for GPU rendering. The
> > first 
> > example was where a brush pattern with an image and/or gradient 
> > applied is to be drawn tiled across an area. WebKit (at that time) 
> > first drew a single instance of that pattern to an image, then
> > drew 
> > that image tiled. For GPU renderers we can (very easily) just do
> > the 
> > repeat pattern (of both original image and gradient) from a shader.
> > Another instance happens at RenderLayer where a new
> > GraphicsContext 
> > “layer” is started on a transformation that has rotation or 
> > perspective. For FastUIDraw, this is not necessary, though if a
> > layer 
> > is transparent, then it is.
> > b.  In addition, FastUIDraw has an interface so that if “what”
> > is 
> > drawn is unchanged but the “how” changes, then a caller can cache
> > the 
> > “what” to send to the GPU. To be explicit, “what” to draw is 
> > essentially attributes and indices and those values do NOT depend
> > on 
> > the state of “how” to draw. Examples of “how” to draw: current 
> > transformation, brush to apply, clipping applied, stroking
> > parameters 
> > (including dash pattern) and blending mode. I admit that I am
> > quite 
> > proud of being able to use the same attributes an indices even if 
> > stroking parameters (stroking width, miter limit and dash pattern) 
> > change. Text rendering “what” to draw does depend on what glyphs
> > one 
> > wants to use. Specifically, if drawing coverage font glyphs, then 
> > attributes and indices values change if one wants to draw the
> > glyph 
> > biffer, but for the GPU rendered glyphs they do not.
> > 4.  The renderer implements full 3x3 transformations. However,
> > the 
> > renderer does NOT implement out-of-order transparency. For a GPU,
> > a 
> > 3x3 transformation is cheap (naturally!). The renderer does
> > handle, 
> > with

Re: [webkit-dev] WebKit GPU rendering possibility

[Carlos Garcia Campos]

El jue, 03-11-2016 a las 06:58 +, Rogovin, Kevin escribió:
> Hi!
>  
> Question answers:
> 1.  Currently FastUIDraw has a backend to OpenGL 3.3 and OpenGL
> ES 3.0. One of its design goals is to make it not terribly awful to
> write a backend to different 3D API’s.
> 2.  I think I was unclear in my video. I have NOT migrated ANY UI
> rendering library to use Fast UI Draw. What I have done is made a
> demo (painter-cells) and ported that demo to Fast UI Draw, Cairo,
> Qt’s QPainter and SKIA. The diffs between the ports is almost trivial
> (it really is just using those different rendering API’s).

That makes me wonder, would it be possible to add a new cairo backend
based on FastUIDraw? That would make very easy to try it out with the
current GraphicsContext cairo backend.

> 3.  There are a few areas:
> a.  Reduce some render to offscreen buffers. When I worked with
> WebKit YEARS ago, I saw a few instances of rendering to texture that
> are unnecessary and even harm performance for GPU rendering. The
> first example was where a brush pattern with an image and/or gradient
> applied is to be drawn tiled across an area. WebKit (at that time)
> first drew a single instance of that pattern to an image, then drew
> that image tiled. For GPU renderers we can (very easily) just do the
> repeat pattern (of both original image and gradient) from a shader.
> Another instance happens at RenderLayer where a new GraphicsContext
> “layer” is started on a transformation that has rotation or
> perspective. For FastUIDraw, this is not necessary, though if a layer
> is transparent, then it is.
> b.  In addition, FastUIDraw has an interface so that if “what” is
> drawn is unchanged but the “how” changes, then a caller can cache the
> “what” to send to the GPU. To be explicit, “what” to draw is
> essentially attributes and indices and those values do NOT depend on
> the state of “how” to draw. Examples of “how” to draw: current
> transformation, brush to apply, clipping applied, stroking parameters
> (including dash pattern) and blending mode. I admit that I am quite
> proud of being able to use the same attributes an indices even if
> stroking parameters (stroking width, miter limit and dash pattern)
> change. Text rendering “what” to draw does depend on what glyphs one
> wants to use. Specifically, if drawing coverage font glyphs, then
> attributes and indices values change if one wants to draw the glyph
> biffer, but for the GPU rendered glyphs they do not.
> 4.  The renderer implements full 3x3 transformations. However,
> the renderer does NOT implement out-of-order transparency. For a GPU,
> a 3x3 transformation is cheap (naturally!). The renderer does handle,
> with a very little additional overhead changing clipping even between
> nasty rotations or perspective changes. The demo painter-cells
> deliberately pushes and does lots of nasty clipping and the
> performance impact of it on FastUIDraw is very small.
> 5.  Drawing text is a right pain in the rear. Currently,
> FastUIDraw has 3 methods to draw text: coverage, distance field and
> an original GPU algorithm that I devised for another open sourced
> project years ago. Coverage is needed when glyphs are drawn small and
> hinting becomes important. The original GPU algorithm keeps corners
> sharps and does a computation in the fragment shader to compute a
> coverage value. Distance field is a fall back which has render
> quality issues (namely corners are rounded) but is very, very cheap.
> I want to write an additional glyph renderer that is much faster than
> the original GPU method and keeps corners sharp. This new one is to
> use the ideas found in https://github.com/Chlumsky/msdfgen but I have
> a way to make the distance field generation much, much faster and
> handle natively cubics (instead of breaking cubics into quadratics)
>  
> For convenience, below is a list of features FastUIDraw implements:
> 1.  3x3 transformation matrix
> 2.  path stroking with anti-aliasing
> a.  dashed stroking too
> b.  miter, rouned, bevel joins
> c.  flat, square and rounded caps
> 3.  path filling against an arbitrary fill rule
> 4.  “brush”
> a.  linear gradients
> b.  two point conical gradients (I call these radial gradients)
> c.  images
>     i. nearest,
> bilinear and bicubic filtering
> 5.  Clipping
> a.  clipIn against rect or filled path (with arbitrary fill rule)
> b.  clipOut against path (with arbitrary fill rule)
> 6.  Glyph rendering
> a.  coverage fonts
> b.  1-channel distance field
> c.  curve-pair analytic (original algorithm)
> 7.  all 12 Porter-Duff blend modes
>  
> However, I still have work to do:
> 1.  anti-alias path fills
> 2.  anti-alias clipping
> 3.  more glyph rendering work
> 4.  some optimizations related to culling on path-fills
> 5.  dash pattern adjustments from contour

Re: [webkit-dev] [CMake] Bumping cmake_minimum_required

[Carlos Garcia Campos]

El mar, 20-09-2016 a las 10:39 -0500, Michael Catanzaro escribió:
> On Tue, 2016-09-20 at 18:35 +0900, Fujii Hironori wrote:
> > 
> > I'm interested in bumping cmake_minimum_required for
> > .
> > Which version of CMake is minimum version to be supported?
> 
> Hi,
> 
> WebKitGTK+ intends to continue supporting 2.8.12 until April, when we
> drop support for Ubuntu 14.04. So the new features you want to use
> should be used conditionally on the CMake version being high enough,
> without bumping the minimum requirement.

So, is our deps policy about build-time only dependencies too? I don't
think it should be. We want people to be able to *use* recent
WebKitGTK+ in older distros, mainly because sometimes full upgrade is
the only way to get security updates. But people *building* WebKitGTK+
can build also any dependency that is missing or not recent enough in
their distro. So, I think we should always allow to bump requirements
of build-only dependencies (CMake, GCC/clang, perl, python, ruby, etc.)
if it helps the project maintenance.

> 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] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 08:54 +0200, Carlos Garcia Campos escribió:
> El lun, 29-08-2016 a las 10:01 -0700, Darin Adler escribió:
> > 
> > > 
> > > On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos  > > t.
> > > org> wrote:
> > > 
> > > Does that mean than from the WebIDL point of view all methods can
> > > now
> > > raise a exception? If don't tell the code generator that a method
> > > can
> > > raise a exception, we assume all could return a Exception?
> > 
> > Correct.
> > 
> > Once the transition is done, the IDL will no longer indicate which
> > functions can raise exceptions; the return types of C++ member
> > functions will, instead. During the transition, exceptions can be
> > indicated in either way.
> > 
> > > 
> > > It actually depends on whether this is an exception or not.
> > 
> > I’m not sure exactly what you mean. But I expect us to keep driving
> > JavaScript DOM bindings forward in lots of ways. Here are a few:
> > 
> > - We will add support for more WebIDL features. There are many
> > still
> > to go. In some cases that means removing code that is currently in
> > the DOM that is doing part of the bindings work and using WebIDL to
> > implement this things. For example, translation of strings into
> > enum
> > values. WebIDL includes a specification of how all these features
> > are
> > reflected in JavaScript, but for non-JavaScript bindings we have to
> > define how to reflect each feature.
> > 
> > - We will add better exception messages, which means DOM code has
> > to
> > provide more than an exception code.
> > 
> > - We will update bindings with changes to move the web platform
> > forward, with JavaScript-specific strategies for backward
> > compatibility that won’t necessarily work for other languages such
> > as
> > Objective-C. For example, the latest specifications turn
> > DOMImplementation.hasFeature into a function that ignores its
> > arguments and always returns true. That’s easy to implement with
> > WebIDL for JavaScript, but for GObject and Objective-C we need code
> > somewhere that remembers what the old argument list was.
> > 
> > - We will update bindings with changes that have minimal observable
> > effect in the JavaScript type system but have effects on types of
> > arguments or return values in GObject bindings, such as making a
> > return type more specific (Attr instead of Node) or changing which
> > numeric type is used.
> > 
> > - We will move things currently done in the DOM itself into the
> > bindings.
> > 
> > - We would like to change the bindings generation scripts to run
> > more
> > quickly and so that fewer run when a given IDL source file is
> > changed.
> > 
> > > 
> > > If you really think that build is going to be broken often
> > > because
> > > of things very difficult to do in the GObject bindings, then we
> > > should indeed find a more general solution. Otherwise I prefer to
> > > solve this problem now, and keep the existing way of generating
> > > the
> > > bindings. We can add a rule that you can break the GObject DOM
> > > bindings build, to not block your work, and I'll try to fix it
> > > asap
> > > as we currently do with WebKit2.
> > 
> > Something like this might work. But coping with these changes is
> > going to be challenging.
> > 
> > I expect we are going to continue to run into many things we want
> > to
> > do for JavaScript that are difficult to do in the GObject bindings.
> > It’s taken many people hundreds of hours already to add these
> > various
> > WebIDL features for the JavaScript bindings, and each one involved
> > changing both the bindings and the underlying DOM implementation.
> > 
> > I think the 88 already existing #if statements in the IDL are one
> > indication that the IDL-based code generation strategy isn’t
> > working
> > very well; *many* features that are simply not supported outside
> > the
> > JavaScript code generator because they use one of the newer IDL
> > features are another.
> > 
> > If you read the latest WebIDL draft <https://heycam.github.io/webid
> > l/
> > > 
> > > you will see lots of features that are tricky to deal
> > with—dictionary types, enumeration types, callback function types,
> > promise types, union types, regular expressions, frozen arrays,
> > stringifiers, serializers, indexed pr

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 19:00 +0200, Carlos Garcia Campos escribió:
[...]
> I just need some time, I'm very busy this week because I have to make
> a
> new branch for WebKitGTK+ 2.14 and prepare a new release. Good thing
> is
> that I made the branch today, so changes in trunk are less risky for
> us
> now, and I plan to make the release tomorrow. As soon as the release
> is
> out, I'll start working on the bindings freeze.

I've just attached a patch here:
https://bugs.webkit.org/show_bug.cgi?id=161438

For now I've copied all the generated code, as a first step, but I
think we can actually remove a lot of code from the unstable part that
nobody is using. But before removing anything, I need to check what
unstable APIs applications are using and ask the WebKitGTK+ community.
Then I'll move all that to the stable part and remove the rest of the
unstable API, since we can add any new API on demand if any
applications need it.

> > 
> > — Darin
-- 
Carlos Garcia Campos
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 09:52 -0700, Darin Adler escribió:
> Thanks for the frank discussion, guys.
> 
> I do think we may be able to make the GObject bindings better and
> better over time even if they are hand written rather than generated.

Exactly.

> I understand that you want to keep them vital and up to date in a way
> that the Apple folks are not planning to do for the Objective-C
> bindings. Given the goal to have them be stable even while adding new
> capabilities with new ones, I hope it will be practical to make them
> great without using automatic generation.

We split the API long time ago and since then we have never added new
methods/properties to the stable part, and very few applications use
the unstable part (and they only use one or two methods). So, I don't
think it will be a problem at all to stop auto-generating them.

> I also think it’s worth further discussion with some of the folks at
> Apple who also want to make sure we have great API for use inside
> injected bundles. We might come up with some idea that is excellent
> both for Cocoa and GTK.
> 
> Can we plan how to do the transition off of automatic generation now,
> or is there anyone else we should consult?

I just need some time, I'm very busy this week because I have to make a
new branch for WebKitGTK+ 2.14 and prepare a new release. Good thing is
that I made the branch today, so changes in trunk are less risky for us
now, and I plan to make the release tomorrow. As soon as the release is
out, I'll start working on the bindings freeze.

> — Darin
-- 
Carlos Garcia Campos
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 06:10 -0500, Michael Catanzaro escribió:
> I'm OK with freezing the bindings. I'm disappointed in that these are
> a
> killer feature for us and they'll never get improved now, but
> generating them seems to be causing too many problems that we cannot
> easily solve.

why do you say they are never going to be improved? we haven't even
started to decide what we are going to do. The only change for now is
that they are not going to be auto-generated.

> On Tue, 2016-08-30 at 08:54 +0200, Carlos Garcia Campos wrote:
> > 
> > haha, no, of course I'm not, but I'm not Ok with the WebKit2 rules
> > either and I just live with that :-) Anyway, I think freezing the
> > GObject API is harmless and it's better for everybody.
> 
> The difference is that the GObject bindings are a seriously difficult
> issue for Apple that materially slows down their development (or at
> least appears to me to do so). It's impressive how much extra effort
> Apple devs (hi Chris) have spent trying to keep our bindings building
> (thanks!), but I don't think it's reasonable to expect them to do so.
> As much as we appreciate it, really nobody should be spending an
> afternoon uploading speculative patches to try to please our bindings
> generator. Anyway, if we freeze the API, this becomes a moot point.
> 
> WebKit2 is totally different. When WebKit2 breaks (which has
> fortunately become much rarer nowadays than it used to be) it's
> usually
> something very very easy to fix -- a function gains an extra
> parameter
> or a pointer becomes a reference or something -- and it just feels
> borderline spiteful to not spend five minutes with 'git grep' to
> avoid
> breaking us. It's not as if WebKit2 is somehow less important to us
> than WebCore

I guess you never had to deal with any failure.

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

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 10:01 -0700, Darin Adler escribió:
> > On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos  > org> wrote:
> > 
> > Does that mean than from the WebIDL point of view all methods can
> > now
> > raise a exception? If don't tell the code generator that a method
> > can
> > raise a exception, we assume all could return a Exception?
> 
> Correct.
> 
> Once the transition is done, the IDL will no longer indicate which
> functions can raise exceptions; the return types of C++ member
> functions will, instead. During the transition, exceptions can be
> indicated in either way.
> 
> > It actually depends on whether this is an exception or not.
> 
> I’m not sure exactly what you mean. But I expect us to keep driving
> JavaScript DOM bindings forward in lots of ways. Here are a few:
> 
> - We will add support for more WebIDL features. There are many still
> to go. In some cases that means removing code that is currently in
> the DOM that is doing part of the bindings work and using WebIDL to
> implement this things. For example, translation of strings into enum
> values. WebIDL includes a specification of how all these features are
> reflected in JavaScript, but for non-JavaScript bindings we have to
> define how to reflect each feature.
> 
> - We will add better exception messages, which means DOM code has to
> provide more than an exception code.
> 
> - We will update bindings with changes to move the web platform
> forward, with JavaScript-specific strategies for backward
> compatibility that won’t necessarily work for other languages such as
> Objective-C. For example, the latest specifications turn
> DOMImplementation.hasFeature into a function that ignores its
> arguments and always returns true. That’s easy to implement with
> WebIDL for JavaScript, but for GObject and Objective-C we need code
> somewhere that remembers what the old argument list was.
> 
> - We will update bindings with changes that have minimal observable
> effect in the JavaScript type system but have effects on types of
> arguments or return values in GObject bindings, such as making a
> return type more specific (Attr instead of Node) or changing which
> numeric type is used.
> 
> - We will move things currently done in the DOM itself into the
> bindings.
> 
> - We would like to change the bindings generation scripts to run more
> quickly and so that fewer run when a given IDL source file is
> changed.
> 
> > If you really think that build is going to be broken often because
> > of things very difficult to do in the GObject bindings, then we
> > should indeed find a more general solution. Otherwise I prefer to
> > solve this problem now, and keep the existing way of generating the
> > bindings. We can add a rule that you can break the GObject DOM
> > bindings build, to not block your work, and I'll try to fix it asap
> > as we currently do with WebKit2.
> 
> Something like this might work. But coping with these changes is
> going to be challenging.
> 
> I expect we are going to continue to run into many things we want to
> do for JavaScript that are difficult to do in the GObject bindings.
> It’s taken many people hundreds of hours already to add these various
> WebIDL features for the JavaScript bindings, and each one involved
> changing both the bindings and the underlying DOM implementation.
> 
> I think the 88 already existing #if statements in the IDL are one
> indication that the IDL-based code generation strategy isn’t working
> very well; *many* features that are simply not supported outside the
> JavaScript code generator because they use one of the newer IDL
> features are another.
> 
> If you read the latest WebIDL draft <https://heycam.github.io/webidl/
> > you will see lots of features that are tricky to deal
> with—dictionary types, enumeration types, callback function types,
> promise types, union types, regular expressions, frozen arrays,
> stringifiers, serializers, indexed properties, named properties,
> overloading, map like, setlike—the only reason this is not a crisis
> is that many web APIs are old and so not built on any of these new
> concepts. Over time, critical features are being built on them.

Ok, I think we can freeze the GObject bindings too, and then see how
things go and decide what to do. From the users point of view there
will be no difference, the current API will be available and working.
Then, you can add any new features to WebIDL without having to worry
about GObject bindings and we can take our time to discuss what to do.

> I am OK with the “it is OK to break the GObject bindings build”
> strategy, I guess, but are you sure you are OK with that?

haha

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 07:54 -0500, Michael Catanzaro escribió:
> On Mon, 2016-08-29 at 14:45 +0200, Carlos Garcia Campos wrote:
> > 
> > I agree this is not ideal for a GObject API, but I really don't see
> > how
> > this is a major problem, to be honest.
> 
> The problem is that you would either have to check for errors on
> every
> function call, including the 95% of function calls that cannot throw
> errors, or just ignore all errors.

That's why I asked Darin if now all DOM methods can raise exceptions,
because that information is no longer in the idl. If we keep the GError
model, we would need to add a GError parameter to every public method,
so that would be the same problem. If we change the exception model and
we know which methods can raise exceptions we can simply document it.

I see a problem for gobject-instrospection bindings more than C
developers.

> I guess if most API users ignore errors, it's not such a big deal.
> 
> Michael
> 
-- 
Carlos Garcia Campos

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

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 07:21 -0500, Michael Catanzaro escribió:
> On Mon, 2016-08-29 at 10:16 +0200, Carlos Garcia Campos wrote:
> > 
> > We basically have a Exception member
> > in WebKitDOMObject base class that is reset for every method call,
> > and
> > set in case of exception. Then we add
> > webkit_dom_object_get_exception()
> > to query if there were a exception. That's not the GLib way, but
> > DOM
> > bindings is a special API anyway.
> 
> It would be a major usability regression for developers. :(
> 

I don't see why. Most of the code using DOM bindings simply ignores the
errors, and existing code is not going to change. I don't see any major
usability issue, neither any regression at all. Is it really a major
usability going from:

GError *error = NULL;
webkit_dom_foo_do_bar (foo, &error);
if (error) {
    handle_error();
    g_error_free (error);
}

to

webkit_dom_foo_do_bar (foo);
error = webkit_dom_foo_get_error (foo);
if (error)
    handle_error();

It even has advantages, for example if you are not interested in the
error details you can null-check the return value of get_error()
without having to worry about freeing the GError. 

I agree this is not ideal for a GObject API, but I really don't see how
this is a major problem, to be honest.

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

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

ipt bindings; we have a lot of work to do on those and
> we are not easily able to make the gobject bindings come along. There
> are all sorts of new WebIDL features that we cannot easily implement
> for gobject without considerable effort, such as enum and union
> types, various types of overloading and default argument values,
> setlike, the list goes on and on and this has been going on for
> months at least already. There’s a good reason we did this “freezing”
> for Objective-C and it seems likely to be worthwhile for gobject too.
> This will also let us get rid of the 88 places in the IDL files where
> we have gobject-binding-specific #if statements, many of which were
> originally added for Objective-C and probably have not all been
> carefully audited.

That worked for Objective-C because the DOM bindings are no legacy
WebKit, but that's not the case of the GObject bindings. I never liked
the ifdefs in the idl files, maybe we can find a different way to move
that to the code generator itself to skip whatever.

> 
> Option 2) Express the list of which functions have a GError** out
> argument as an explicit list of function names inside the gobject
> bindings generator and generate code accordingly. This is not all
> that farfetched given we already have .symbols files to help keep the
> set of gobject bindings functions stay stable, and there is already a
> list inside the bindings generator of functions that used to raise
> exceptions and therefore have a GError** out argument that is never
> used, showing that this issue is not a new one. Compared to (1) this
> is just a stopgap measure. It can keep existing functions working,
> but does not give us a clear path for what to do as we add more and
> more DOM APIs that don’t fit in with what the gobject binding code
> generator can do.

Exceptions are indeed the main cause of API breaks in GObject DOM
bindings, methods that now raise exceptions or the other way around.
New WebIDL features that don't fit in GObject model are not a problem
at all, as long as they don't affect the existing stable API, are there
other features planned that you think can break existing stable API?

> 
> Option 3) Keep the extended attributes telling whether something
> raises exceptions in the IDL files as gobject-specific attributes
> that are ignored by the JavaScript bindings.
> 
> Are there other practical options?

Yes, I think so, at least for the exceptions issue. If there will
actually be more changes like this maybe we need to find another
solution more general. But for the particular case of extensions, I
think we can find a different way to handle exceptions in GObject API.
We are using the GError because it's the GLib way, but it's very
problematic for generated code like this. We are limited to C, so we
can probably move to a global way to ask for exception. this could even
be limited to a particular object. We basically have a Exception member
in WebKitDOMObject base class that is reset for every method call, and
set in case of exception. Then we add webkit_dom_object_get_exception()
to query if there were a exception. That's not the GLib way, but DOM
bindings is a special API anyway. That would allow to change the
methods that can raise exceptions without affecting the API anymore. To
not break the API, we would need to collect the current methods in the
stable API that have a GError parameter, and handle them manually.

> 
> I strongly prefer option 1, and I would like to hear from the people
> who are working to make the gobject bindings work well to get an idea
> of how they feel about this and how they’d like to proceed, before I
> decide what to do.

It actually depends on whether this is an exception or not. If you
really think that build is going to be broken often because of things
very difficult to do in the GObject bindings, then we should indeed
find a more general solution. Otherwise I prefer to solve this problem
now, and keep the existing way of generating the bindings. We can add a
rule that you can break the GObject DOM bindings build, to not block
your work, and I'll try to fix it asap as we currently do with WebKit2.

> 
> — Darin
>  
-- 
Carlos Garcia Campos
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Some text about the B3 compiler

[Carlos Garcia Campos]

El dom, 31-01-2016 a las 06:00 +0900, Yusuke SUZUKI escribió:
> Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and https://bugs.
> webkit.org/show_bug.cgi?id=153711 are landed.

Awesome, thanks for fixing those issues so quickly.

> So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's
> time to enable B3 in Linux x64 :D

Indeed!

> Regards,
> Yusuke Suzuki
> 
> On Sat, Jan 30, 2016 at 8:09 AM, Filip Pizlo 
> wrote:
> > Follow up on this:
> > 
> > > On Jan 29, 2016, at 11:38 AM, Filip Pizlo 
> > > wrote:
> > > 
> > > I started coverting the documentation to Markdown.  I don’t think
> > > this is a good idea.
> > > 
> > > - Markdown has no definition lists.  The entire IR document is a
> > > definition list.  I don’t want B3’s documentation to be blocked
> > > on this issue.
> > It turns out that it does have them, but they are very weak.  For
> > example, you can’t have code blocks or paragraphs inside them.  We
> > want to have code blocks inside opcode definitions, to show
> > examples.
> > 
> > > - Markdown’s conversion step makes the workflow awkward.  I’m not
> > > going to use some Markdown editing app - that will prevent me
> > > from being able to properly format code examples.  I need a code
> > > editor for that.
> > This was hard to get around.  This isn’t a problem with Markdown,
> > but rather, a problem with using Wordpress to render Markdown that
> > is in svn.  There is no way to preview the Markdown before
> > committing it.  That would lead to unusual problems, where after a
> > patch is landed, the patch author or someone else would have to do
> > a bunch of blind follow-up commits to fix any style issues, like
> > code blocks that don’t fit properly or whatever.
> > 
> > Considering that we will have to be hacking raw HTML inside those
> > Markdown files (due to definition lists), the lack of preview
> > basically means that you have no way of predicting what the your
> > HTML will render like.
> > 
> > > 
> > > I think that this documentation should be HTML.  I don’t think we
> > > should expend a lot of energy to formatting it nicely.  The point
> > > of this document is for it to be read by engineers while they
> > > hack code.
> > I landed raw HTML documentation: http://trac.webkit.org/changeset/1
> > 95841
> > 
> > I filed this bug about improving its style: https://bugs.webkit.org
> > /show_bug.cgi?id=153674
> > 
> > -Filip
> > 
> > 
> > > 
> > > -Filip
> > > 
> > > 
> > > > On Jan 29, 2016, at 10:12 AM, Timothy Hatcher  > > > m> wrote:
> > > > 
> > > > I also added:
> > > > 
> > > > https://webkit.org/documentation/b3/air/ loads /docs/b3/assembl
> > > > y-intermediate-representation.md
> > > > 
> > > > > On Jan 29, 2016, at 10:05 AM, Filip Pizło 
> > > > > wrote:
> > > > > 
> > > > > Thank you!  I'll convert them today. 
> > > > > 
> > > > > -Filip
> > > > > 
> > > > > On Jan 29, 2016, at 10:02 AM, Timothy Hatcher  > > > > com> wrote:
> > > > > 
> > > > > > Markdown is pretty similar to the wiki formatting and very
> > > > > > simple.
> > > > > > 
> > > > > > You can look at a cheatsheet if you login to the blog: http
> > > > > > s://webkit.org/wp/wp-admin/post.php?post=4300&action=edit
> > > > > > 
> > > > > > I have also used this HTML to Markdown converter before: ht
> > > > > > tp://domchristie.github.io/to-markdown/
> > > > > > 
> > > > > > The pages are created:
> > > > > > 
> > > > > > https://webkit.org/documentation/b3/ loads /docs/b3/bare-bo
> > > > > > nes-backend.md
> > > > > > https://webkit.org/documentation/b3/intermediate-representa
> > > > > > tion/ loads /docs/b3/intermediate-representation.md
> > > > > > 
> > > > > > Once those files are added to SVN, they will get picked up
> > > > > > by the site. I can change those to point to other names if
> > > > > > you want something different.
> > > > > > 
> > > > > > — Timothy Hatcher
> > > > > > 
> > > > > > > On Jan 29, 2016, at 9:34 AM, saam barati  > > > > > > il.com> wrote:
> > > > > > > 
> > > > > > > I'm happy to convert the document to markdown. Can you
> > > > > > > send me your latest revision or post it to the website?
> > > > > > > 
> > > > > > > I usually look at:
> > > > > > > http://daringfireball.net/projects/markdown/syntax
> > > > > > > For a refresher on the syntax.
> > > > > > > 
> > > > > > > Tim, could you create a page that loads the markdown
> > > > > > > file?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Saam
> > > > > > > 
> > > > > > > On Jan 29, 2016, at 12:06 AM, Filip Pizło  > > > > > > om> wrote:
> > > > > > > 
> > > > > > > > I'm all for this but I don't know anything about
> > > > > > > > markdown. 
> > > > > > > > 
> > > > > > > > What's the best way to proceed?
> > > > > > > > 
> > > > > > > > -Filip
> > > > > > > > 
> > > > > > > > On Jan 28, 2016, at 9:24 PM, Timothy Hatcher  > > > > > > > pple.com> wrote:
> > > > > > > > 
> > > > > > > > > They should be markdown files like we do for the code
> > > > > > > > > style and policy documents.
> > > > > > > > >

Re: [webkit-dev] Some text about the B3 compiler

[Carlos Garcia Campos]

El sáb, 30-01-2016 a las 20:16 -0800, Filip Pizlo escribió:
> Michael,
> 
> As my original message said, I was wondering if there was any support
> for running some JavaScript tests *in browser*.  run-jsc-stress-tests 
> doesn’t support that because it doesn’t know what a browser is.
> 
> Some tests, like Kraken, Octane, JetStream, and Speedometer, either
> require a browser to run (like JetStream and Speedometer) or have
> significantly different behavior in the browser than in their
> command-line harnesses (like Kraken and Octane).  If you did have a
> bot that ran these tests in some GTK+ or EFL browser, you’d probably
> catch bugs that testing the JSC shell cannot catch.

We should definitely do that. We are quite late already in our release
cycle, so if we are going to switch to B3 at this point, we really need
a lot more testing. 

> -Filip
> 
> 
> > On Jan 30, 2016, at 7:50 PM, Michael Catanzaro  > om> wrote:
> > 
> > On Sat, 2016-01-30 at 16:06 -0800, Filip Pizło wrote:
> > > Do we have Linux bots that run Octane, Speedometer, JetStream and
> > > Kraken in browser?
> > > 
> > > We find that this catches a lot of bugs that none of the other
> > > tests
> > > catch. 
> > > 
> > > -Filip
> > 
> > This is the command that the bots run:
> > 
> > /usr/bin/env ruby Tools/Scripts/run-jsc-stress-tests -j
> > /home/slave/webkitgtk/gtk-linux-64-release-
> > tests/build/WebKitBuild/Release/bin/jsc -o
> > /home/slave/webkitgtk/gtk-
> > linux-64-release-tests/build/WebKitBuild/Release/bin/jsc-stress-
> > results 
> > PerformanceTests/SunSpider/tests/sunspider-1.0
> > PerformanceTests/JetStream/cdjs/cdjs-tests.yaml
> > Source/JavaScriptCore/tests/executableAllocationFuzz.yaml
> > Source/JavaScriptCore/tests/exceptionFuzz.yaml
> > PerformanceTests/SunSpider/no-architecture-specific-
> > optimizations.yaml
> > PerformanceTests/SunSpider/tests/v8-v6
> > Source/JavaScriptCore/tests/mozilla/mozilla-tests.yaml
> > Source/JavaScriptCore/tests/stress LayoutTests/js/regress/script-
> > tests
> > PerformanceTests/SunSpider/profiler-test.yaml LayoutTests/jsc-
> > layout-
> > tests.yaml Source/JavaScriptCore/tests/typeProfiler.yaml
> > Source/JavaScriptCore/tests/controlFlowProfiler.yaml
> > Source/JavaScriptCore/tests/es6.yaml
> > Source/JavaScriptCore/tests/modules.yaml --ftl-jit --
> > 
> > I see SunSpider and JetStream in there, but not the others
> > 
> > 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] NetworkSession

[Carlos Garcia Campos]

El mié, 18-11-2015 a las 15:58 -0800, Alex Christensen escribió:
> As part of this work, I’m also planning to remove the non-
> NetworkProcess code, both run time and compile time. Based on
> discussion at the WebKit contributors’ meeting I assume there is no
> objection to this.  See https://bugs.webkit.org/show_bug.cgi?id=15141
> 8

No objections for GTK port. I guess then the single process model will
become multiple model with max process limit = 1 internally, right?
 That's what we did in epiphany in preparation for this change. Or do
you plan to remove/deprecate the single process model?

> Alex
> 
> > On Nov 9, 2015, at 11:32 AM, Alex Christensen  > om> wrote:
> > 
> > I made new abstractions for loading in WebKit2: NetworkSession and
> > NetworkDataTask.  It is disabled by default right now, but if you
> > switch USE_NETWORK_SESSION to 1, it mostly works on Mac with
> > features like authentication challenges not implemented yet.  I
> > believe these new abstractions fit better with libsoup, but I’d
> > like feedback on what an actual libsoup implementation would need.
> >  I’m planning on removing the ResourceHandle use in WebKit2 and the
> > async/continue callbacks in ResourceHandleClient and ResourceHandle
> > once this work is done.
> > 
> > Alex
> > 
> > ___
> > 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] HA: Problem with -webkit-gradient css option on MIPS platform.

[Carlos Garcia Campos]

El mié, 30-09-2015 a las 07:33 +, Pushkin Andrei escribió:
> A talk about webkitgtk (webkitgtk-1.10.0.tar.xz). Both version build
> from one sources with similar configure options. 
> Why webkit can not show -webkit-gradient on buttons? Is it bug or
> some webkit settings?

WebKitGTK+ 1.10 was released 3 years ago, I would try with a recent
version.

> Andrei Pushkin
> От: mmaxfi...@apple.com [mmaxfi...@apple.com]
> Отправлено: 29 сентября 2015 г. 23:37
> Кому: Pushkin Andrei
> Копия: webkit-dev@lists.webkit.org
> Тема: Re: [webkit-dev] Problem with -webkit-gradient css option on
> MIPS platform.
> 
> Are you sure that the two versions of webkit are exactly the same?
> Same operating system, same port, same SVN revision?
> 
> AFAIK, WebKit itself has no concept of "1.10." That version number
> belongs to whichever project you are getting WebKit from. That
> project may have built WebKit on the two different platforms
> differently. (Someone else on the team: Please correct me if I'm
> wrong.)
> 
> --Myles
> 
> > On Sep 29, 2015, at 8:35 AM, Pushkin Andrei <
> > andrei.push...@promwad.com> wrote:
> > 
> > Hi. I have embedded Linux MIPS board with webkit 1.10.
> > This code does not work on my MIPS board (-webkit-gradient is
> > ignored):
> > ABC
> > But work in my x86 PC on same version of webkit.
> > 
> > This code work fine in all platforms:
> > ABC
> > 
> > Andrei Pushkin
> > ___
> > 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] Windows Build Now on VS2015

[Carlos Garcia Campos]

El mar, 25-08-2015 a las 14:29 +0200, z...@falconsigh.net escribió:
> On Tue, Aug 25, 2015, at 12:55 PM, Carlos Garcia Campos wrote:
> > El mar, 25-08-2015 a las 12:47 +0200, z...@falconsigh.net escribió:
> > > On Fri, Aug 14, 2015, at 07:19 PM, Alex Christensen wrote:
> > > > The days of supporting VS2013 are behind us, so if it works 
> > > > with 
> > > > VS2015, go for it.  Not all c++14 features are supported, 
> > > > though. 
> > > >  See 
> > > > https://msdn.microsoft.com/en
> > > > -us/library/hh567368.aspx#cpp14table
> > > >  
> > > > I’m not sure what the oldest gcc we support is.
> > >  
> > > The oldest GCC we support is 4.7.0.
> > 
> > Nope, we bumped it to 4.9.0 because of the bug in 4.8 that caused
> > failures in the database process implementation (see bug #98932).
> >  
> 
> The EFL port didn't, to the best of my knowledge.

Ah!, I assumed that with "we" you meant "the GTK+ port" :-)

> > > GCC 5.0 supports all but one C++14 proposal (which covers 
> > > allocation 
> > > optimizations and shouldn't be a blocker):
> > > https://gcc.gnu.org/projects/cxx1y.html
> > 
> > My main concern is how stable those features are in GCC, though.
> >  
> > > Clang has full C++14 coverage since version 3.4, but I'm not 
> > > aware of 
> > > any incorporated check for a minimal Clang version.
> > >  
> > > > > On Aug 14, 2015, at 5:49 AM, Antti Koivisto  
> > > > > 
> > > > > wrote:
> > > > >  
> > > > > Does this mean we can start using (most) C++14 features?
> > > > >  
> > > > >  
> > > > >   antti
> > > > >  
> > > > >  
> > > > > On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham <
> > > > > bfulg...@apple.com> wrote:
> > > > > Hi Floks,
> > > > >  
> > > > > We’ve finished updating the various Windows builds to VS2015. 
> > > > > 
> > > > > Full regression tests are now completing on these new builds, 
> > > > > and 
> > > > > seem to be comparable in terms of stability and correctness.
> > > > >  
> > > > > Please let me know if you encounter any new issues on 
> > > > > Windows. I 
> > > > > know that EA encountered some JavaScript issues in a prior 
> > > > > revision, but I haven’t been able to replicate this problem 
> > > > > (at 
> > > > > least yet).
> > > > >  
> > > > > VS2015 is churning out a number of new build warnings, which 
> > > > > I 
> > > > > hope to address over the coming weeks. It will also likely 
> > > > > have 
> > > > > some useful static analysis results in the Windows-specific 
> > > > > portions of the code that we should evaluate.
> > > > >  
> > > > > Thanks,
> > > > >  
> > > > > -Brent
> > > > > ___
> > > > > 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
> > >  
> > > ___
> > > 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Windows Build Now on VS2015

[Carlos Garcia Campos]

El mar, 25-08-2015 a las 12:47 +0200, z...@falconsigh.net escribió:
> On Fri, Aug 14, 2015, at 07:19 PM, Alex Christensen wrote:
> > The days of supporting VS2013 are behind us, so if it works with 
> > VS2015, go for it.  Not all c++14 features are supported, though. 
> >  See 
> > https://msdn.microsoft.com/en-us/library/hh567368.aspx#cpp14table
> >  
> > I’m not sure what the oldest gcc we support is.
>  
> The oldest GCC we support is 4.7.0.

Nope, we bumped it to 4.9.0 because of the bug in 4.8 that caused
failures in the database process implementation (see bug #98932).
 
> GCC 5.0 supports all but one C++14 proposal (which covers allocation 
> optimizations and shouldn't be a blocker):
> https://gcc.gnu.org/projects/cxx1y.html

My main concern is how stable those features are in GCC, though.
 
> Clang has full C++14 coverage since version 3.4, but I'm not aware of 
> any incorporated check for a minimal Clang version.
>  
> > > On Aug 14, 2015, at 5:49 AM, Antti Koivisto  
> > > wrote:
> > >  
> > > Does this mean we can start using (most) C++14 features?
> > >  
> > >  
> > >   antti
> > >  
> > >  
> > > On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham <
> > > bfulg...@apple.com> wrote:
> > > Hi Floks,
> > >  
> > > We’ve finished updating the various Windows builds to VS2015. 
> > > Full regression tests are now completing on these new builds, and 
> > > seem to be comparable in terms of stability and correctness.
> > >  
> > > Please let me know if you encounter any new issues on Windows. I 
> > > know that EA encountered some JavaScript issues in a prior 
> > > revision, but I haven’t been able to replicate this problem (at 
> > > least yet).
> > >  
> > > VS2015 is churning out a number of new build warnings, which I 
> > > hope to address over the coming weeks. It will also likely have 
> > > some useful static analysis results in the Windows-specific 
> > > portions of the code that we should evaluate.
> > >  
> > > Thanks,
> > >  
> > > -Brent
> > > ___
> > > 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
>  
> ___
> 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] WebCore/platform standalone library

[Carlos Garcia Campos]

El mié, 18-03-2015 a las 21:43 -0700, Myles C. Maxfield escribió:
> Hello, all,
> 
> I’d like to announce that I intend to create a standalone static library from 
> the current contents of WebCore/platform over the coming months. This will 
> involve creating a “Platform" top-level directory and moving source files 
> into it, one by one. 

Yes!

> There are a few reasons for this:
> 
> 1. Enforcing the layering between Platform and WebCore. Moving Platform into 
> its own target/directory can guarantee that nothing inside it knows about 
> anything in WebCore.
> 2. Being able to test code in the Platform directory with TestWebKitAPI 
> (without exporting Platform symbols from the WebCore library)
> 3. Managing conceptual complexity.
> 
> Does anyone have any thoughts or feedback?

This has always been blocked by the existing layering violations, what
are your plans for that? I guess we will have WebCore/platform and
Platform at the same time for a while until all layering violations are
fixed?

See the tracking bug:
https://bugs.webkit.org/show_bug.cgi?id=21354

But there are more, I wrote a script to get the list of violations, it's
in Tools/Scripts/check-for-platform-layering-violations

> Thanks,
> Myles
> ___
> 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] NEON_INTRINSICS

[Carlos Garcia Campos]

El lun, 09-03-2015 a las 14:48 -0700, Maciej Stachowiak escribió:
> Is anyone actually shipping it or planning to ship it? I don’t have a problem 
> with it if it’s being used, but from the thread it didn’t sound like anyone 
> was actually using it.

Or people were using it in their forks and never contributed the build
fix back upstream :-/

>  - Maciej
> 
> > On Mar 9, 2015, at 1:51 PM, Benjamin Poulain  wrote:
> > 
> > This is quite different from legacy features we remove all the time. This 
> > simple valuable code that happen to be untested because of the lack of 
> > ARMv7 infrastructure on the public bots.
> > 
> > Regarding maintenance, I'd be happy to fix bugs in that code.
> > 
> > Benjamin
> > 
> > On 3/9/15 11:34 AM, Maciej Stachowiak wrote:
> >> Requiring a perf bot to be set up before removing unmaintained code
> >> seems like a really high bar. What would it take to do a one-shot
> >> test of whether NEON_INTRINSICS is a perf benefit? Would it show up
> >> on PLT or on JS perf benchmarks if you compiled with it? If it’s not
> >> a speedup in its existing form, then it’s probably not worth keeping
> >> around. If it is, then that might be incentive for someone to get it
> >> production-ready and on by default for relevant platforms.
> >> 
> >> Regards, Maciej
> >> 
> >>> On Mar 8, 2015, at 6:56 PM, Benjamin Poulain 
> >>> wrote:
> >>> 
> >>> That code looks straightforward, the maintenance cost is likely
> >>> low. We just really need a test bot to run that code.
> >>> 
> >>> I suggest we wait until we have a ARMv7 perf bot and re-evaluate
> >>> NEON_INTRINSICS.
> >>> 
> >>> On 05/03/2015 22:27, Carlos Garcia Campos wrote:
> >>>> Yesterday a patch was submitted to fix the build with
> >>>> NEON_INTRINSICS, and Ossy pointed out that the build has been
> >>>> broken since r170433, and nobody has noticed it until now. So
> >>>> that makes me wonder if anybody is actually using that and if it
> >>>> even works, because otherwise we should probably remove the
> >>>> NEON_INTRINSICS code.
> >>>> 
> >>>> So, is there anybody actually using that (I guess patched
> >>>> downstream)?
> >>>> 
> >>>> 
> >>>> ___ 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


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

[webkit-dev] NEON_INTRINSICS

[Carlos Garcia Campos]

Yesterday a patch was submitted to fix the build with NEON_INTRINSICS,
and Ossy pointed out that the build has been broken since r170433, and
nobody has noticed it until now. So that makes me wonder if anybody is
actually using that and if it even works, because otherwise we should
probably remove the NEON_INTRINSICS code. 

So, is there anybody actually using that (I guess patched downstream)?


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

Re: [webkit-dev] WebKit not rendering images of a local resource (from within Gedit)

[Carlos Garcia Campos]

El lun, 19-01-2015 a las 18:58 +0100, Peter Bittner escribió:
> Hi,
> 
> I'm using WebKit to render HTML in a plugin of Gedit, the Gnome text
> editor. The source code is available from
> https://github.com/bittner/gedit-reST-plugin/blob/gedit-3.14/reST/restructuredtext.py#L56

This is the list for WebKit development, you can use
webkit-...@lists.webkit.org for questions about WebKitGTK+.

> Now it looks like WebKit is rendering images from remote resources
> (e.g. http://farm3.static.flickr.com/2256/2259897373_d47ecf0983_o_d.png)
> fine, but local images (e.g. docs/reStPlugin.png) just display as an
> empty box. Interestingly, the size of the box corresponds to the real
> size of the image, but the image itself is not displayed.

Sounds like local images fail to load, probably because they aren't
found (I guess you are not passing the right base URL to the load
method). I don't know much about the python bindings, and it seems you
are using the deprecated WebKit1 API.

> Some details and a screenshot are available from a bug report at
> https://github.com/bittner/gedit-reST-plugin/issues/7
> 
> Does this problem sound familiar to someone?
> 
> Thanks in advance for any hints,
> Peter
> ___
> 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] Žan Doberšek is now WebKit reviewer

[Carlos Garcia Campos]

I'm happy to announce that Žan Doberšek is now a WebKit reviewer.

Žan has contributed to WebKit for more than 6 years working on almost
all areas of WebKit. Mainly focused on the GTk+ port he has also helped
a lot improving the whole codebase, fixing bugs,
cleaning up code, modernizing code using new C++ 11 features, etc. He is
currently leading the new WebKit for Wayland port.

Thank you Žan for all the work you have done so far for WebKit.

Congratulations!

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

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

[Carlos Garcia Campos]

El mié, 19-11-2014 a las 12:20 -0800, Chris Dumez escribió:
> Hi all,
> 
> I recently started updating the WTF::Vector API to use unsigned types
> instead of size_t [1][2], because:
> - WTF::Vector is already using unsigned type for size/capacity
> internally to save memory on 64-bit, causing a mismatch between the
> API and the internal representation [3]
> - Some reviewers have asked me to use unsigned for loop counters
> iterating over vectors (which looks unsafe as the Vector API, e.g.
> size(), returns a size_t).
> - I heard from Joseph that this type mismatch is forcing us (and other
> projects using WTF) to disable some build time warnings
> - The few people I talked to before making that change said we should
> do it

I started this [1] some time ago, copy pasting what Darin told me in a
review. Whatever we decide could be documented there.

> However, Alexey recently raised concerns about this change. it doesn't
> "strike him as the right direction. 4Gb is not much, and we should
> have more of WebKit work with the right data types, not less.”.
> I did not initially realize that this change was controversial, but
> now that it seems it is, I thought I would raise the question on
> webkit-dev to see what people think about this.
> 
> Kr,
> --
> Chris Dumez - Apple Inc.
> Cupertino, CA
> 
> 
> 
> [1] http://trac.webkit.org/changeset/176275
> [2] http://trac.webkit.org/changeset/176293
> [3] http://trac.webkit.org/changeset/148891

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



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

Re: [webkit-dev] GTK EWS bot failing to build (gtkdoc-mkdb can’t find WebKitDOMCustomUnstable.h)

[Carlos Garcia Campos]

El dom, 09-11-2014 a las 11:30 +0100, Carlos Garcia Campos escribió:
> El dom, 09-11-2014 a las 11:07 +0100, Carlos Garcia Campos escribió:
> > El sáb, 08-11-2014 a las 16:27 -0800, Darin Adler escribió:
> > > Hi folks.
> > > 
> > > The GTK EWS bot is failing to build, with this error:
> > > 
> > > > Can't open 
> > > > /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/webkitdom/WebKitDOMCustomUnstable.h:
> > > >  No such file or directory at 
> > > > /home/rego/checkout/WebKit/WebKitBuild/DependenciesGTK/Root/bin/gtkdoc-mkdb
> > > >  line 3889.
> > > > 
> > > > Generating webkitdomgtk documentation...
> > > > Traceback (most recent call last):
> > > >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 
> > > > 201, in 
> > > > 
> > > > generate_documentation_for_config(common.build_path('gtkdoc-webkitdom.cfg'))
> > > >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 
> > > > 152, in generate_documentation_for_config
> > > > return generate_doc(generator, arguments.skip_html)
> > > >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 
> > > > 133, in generate_doc
> > > > generator.generate(not skip_html)
> > > >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 145, in 
> > > > generate
> > > > self._run_gtkdoc_mkdb()
> > > >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 361, in 
> > > > _run_gtkdoc_mkdb
> > > > self._run_command(args, cwd=self.output_dir)
> > > >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 210, in 
> > > > _run_command
> > > > % (args[0], process.returncode))
> > > 
> > > Is there someone who knows how to fix this?
> > 
> > hmm, a clean build should fix that, I'd say.
> 
> However, that should never happen, unstable headers shouldn't be scanned
> by gtk-doc, so this is revealing a bug in our generate-gtkdoc script.

https://bugs.webkit.org/show_bug.cgi?id=138542

> > > — 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 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] GTK EWS bot failing to build (gtkdoc-mkdb can’t find WebKitDOMCustomUnstable.h)

[Carlos Garcia Campos]

El dom, 09-11-2014 a las 11:07 +0100, Carlos Garcia Campos escribió:
> El sáb, 08-11-2014 a las 16:27 -0800, Darin Adler escribió:
> > Hi folks.
> > 
> > The GTK EWS bot is failing to build, with this error:
> > 
> > > Can't open 
> > > /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/webkitdom/WebKitDOMCustomUnstable.h:
> > >  No such file or directory at 
> > > /home/rego/checkout/WebKit/WebKitBuild/DependenciesGTK/Root/bin/gtkdoc-mkdb
> > >  line 3889.
> > > 
> > > Generating webkitdomgtk documentation...
> > > Traceback (most recent call last):
> > >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 201, 
> > > in 
> > > 
> > > generate_documentation_for_config(common.build_path('gtkdoc-webkitdom.cfg'))
> > >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 152, 
> > > in generate_documentation_for_config
> > > return generate_doc(generator, arguments.skip_html)
> > >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 133, 
> > > in generate_doc
> > > generator.generate(not skip_html)
> > >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 145, in 
> > > generate
> > > self._run_gtkdoc_mkdb()
> > >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 361, in 
> > > _run_gtkdoc_mkdb
> > > self._run_command(args, cwd=self.output_dir)
> > >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 210, in 
> > > _run_command
> > > % (args[0], process.returncode))
> > 
> > Is there someone who knows how to fix this?
> 
> hmm, a clean build should fix that, I'd say.

However, that should never happen, unstable headers shouldn't be scanned
by gtk-doc, so this is revealing a bug in our generate-gtkdoc script.

> > — 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] GTK EWS bot failing to build (gtkdoc-mkdb can’t find WebKitDOMCustomUnstable.h)

[Carlos Garcia Campos]

El sáb, 08-11-2014 a las 16:27 -0800, Darin Adler escribió:
> Hi folks.
> 
> The GTK EWS bot is failing to build, with this error:
> 
> > Can't open 
> > /home/rego/checkout/WebKit/WebKitBuild/Release/DerivedSources/webkitdom/WebKitDOMCustomUnstable.h:
> >  No such file or directory at 
> > /home/rego/checkout/WebKit/WebKitBuild/DependenciesGTK/Root/bin/gtkdoc-mkdb 
> > line 3889.
> > 
> > Generating webkitdomgtk documentation...
> > Traceback (most recent call last):
> >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 201, in 
> > 
> > 
> > generate_documentation_for_config(common.build_path('gtkdoc-webkitdom.cfg'))
> >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 152, in 
> > generate_documentation_for_config
> > return generate_doc(generator, arguments.skip_html)
> >   File "/home/rego/checkout/WebKit/Tools/gtk/generate-gtkdoc", line 133, in 
> > generate_doc
> > generator.generate(not skip_html)
> >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 145, in 
> > generate
> > self._run_gtkdoc_mkdb()
> >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 361, in 
> > _run_gtkdoc_mkdb
> > self._run_command(args, cwd=self.output_dir)
> >   File "/home/rego/checkout/WebKit/Tools/gtk/gtkdoc.py", line 210, in 
> > _run_command
> > % (args[0], process.returncode))
> 
> Is there someone who knows how to fix this?

hmm, a clean build should fix that, I'd say.

> — 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

Re: [webkit-dev] Disk cache

[Carlos Garcia Campos]

El lun, 03-11-2014 a las 00:22 -0800, Benjamin Poulain escribió:
> On 11/2/14, 1:11 AM, Carlos Garcia Campos wrote:
> > El sáb, 01-11-2014 a las 20:43 +0200, Antti Koivisto escribió:
> >> On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos
> >>  wrote:
> >>  El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió:
> >>  > Hello,
> >>  >
> >>  >
> >>  > I'm planning to add an experimental HTTP cache
> >>  implementation to
> >>  > WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322).
> >>  
> >>  Great news!
> >>  
> >>  >  The main motivations are:
> >>  >
> >>  >
> >>  > - Improving performance by bringing the cache closer. For
> >>  example we
> >>  > can serialize WebKit response objects directly instead of
> >>  converting
> >>  > to/from platform types.
> >>  > - Making future innovation around caching easier. Closer
> >>  coordination
> >>  > between cache and WebKit opens new optimization
> >>  possibilities.
> >>  >
> >>  >
> >>  > The cache lives in the network process. Most of the code is
> >>  > cross-platform. The storage backend uses libdispatch IO
> >>  though it
> >>  > wouldn't be hard to add a generic posix one too.
> >>  
> >>  Why is it limited to the network process? wouldn't it be
> >>  possible to use
> >>  it also in the web process when shared secondary process model
> >>  is used?
> >>
> >>
> >> The cache ties to NetworkResourceLoader which lives in the network
> >> process. In principle it would be possible to integrate with the web
> >> process side resource loader too. However I don't want to support
> >> multiple configurations during development.
> >>
> >>
> >> It would be good if all WK2 ports would eventually switch to using the
> >> network process. The current multitude of configurations makes
> >> networking related code more confusing and less hackable than it needs
> >> to be.
> > The GTK+ port supports the network process, but it's only used when
> > multiple secondary process model is used. Some applications prefer the
> > single shared secondary process model, and even some of the browser
> > users change the default process model of epiphany to single web process
> > because it requires fewer resources. So, we could either integrate the
> > cache with the web process loader, or use the network process
> > unconditionally for all process models. I think for many simple
> > applications a single web process is the most efficient model, though.
> 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.
> 
> You say a single Web Process is the most efficient model for some 
> applications. What is the impact of always enabling the network process on:
> -CPU load?
> -Memory load?
> -Overall performance?

I haven't measured, I was thinking mainly on the overhead of the IPC
traffic required for the network resources.

> Once we know where the problems are, we should work together at reducing 
> the impact. I suspect we can get the network process below 5% overhead.
> 
> Benjamin
> ___
> 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] Disk cache

[Carlos Garcia Campos]

El sáb, 01-11-2014 a las 20:43 +0200, Antti Koivisto escribió:
> On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos
>  wrote:
> El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió:
> > Hello,
> >
> >
> > I'm planning to add an experimental HTTP cache
> implementation to
> > WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322).
> 
> Great news!
> 
> >  The main motivations are:
> >
> >
> > - Improving performance by bringing the cache closer. For
> example we
> > can serialize WebKit response objects directly instead of
> converting
> > to/from platform types.
> > - Making future innovation around caching easier. Closer
> coordination
> > between cache and WebKit opens new optimization
> possibilities.
> >
> >
> > The cache lives in the network process. Most of the code is
> > cross-platform. The storage backend uses libdispatch IO
> though it
> > wouldn't be hard to add a generic posix one too.
> 
> Why is it limited to the network process? wouldn't it be
> possible to use
> it also in the web process when shared secondary process model
> is used?
> 
> 
> The cache ties to NetworkResourceLoader which lives in the network
> process. In principle it would be possible to integrate with the web
> process side resource loader too. However I don't want to support
> multiple configurations during development.
>
> 
> It would be good if all WK2 ports would eventually switch to using the
> network process. The current multitude of configurations makes
> networking related code more confusing and less hackable than it needs
> to be.

The GTK+ port supports the network process, but it's only used when
multiple secondary process model is used. Some applications prefer the
single shared secondary process model, and even some of the browser
users change the default process model of epiphany to single web process
because it requires fewer resources. So, we could either integrate the
cache with the web process loader, or use the network process
unconditionally for all process models. I think for many simple
applications a single web process is the most efficient model, though.

> 
> 
> 
>antti
>  
> 
> >
> > The code will be behind NETWORK_CACHE feature flag.
> >
> >
> >
> >
> >   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
> 
> 
> 


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

Re: [webkit-dev] Disk cache

[Carlos Garcia Campos]

El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió:
> Hello,
> 
> 
> I'm planning to add an experimental HTTP cache implementation to
> WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322).

Great news!

>  The main motivations are:
> 
> 
> - Improving performance by bringing the cache closer. For example we
> can serialize WebKit response objects directly instead of converting
> to/from platform types.
> - Making future innovation around caching easier. Closer coordination
> between cache and WebKit opens new optimization possibilities.
> 
> 
> The cache lives in the network process. Most of the code is
> cross-platform. The storage backend uses libdispatch IO though it
> wouldn't be hard to add a generic posix one too.

Why is it limited to the network process? wouldn't it be possible to use
it also in the web process when shared secondary process model is used?

> 
> The code will be behind NETWORK_CACHE feature flag.
> 
> 
> 
> 
>   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] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

[Carlos Garcia Campos]

El vie, 17-10-2014 a las 12:42 +0200, Sergio Villar Senin escribió:
> On 17/10/14 06:28, Benjamin Poulain wrote:
> > It works great! Thanks for updating bugzilla, it is really neat.
> > 
> > Benjamin
> 
> Could the format of bz emails be changed? The new one with those huge
> tables on top and tiny fonts for the bug comments are pretty difficult
> to process.

I've always received bz emails in plain text, you can change that in
your prefs, I did it yesterday and now I'm receiving the same emails I
used to.

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


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

Re: [webkit-dev] Determining stable JavaScriptCore revision

[Carlos Garcia Campos]

El mar, 07-10-2014 a las 19:26 -0700, Gary Kratkin escribió:
> Hello, I’m using WebKitGtk 2.4.4. It branched from trunk at r163300 on
> Feb. 03, 2014. That may not have been a great moment for
> JavaScriptCore. The jsCStack branch had recently been merged,

That's not accurate due to the confusing svn. r163300 is the revision
where the "branch" was made (the copy), but the branch point was
r163026, right before the jsCStack merge in r163027. See
http://trac.webkit.org/changeset/163300/releases/WebKitGTK/webkit-2.4
and click on the "trunk" link.

>  and 2.4.4 has numerous JSC crashes, especially in DFG.
>  Disabling DFG is a reasonable short-term solution for my use case,
> but it leaves one crash I’m having trouble debugging. The release
> build crashes here:
> 
> 
> #0 0x7f1ffd385710 in JSC::JSCell::toBoolean(JSC::ExecState*) const
> () from libjavascriptcoregtk-1.0.so.0
> #1 0x7f1ffd3ac7f0 in ?? () from libjavascriptcoregtk-1.0.so.0
> #2 0x7f1ffd3b6de3 in ?? () from libjavascriptcoregtk-1.0.so.0
> #3 0x7f1ff7a5d018 in ?? ()
> #4 0x7f1ff7a5d000 in ?? ()
> #5 0x7f1fb40af970 in ?? ()
> #6 0x7f1f7dec6a28 in ?? ()
> #7 0x7f1fac4b0ff8 in ?? ()
> #8 0x7fffe0e09000 in ?? ()
> #9 0x7fffe0e08da0 in ?? ()
> #10 0x7f1ffd36bada in JSC::JITCode::execute(JSC::VM*,
> JSC::ProtoCallFrame*, JSC::Register*) () from
> libjavascriptcoregtk-1.0.so.0
> Backtrace stopped: previous frame inner to this frame (corrupt
> stack?) 
> 
> 
> The debug build asserts:
> 
> 
> #0  0x7f434f2e692f in WTFCrash ()
> at ../../Source/WTF/wtf/Assertions.cpp:333
> #1  0x7f434eefe7ba in JSC::validateCell
> (cell=0x3569a30)
> at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
> #2  0x7f434eefe39d in
> JSC::WriteBarrierBase::operator->
> (this=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
> #3  0x7f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
> #4  0x7f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90,
> exec=0x7f42fd3bb878)
> at ../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
> #5  0x7f434ef290b5 in JSC::JSValue::toBoolean
> (this=0x7fff20ff7410, exec=0x7f42fd3bb878)
> at ../../Source/JavaScriptCore/runtime/JSString.h:521
> #6  0x7f434f085a84 in JSC::operationConvertJSValueToBoolean
> (exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90)
> at ../../Source/JavaScriptCore/jit/JITOperations.cpp:861
> #7  0x7f43069fc99c in ?? ()
> #8  0x7f43069218e0 in ?? ()
> #9  0x0274c130 in ?? ()
> #10 0x0301f740 in ?? ()
> #11 0x031e5eb0 in ?? ()
> #12 0x03295eb8 in ?? ()
> #13 0x7f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling
> (object=0x7f43069218e0)
> at ../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
> #14 0x7fff20ff74c0 in ?? ()
> #15 0x7f434f06f74c in JSC::JITCode::execute
> (this=0xf0458b4832eb, vm=0xb8077500f07d,
> protoCallFrame=0x8348f0458948, topOfStack=0xdb6e8c7894860c0)
> at ../../Source/JavaScriptCore/jit/JITCode.cpp:48
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> 
> My question isn’t how to debug this, though any insights would be
> welcome. Instead I’m hoping to to roll JSC forward or backward to a
> more stable revision somewhere near 02/2014  (in order to reduce
> problems merging into WebKitGtk). It seems best to tie it to a
> contemporaneous Safari release, perhaps from the safari-600.1 branch.
> I’m wondering if that branch is considered always stable, and
> therefore safe to pull from at an arbitrary revision. Alternatively,
> is there a way to discover the revision for a given Safari release?
> 
> 
> Thanks for any help,
> Gary
> 
> 
> ___
> 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] New EWS status bubbles in Bugzilla

[Carlos Garcia Campos]

El lun, 29-09-2014 a las 23:51 -0700, Alexey Proskuryakov escribió:
> 29 сент. 2014 г., в 23:12, Carlos Garcia Campos  
> написал(а):
> 
> >> Please try it out, and let me know if something breaks, or is not as
> >> good as it could be!
> > 
> > Looks great! thanks. I've noticed that now we use red also for patches
> > that don't apply. I liked that there was a different color for that
> > case, since it's common when a patch depends on another one, and the
> > patch itself is not necessarily bad.
> 
> I agree that this is a non-obvious case. I chose red because EWS can't
> say anything good about the patch (or anything at all), so it needs
> extra careful attention from a reviewer.
> 
> Other options that I considered were:
> 
> - Keep it purple, as it was. I restricted purple to indicating
> internal errors, so it should pretty much never happen. Using the same
> color for the entirely different case of a patch that does not apply
> seems wrong.

Agree.

> - Make it white. That seems to make sense logically, but it has the
> same problem of using a single color for multiple purposes as red
> does. Also, I expect it to be surprising (I posted my patch several
> hours ago, why is it still white?)

Agree.

> - Add a new color. I'm not sure if this case is common enough for the
> color to become generally recognizable.

Well, I guess it's a matter of getting used to it :-)

> - Instead of per-queue bubbles, show text like "Patch does not apply
> to trunk". Not workable, because queues start at different times, and
> only some of them could fail to apply the patch.

Right.

> Perhaps most importantly, this case is really no different from
> failing to build due to a dependency on another patch, or to failing
> some tests for the same reason. So I don't think that we can represent
> dependency on another patch with color.

Fair enough, I haven't thought about those cases, I agree it's indeed
the same case and we will see red bubbles. Ideally, the EWS might apply
the patches following the dependency chain, but I guess that's not easy
to do.

> Thinking about this now, we could replace bubbles with text when no
> queue has results (i.e. at least one queue has failed to apply, and
> those that didn't still haven't started processing - we can reasonably
> expect that they will fail, too, and even if they apply cleanly, we
> can just revert to showing bubbles then). I can't think of any
> situation where this would be misleading or difficult to comprehend.
> Would this resolve your concern? Would you be willing to post a patch
> implementing this?

Well, I was just surprised to see the bubbles red because I was used to
seeing them purple, but I agree the case it's not different to when a
patch fails to build because of a dependency. So, I'll get used to the
red :-)

> - Alexey
> 
> 


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

Re: [webkit-dev] New EWS status bubbles in Bugzilla

[Carlos Garcia Campos]

El lun, 29-09-2014 a las 15:05 -0700, Alexey Proskuryakov escribió:
> Hi,
> 
> 
> WebKit Bugzilla has new EWS status bubbles now, which will hopefully
> make it more clear what's going on with a patch. Mysterious yellow
> bubbles that could mean anything were eliminated, and most
> importantly, there is now detailed information presented on hover:

> Please try it out, and let me know if something breaks, or is not as
> good as it could be!

Looks great! thanks. I've noticed that now we use red also for patches
that don't apply. I liked that there was a different color for that
case, since it's common when a patch depends on another one, and the
patch itself is not necessarily bad.

> 
> - Alexey
> 
> 
> ___
> 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’s the status of the GObject bindings?

[Carlos Garcia Campos]

El sáb, 19-07-2014 a las 23:08 -0700, Darin Adler escribió:
> Which port exposes the GObject bindings? I had the impression that the GTK 
> port was dropping WebKit1. Are the GObject bindings used with WebKit2?

Yes, GObject DOM bindings are now used in WebKit2 GTK+ using web
extensions (injected bundle) API.

> — 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

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

[Carlos Garcia Campos]

El mar, 28-01-2014 a las 14:32 -0800, Anders Carlsson escribió:
> 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);

Yes, we preferred that way to keep the code simpler and avoid long
switches.

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

That's right, it's also true that most of the times enums are extended
adding new entries at the end.

> 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.

Ok, let's fix this sooner rather than later, then.

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

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3


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

Re: [webkit-dev] Guideline for nullptr

[Carlos Garcia Campos]

El lun, 06-01-2014 a las 14:19 -0800, Martin Robinson escribió:
> On Mon, Jan 6, 2014 at 1:16 PM, Ryosuke Niwa  wrote:
> > Sounds like a great idea to me.
> 
> Seconding this. nullptr also has much better compatibility with varargs than 
> 0.

Yeah, with nullptr we don't need the coding style exceptions for C API
using NULL as a sentinel.



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

Re: [webkit-dev] ChangeLog format

[Carlos Garcia Campos]

El jue, 22-08-2013 a las 00:41 -0700, Mark Rowe escribió:
> On 2013-08-21, at 11:11 PM, Carlos Garcia Campos  wrote:
> 
> > I see, I thought ChangeLog parser was used everywhere. So, I guess the
> > solution would be to find a format most people like and adapt all
> > scripts to it. I personally think it's not worth it, though. The oneline
> > git log format is ok with the old commit message format IMO. If the only
> > problem is that the bug number is not in the first line we can probably
> > add it without adding the URL in angle brackets, something like:
> > 
> > Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
> > https://bugs.webkit.org/show_bug.cgi?id=119872
> 
> What benefit does duplicating the bug number in the first line provide? It’s 
> just yet another thing to have to add when writing the ChangeLog entry.

The benefit is that you see the bug number when using git log oneline
format, I'm guessing that seeing the bug number in the first line was
the motivation of the new ChangeLog format.

> - Mark
> 
> 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

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

Re: [webkit-dev] ChangeLog format

[Carlos Garcia Campos]

El mié, 21-08-2013 a las 23:01 -0700, Ryosuke Niwa escribió:
> On Wed, Aug 21, 2013 at 10:54 PM, Ryosuke Niwa 
> wrote:
> On Wed, Aug 21, 2013 at 10:50 PM, Carlos Garcia Campos
>  wrote:
> 
> El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa
> escribió:
> > Hi,
> 
> [...]
> >
> > Separately, I'd like to know whether people liked
> the new format and
> > it's worth my time making webkitpy adopt the new
> format.
> 
> 
> I prefer the old format.
> 
> >
> > I personally didn't like the old format because it
> made the first line
> > of each change log too long.  I'm also not a big fun
> of wrapping URLs
> > in angle brackets.  It's also unclear to me what
> should happen when
> > there are multiple Bugzilla URLs to list.
> >
> >
> > But I hear the new format made git log --oneline
> much more readable so
> > I can be convinced although I don't intend to use
> git for WebKit
> > development in the foreseeable future myself.
> 
> 
> Well, git log is not actually affected by the
> ChangeLog format, but by
> the commit message. I mean, we generate the commit
> message from the
> ChangeLog, so we can keep the old format in the
> ChangeLog and update the
> script to generate the commit message to make it
> better for oneline git
> log format. webkitpy parses the ChangeLog not the
> commit message, so
> everything should work.
> 
> 
> If I'm not mistaken, I think a bunch of tools DO analyze git
> logs to do the work; commit-queue, webkitbot, etc...
> 
> 
> e.g. MarkBugFixed._determine_bug_id_and_svn_revision
> uses tool.scm().svn_commit_log to figure out the bug number.  In fact,
> the code assumes that the commit log uses the same format as the
> change log and uses changelog.py's parse_bug_id_from_changelog
> 
> 
> In fact, making change log & commit log use a different format is much
> more challenging than changing the format of change log & commit log.
>  It requires A LOT of refactoring and bug fixes in webkitpy.  I don't
> even know much work is required for webkitperl and other tools.

I see, I thought ChangeLog parser was used everywhere. So, I guess the
solution would be to find a format most people like and adapt all
scripts to it. I personally think it's not worth it, though. The oneline
git log format is ok with the old commit message format IMO. If the only
problem is that the bug number is not in the first line we can probably
add it without adding the URL in angle brackets, something like:

Bug 119872 - REGRESSION: Crash under JITCompiler::link while loading Gmail
https://bugs.webkit.org/show_bug.cgi?id=119872

> 
> - R. Niwa
> 
> 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

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

Re: [webkit-dev] ChangeLog format

[Carlos Garcia Campos]

El mié, 21-08-2013 a las 14:04 -0700, Ryosuke Niwa escribió:
> Hi,

[...]
> 
> Separately, I'd like to know whether people liked the new format and
> it's worth my time making webkitpy adopt the new format.

I prefer the old format.

> 
> I personally didn't like the old format because it made the first line
> of each change log too long.  I'm also not a big fun of wrapping URLs
> in angle brackets.  It's also unclear to me what should happen when
> there are multiple Bugzilla URLs to list.
> 
> 
> But I hear the new format made git log --oneline much more readable so
> I can be convinced although I don't intend to use git for WebKit
> development in the foreseeable future myself.

Well, git log is not actually affected by the ChangeLog format, but by
the commit message. I mean, we generate the commit message from the
ChangeLog, so we can keep the old format in the ChangeLog and update the
script to generate the commit message to make it better for oneline git
log format. webkitpy parses the ChangeLog not the commit message, so
everything should work.

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

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

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

Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?

[Carlos Garcia Campos]

El mar, 20-08-2013 a las 23:41 -0700, Ryosuke Niwa escribió:
> Does that mean we want the new Mac behavior
> (i.e. shouldShowPlaceholderWhenFocused returning true) everywhere?

I think so unless any GTK+ port maintainer disagree, but consistency
with the platform is important too, so I'll first check with GNOME
designers if they are ok with changing that in GTK+.

> Ryosuke Niwa
> 
> 
> 
> 
> On Tue, Aug 20, 2013 at 11:35 PM, Kangil Han 
> wrote:
> +1
> 
> -Original Message-
> From: webkit-dev-boun...@lists.webkit.org
> [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of
> Carlos Garcia Campos
> Sent: Wednesday, August 21, 2013 3:08 PM
> To: Martin Robinson
> Cc: WebKit Development
> Subject: Re: [webkit-dev] Are Qt and GTK+ intentionally
> returning false in shouldShowPlaceholderWhenFocused?
> 
> El mar, 20-08-2013 a las 10:41 -0700, Martin Robinson
> escribió:
> > On Mon, Aug 19, 2013 at 10:16 PM, Ryosuke Niwa
>  wrote:
> > > Are Qt and GTK+ (and other) ports intentionally returning
> false in
> > > shouldShowPlaceholderWhenFocused?  Or is this just an
> oversight due
> > > to the fact the default implementation returned false?
> >
> > I just confirmed that the native GTK+ behavior is for
> placeholder text
> > to disappear when a text entry is focused. I believe for GTK
> + this
> > method should return false.
> 
> I think that removing the placeholder text when starting
> typing instead of when the entry is focused is indeed a good
> idea. I implemented the placeholder text in GTK+ following the
> WebKit approach, so maybe we can change it in both places.
> 
> > --Martin
> > ___
>     > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> 
> --
> Carlos Garcia Campos
> 
> http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
> 
> ___
> 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
> 
> 
> 

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

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

Re: [webkit-dev] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?

[Carlos Garcia Campos]

El mar, 20-08-2013 a las 10:41 -0700, Martin Robinson escribió:
> On Mon, Aug 19, 2013 at 10:16 PM, Ryosuke Niwa  wrote:
> > Are Qt and GTK+ (and other) ports intentionally returning false in
> > shouldShowPlaceholderWhenFocused?  Or is this just an oversight due to the
> > fact the default implementation returned false?
> 
> I just confirmed that the native GTK+ behavior is for placeholder text
> to disappear when a text entry is focused. I believe for GTK+ this
> method should return false.

I think that removing the placeholder text when starting typing instead
of when the entry is focused is indeed a good idea. I implemented the
placeholder text in GTK+ following the WebKit approach, so maybe we can
change it in both places.

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

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

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

Re: [webkit-dev] Adding ENABLE_CSS_DIRECTIONAL_FOCUS to WebCore.

[Carlos Garcia Campos]

El vie, 26-07-2013 a las 20:07 -0700, Benjamin Poulain escribió:
> On Fri, Jul 26, 2013 at 1:57 AM, Mario Sanchez Prada <
> mario.pr...@samsung.com> wrote:
> 
> > > Ah, When I made a new patch, had doubts about the file name "Deprecated".
> > > So, I have to wait the "StyleBuilder" Class to have a clear form.
> >
> > On this regard, some input from Dirk Schulze could probably be very useful
> > as guidance here, as he was the original author of the commit where this
> > class got deprecated[1].
> >
> 
> It is a work in progress to clean the StyleBuilder.
> 
> 
> > > Also, I'm waiting for the community to conclude this discussion.
> >
> > Me too.
> >
> 
> Honestly, I am concerned that no one in favor of this feature is a regular
> contributor.

Mario has volunteered to maintain this feature, or do you really mean
Mario is not a regular contributor?

> The feature does not seem very invasive so if some people really invest
> time in maturing this, it could be worth experimenting with this and
> provide feedback to the W3C working group.
> I think everything should be behind a feature flag, and have the -webkit-
> prefix. As usual with experimental features, you will have to remove it if
> it turns out the experiment is not successful.
> 
> Benjamin
> On Fri, Jul 26, 2013 at 1:57 AM, Mario Sanchez Prada
>  wrote:
> > Ah, When I made a new patch, had doubts about the file name
> "Deprecated".
> > So, I have to wait the "StyleBuilder" Class to have a clear
> form.
> 
> 
> On this regard, some input from Dirk Schulze could probably be
> very useful
> as guidance here, as he was the original author of the commit
> where this
> class got deprecated[1].
> 
> 
> It is a work in progress to clean the StyleBuilder.
>  
> > Also, I'm waiting for the community to conclude this
> discussion.
> 
> 
> Me too.
> 
> 
> Honestly, I am concerned that no one in favor of this feature is a
> regular contributor.
> 
> 
> The feature does not seem very invasive so if some people really
> invest time in maturing this, it could be worth experimenting with
> this and provide feedback to the W3C working group.
> I think everything should be behind a feature flag, and have the
> -webkit- prefix. As usual with experimental features, you will have to
> remove it if it turns out the experiment is not successful.
> 
> 
> Benjamin
> ___
> 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] WebKit2 and ENABLE_PLUGIN_PROCESS

[Carlos Garcia Campos]

El lun, 20-05-2013 a las 15:15 -0700, Anders Carlsson escribió:
> 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.

I think we removed the compile option in GTK port already.

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


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

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

[Carlos Garcia Campos]

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 :-)

> 
> BR,
> /Arvid
> 
> 
> Sent from my BlackBerry 10 smartphone.
> From: Anders Carlsson
> Sent: Sunday, May 19, 2013 8:36 PM
> To: WebKit Development
> Subject: [webkit-dev] ENABLE(PAGE_POPUP) in WebCore
> 
> 
> Hi everyone,
> 
> I was looking at the PagePopup code and it seems to be BlackBerry
> specific. Furthermore, it seems to only be called from inside
> BlackBerry WebKit.
> 
> Would it be possible to just move the code into WebKit/blackberry
> instead? I think someone with access to a BlackBerry build environment
> could do it in ~30 minutes or so. 
> 
> Thanks,
> - Anders
> 
> ___
> 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] Clipboard class plans

[Carlos Garcia Campos]

El mié, 15-05-2013 a las 10:32 -0700, Darin Adler escribió:
> On Feb 6, 2013, at 9:13 AM, Darin Adler  wrote:
> 
> > The major step is to refactor so that Pasteboard is the platform 
> > abstraction and Clipboard is a pure DOM class built on top of Pasteboard. 
> > To do a good job on that I will probably need help from people willing to 
> > tackle platforms other than Mac. I’ve started by doing the refactoring on 
> > Mac and putting an #ifdef in place for scaffolding.
> 
> This is mostly done for Mac now. See 
>  for details.
> 
> So the basic pattern is in place and we just have to fill in the details for 
> other platforms.
> 
> For the other platforms I might make an initial pass, but I will need a 
> platform expert to help get it to 100%. The platforms are Blackberry, EFL, 
> GTK, Qt, and Win (and iOS, but we’ll have to handle that differently since 
> it’s not fully upstreamed at this time).

I can help with he GTK port, I've already opened a new bug :

https://bugs.webkit.org/show_bug.cgi?id=116221

Do you also plan to fix the layering violations in Pasteboard?

> -- 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

Re: [webkit-dev] Crash in JSC while loading gap.com on 1.6.3

[Carlos Garcia Campos]

El mar, 30-04-2013 a las 09:11 +0200, Allan Sandfeld Jensen escribió:
> He probably refers to 1.6.3 of WebKitGTK+, the confusion comes from the fact 
> that WebKitGTK+ calls themselves and their library 'WebKit' on Linux with no 
> attempt of disambiguation.

right :-( but we fixed that already, our libs are now libwebkitgtk,
libwebkit2gtk and libjavascriptcoregtk

> He needs to update though. I think they are at 1.11 and 2.0 now.

Right.

> `Allan
> 
> On Tuesday 30 April 2013, Filip Pizlo wrote:
> > Three suggestions:
> > 
> > 1) If you find a bug in some part of WebKit (JSC or elsewhere), you should
> > file it on bugs.webkit.org.  webkit-dev isn't really the right venue for
> > bug reports.
> > 
> > 2) You should be more specific - in the bug report that you will file and
> > not in this thread - about what port you're using.  Version "1.6.3" is
> > ambiguous, to me.  There are a number of ports that support ARM, and it's
> > not clear to me which you're using.  Hence, I don't even know how old
> > "1.6.3" is, because I'm not familiar with the versioning that the
> > different ports do.
> > 
> > 3) Your best bet is probably to update to a newer version, and see if the
> > bug reproduces.
> > 
> > -Filip
> > 
> > On Apr 29, 2013, at 10:15 PM, developer World  
> wrote:
> > > Hi,
> > > 
> > >   I am using the 1.6.3 release (an old one) for my development and get a
> > >   crash while loading gap.com and youtube.com/tv.(Both related to JS
> > >   function apply having an incredibly large number of arguments)
> > > 
> > > My processor is ARM 11 based and the smaps of the crash point me to the
> > > location where the JIT has dumped the bytecode for excuting various JS
> > > functionality.
> > > 
> > > From the looks of it, the issue I face is very similar to this one
> > > https://bugs.webkit.org/show_bug.cgi?id=108991 however, since I am on an
> > > old version it is difficult for me to fix it in my JSC. Can anyone help
> > > me out over here as to where should I patch my JSC source code
> > > 
> > > Thanks
> > > ___
> > > webkit-dev mailing list
> > > webkit-dev@lists.webkit.org
> > > https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 


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

Re: [webkit-dev] C++11 (was Re: on coding-style)

[Carlos Garcia Campos]

El vie, 12-04-2013 a las 18:15 -0700, Maciej Stachowiak escribió:
> On Apr 12, 2013, at 4:09 PM, Karen Shaeffer  wrote:
> 
> > 
> > Of course, I understand that. But there is a huge opportunity cost to 
> > webkit.
> > The c++11 standard also rewrites the entire standard library. I have been 
> > using
> > g++ 4.7.2 using -stdc++11 in my work with linux. And the code I have tested 
> > is
> > performing nearly like c code. If you take advantage of the performance 
> > enhancements
> > in C++11, then you can realize impressive performance gains.
> > 
> > I do understand the nature of the business. And I also understand that 
> > performance
> > is huge moving forward, where resource constrained mobile platforms are 
> > significantly
> > affected by performance issues. I suggest you'll see Blink moving 
> > aggressively to
> > support C++11 moving forward. And I suggest it is in WebKit's long term 
> > interest to
> > do so as well.
> 
> As others have said, we are definitely eager to use C++11 across the board 
> but are limited by compiler support requirements.
> 
> One thing that it would be useful to know: what are the compilers and minimum 
> required versions used for in-tree ports? Perhaps we could record this so we 
> can regularly evaluate which features are safe to use and what the blockers 
> are to wholesale adoption, if any.

The GTK+ port now requires gcc >= 4.7 and clang >= 3. We also added the
-stdc++11 where possible. See
https://bugs.webkit.org/show_bug.cgi?id=109932

> Regards,
> Maciej
> 
> 
> 
> 
> 
> 
> On Apr 12, 2013, at 4:09 PM, Karen Shaeffer 
> wrote:
> 
> > 
> > Of course, I understand that. But there is a huge opportunity cost
> > to webkit.
> > The c++11 standard also rewrites the entire standard library. I have
> > been using
> > g++ 4.7.2 using -stdc++11 in my work with linux. And the code I have
> > tested is
> > performing nearly like c code. If you take advantage of the
> > performance enhancements
> > in C++11, then you can realize impressive performance gains.
> > 
> > I do understand the nature of the business. And I also understand
> > that performance
> > is huge moving forward, where resource constrained mobile platforms
> > are significantly
> > affected by performance issues. I suggest you'll see Blink moving
> > aggressively to
> > support C++11 moving forward. And I suggest it is in WebKit's long
> > term interest to
> > do so as well.
> > 
> 
> As others have said, we are definitely eager to use C++11 across the
> board but are limited by compiler support requirements.
> 
> 
> One thing that it would be useful to know: what are the compilers and
> minimum required versions used for in-tree ports? Perhaps we could
> record this so we can regularly evaluate which features are safe to
> use and what the blockers are to wholesale adoption, if any.
> 
> 
> Regards,
> Maciej
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3


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

Re: [webkit-dev] Changes to the WebKit2 development process

[Carlos Garcia Campos]

El mar, 29-01-2013 a las 09:39 +0100, Balazs Kelemen escribió:
> >
> > IMHO, recently, contributors as well as WK2 owners are a bit suffering 
> > from it. I think we can go to a better direction: making all 
> > developers happy as well as resolving WK2 owners' concerns.
> >
> 
> I think the straightforward way to achieve this is to let somebody be an 
> owner from every port. He/she should could be restricted to approve only 
> platform specific changes.

And why not making it even simpler an allow any reviewer to r+
port-specific patches? If the patch doesn't change any cross-platform
code at all there's no risk to break mac or any other port. 


Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

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

Re: [webkit-dev] WebKit2GTK+ breakage due to removal of WKPageResourceLoadClient

[Carlos Garcia Campos]

El lun, 21-01-2013 a las 17:57 -0800, Sam Weinig escribió:
> Hi Mario,
> 
> The motivation of the change was to reduce the chatter between the
> WebProcess and UIProcess and reduce the amount of knowledge the
> UIProcess has about the internals of the WebProcess.  We will also be
> removing the UIProcess' notion of the frame tree, for the same reason.

Now that you guys can break other ports at any time, would it be
possible that those changes are announced in advance here so that we
have some time to prepare for the change? I don't mean all changes that
might break the build and are easy to fix, but changes like that one
that break the C API, remove functionality, etc. that require a lot of
work adapting to them.

> Going forward, if you need that kind of detailed knowledge, you should
> use the WebInspector or the protocol it is based on.

The GTK+ API depends on the WebResource API, so WebInspector is not a
solution, 14 unit test are timing out now that resources don't work at
all. We'll rework it using injected bundle, but I'm afraid the injected
bundle API could be removed too, are there any plans in that regard or
can we safely use the injected bundle API?

> -Sam
> 
> On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada  
> wrote:
> 
> > Hi,
> >  
> > So it seems WebKit2GTK+ builds are broken since yesterday due to this 
> > commit (as it was already predicted by EWS in [1]):
> > http://trac.webkit.org/changeset/140285
> >  
> > ... and it seems to me it’s not something easily fixable since it will 
> > certainly require a certain amount of work (and maybe a certain amount of 
> > re-design too) to get it back, as the WebKitWebResource API (as well as 
> > certain parts in WebKitWebView API) did benefit of both 
> > WKResourceLoadClient and WebResourceLoadClient.
> >  
> > I’ve checked the related bug [1], but still haven’t been able to properly 
> > understand what’s exactly the reason of this change and, more importantly, 
> > what could be the best way to sort this out in the GTK port (an alternative 
> > implementation using the Injected Bundle perhaps?).
> >  
> > If anyone could drop some light on this issue or provide some pointers to 
> > better understand the motivation of this change, I’d really appreciate 
> > that. I understand rolling r140285 might be not the best option at this 
> > point, yet I’d personally rather not keep the WebKit2GTK+ broken for too 
> > long.
> >  
> > Thanks,
> > Mario
> >  
> > [1] https://bugs.webkit.org/show_bug.cgi?id=107405
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> Hi Mario,
> 
> 
> The motivation of the change was to reduce the chatter between the
> WebProcess and UIProcess and reduce the amount of knowledge the
> UIProcess has about the internals of the WebProcess.  We will also be
> removing the UIProcess' notion of the frame tree, for the same reason.
> 
> 
> Going forward, if you need that kind of detailed knowledge, you should
> use the WebInspector or the protocol it is based on.
> 
> 
> -Sam
> 
> On Jan 21, 2013, at 5:53 AM, Mario Sanchez Prada
>  wrote:
> 
> > Hi,
> >  
> > So it seems WebKit2GTK+ builds are broken since yesterday due to
> > this commit (as it was already predicted by EWS in [1]):
> > http://trac.webkit.org/changeset/140285
> >  
> > ... and it seems to me it’s not something easily fixable since it
> > will certainly require a certain amount of work (and maybe a certain
> > amount of re-design too) to get it back, as the WebKitWebResource
> > API (as well as certain parts in WebKitWebView API) did benefit of
> > both WKResourceLoadClient and WebResourceLoadClient.
> >  
> > I’ve checked the related bug [1], but still haven’t been able to
> > properly understand what’s exactly the reason of this change and,
> > more importantly, what could be the best way to sort this out in the
> > GTK port (an alternative implementation using the Injected Bundle
> > perhaps?).
> >  
> > If anyone could drop some light on this issue or provide some
> > pointers to better understand the motivation of this change, I’d
> > really appreciate that. I understand rolling r140285 might be not
> > the best option at this point, yet I’d personally rather not keep
> > the WebKit2GTK+ broken for too long.
> >  
> > Thanks,
> > Mario
> >  
> > [1] https://bugs.webkit.org/show_bug.cgi?id=107405
> > ___
> > webk

Re: [webkit-dev] Moving to Git?

[Carlos Garcia Campos]

El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió:
> On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik  wrote:
> > It is possible to keep linear history with git.  This just requires you to 
> > fast forward and rebase before pushing.
> 
> But can you enforce in the server? To avoid people to push it by mistake?

Yes, I think it's possible with a hook in the server.

> > Konrad
> > Sent from my BlackBerry on the Rogers Wireless Network
> >
> > ----- Original Message -
> > From: Carlos Garcia Campos [mailto:carlo...@webkit.org]
> > Sent: Thursday, March 08, 2012 12:27 PM
> > To: webkit-dev@lists.webkit.org 
> > Subject: Re: [webkit-dev] Moving to Git?
> >
> > El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
> >> On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa  wrote:
> >> > On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian 
> >> > 
> >> > wrote:
> >> >>
> >> >> In the light of discovering that some SVN scripts have fallen behind in
> >> >> terms of maintenance[1] and WebKit's strong Git support and 
> >> >> infrastructure,
> >> >> against my better judgement, I'd like to distract you from being 
> >> >> productive
> >> >> by bringing up this topic (again).
> >> >>
> >> >> The wiki page of the same name[2] was created 3 years ago and hardly
> >> >> updated since[3]. I know we're all busy with more important things, but 
> >> >> IMHO
> >> >> I think we can at least update the wiki and perhaps vote on when/how we
> >> >> should do the eventual transition.
> >> >>
> >> >> I understand that while this type of work isn't necessarily very
> >> >> productive, maintaining two repositories and sets of scripts (with their
> >> >> docs and issues) has a very real cost as well. I'm proposing we 
> >> >> reevaluate
> >> >> the situation and act accordingly.
> >> >
> >> >
> >> > Re-evaluating the situation is good, but I'm still opposed.
> >>
> >> I don't use svn but the only benefit I see of WebKit using svn is the
> >> linear history, clean, easy to read and to explore. Git repos tend to
> >> have merging commits a lot and it leads to make bisecting/history
> >> browsing harder (my taste).
> >
> > I agree about merging commits, but I think it's possible to enforce all
> > merges to be fast-forward and without merging commits. In general
> > browsing git history is easier and cleaner than svn, and more important
> > it's much faster (my taste :-P)
> >
> >> Then for everything else I use git and its power locally.
> >
> > I would be more than happy with the switch :-)
> >
> > --
> > Carlos Garcia Campos
> > http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/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
> > 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] Moving to Git?

[Carlos Garcia Campos]

El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:
> On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa  wrote:
> > On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian 
> > wrote:
> >>
> >> In the light of discovering that some SVN scripts have fallen behind in
> >> terms of maintenance[1] and WebKit's strong Git support and infrastructure,
> >> against my better judgement, I'd like to distract you from being productive
> >> by bringing up this topic (again).
> >>
> >> The wiki page of the same name[2] was created 3 years ago and hardly
> >> updated since[3]. I know we're all busy with more important things, but 
> >> IMHO
> >> I think we can at least update the wiki and perhaps vote on when/how we
> >> should do the eventual transition.
> >>
> >> I understand that while this type of work isn't necessarily very
> >> productive, maintaining two repositories and sets of scripts (with their
> >> docs and issues) has a very real cost as well. I'm proposing we reevaluate
> >> the situation and act accordingly.
> >
> >
> > Re-evaluating the situation is good, but I'm still opposed.
> 
> I don't use svn but the only benefit I see of WebKit using svn is the
> linear history, clean, easy to read and to explore. Git repos tend to
> have merging commits a lot and it leads to make bisecting/history
> browsing harder (my taste).

I agree about merging commits, but I think it's possible to enforce all
merges to be fast-forward and without merging commits. In general
browsing git history is easier and cleaner than svn, and more important
it's much faster (my taste :-P)

> Then for everything else I use git and its power locally.

I would be more than happy with the switch :-)

-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

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

[webkit-dev] WebKit2 C API

[Carlos Garcia Campos]

In the contributors meeting notes about WebKit2[1] I've read that the C
API might have been a bad idea, and I've heard that there are plans to
remove, or replace it by a C++ API. What are the plans for the C API?

In the GTK+ port we are using the C API to implement the MiniBrowser
and we are planning to provide a high level GTK+ API on top of the C
one (without exposing it), so can we rely on the C API to implement our
GTK+ one?

[1] http://trac.webkit.org/wiki/April 2011 Meeting/WebKit2

Thanks, 
-- 
Carlos Garcia Campos
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev