Re: [webkit-dev] Position on WebXr Lighting Estimation Module

[Sergio Villar Senin via webkit-dev]

O Mér, 11-11-2020 ás 11:21 -0800, Alex Cooper via webkit-dev escribiu:
> Hello Webkit,
> 
> I'd like to ask for WebKit's position on the WebXR Lighting
> Estimation Module. It's an extension of the WebXr Device API from the
> Immersive Web Community Group. The API allows web applications to
> request both the spherical harmonics representing ambient light as
> well as a reflection map. More details can be found in the explainer
> and specification draft.
> 
> Explainer: 
> https://github.com/immersive-web/lighting-estimation/blob/main/lighting-estimation-explainer.md
> Spec Draft: https://immersive-web.github.io/lighting-estimation/
> Chromestatus: https://www.chromestatus.com/features/5704707957850112
> 
> Could I get your position on this?

Not officially speaking on WebKit's name, but wanted to comment on
this. The API seems interesting and sane from the functional POV. I
just wanted to ask for the potential mitigations for the additional
fingerprinting opportunities it provides for attackers. For example, in
the case of the pose it's advised to use rounding,quantization and/or
fuzzing. Would that work for lightning estimation or would it cause
more harm than benefit (I'm thinking about the different VR sickness).

BR


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

[webkit-dev] Exposing FeaturePolicy to the web

[Sergio Villar Senin]

Hi,

WebKit currently implements the feature policy mechanism[1] to allow
developers/sites to enabled/disable certain features and/or browser
APIs like geolocation or access to camera among others.

While implementing the WebXR API I realized that we are not exposing[2]
the values of feature policies to the web. I was wondering whether that
was made on purpouse (fingerprinting?, privacy?...) or it is just
because the use cases were not considered relevant enough to implement
it. I haven't found any bug tracking that.

BR

[1] https://w3c.github.io/webappsec-feature-policy
[2] https://w3c.github.io/webappsec-feature-policy/#the-policy-object

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

Re: [webkit-dev] WebXR on WebKit

[Sergio Villar Senin]

Not sure how to interprete silence. BTW patch[*] is now ready to be
reviewed as all EWS are happy with it.

BR

[*] https://bugs.webkit.org/show_bug.cgi?id=208702

O Ven, 06-03-2020 ás 12:56 +0100, Sergio Villar Senin escribiu:
> Hi,
> 
> I've just uploaded a patch[1] (based on previous work from my
> colleague
> Žan Doberšek) which brings a very basic WebXR[2] support for WebKit.
> Right now is just IDLs, stubs and pretty basic platform code, mostly
> empty implementations anyway.
> 
> You can see WebXR[3] as the evolution of the deprecated WebVR API
> (which I recently removed from the tree). The idea is bringing the
> experience of mixed reality worlds (from VR to AR) to the Web by
> using
> the appropriate devices.
> 
> This new spec was not born in a semi-deprecated state as WebVR did.
> It's currently partially shipped in Chrome/Edge[4]. Firefox has not
> shipped it yet but Mozilla has been one of the original authors of
> the
> specs with some proposals dating back to 2017. There is ongoing work
> to
> support the spec[5].
> 
> It's worth mentioning that there are already several WPT tests[6] for
> the feature (my plan is to import them ASAP and make them work as
> APIs
> are implemented).
> 
> Another important difference from the WebVR era is that right now we
> have a multiplatform Khronos standarized API for accessing VR/AR
> devices and platforms called OpenXR[7]. My plan is to implement all
> the
> platform code using OpenXR as a reference. This would allow us to use
> even the same platform code for different ports. AFAIK there is no
> OpenXR implementation and loader available at the moment for
> MacOS/iOS
> but I guess it'll eventually happen (in any case the platform code
> could be implemented without using OpenXR of course).
> 
> Privacy has been always a concern in the WebKit project and now it
> gained the status of project goal. That's why I'd also like to
> mention
> here that privacy&security was also considered[8] since the very
> beginning. For example, when I attended the TPAC F2F meeting of the
> WebXR WG there was a joint session with the privacy CG where
> fingerprinting and other potential threat vectors were discussed.
> 
> Last but not least, I'll focus this early stages of development in
> the
> WPE port, meaning that for example I'll be maintaining just the WPE
> build configuration (other ports won't be affected). My plan is to
> extend the support to other ports as the implementation matures.
> 
> Opinions?
> 
> BR
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=208702
> [2] https://immersive-web.github.io/webxr/
> [3] https://github.com/immersive-web/webxr/blob/master/explainer.md
> [4] https://caniuse.com/#search=webxr
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1614496
> [6] 
> https://wpt.fyi/results/webxr?label=experimental&label=master&aligned
> [7] https://www.khronos.org/openxr/
> [8] https://github.com/immersive-web/privacy-and-security
> 
> ___
> 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] WebXR on WebKit

[Sergio Villar Senin]

Hi,

I've just uploaded a patch[1] (based on previous work from my colleague
Žan Doberšek) which brings a very basic WebXR[2] support for WebKit.
Right now is just IDLs, stubs and pretty basic platform code, mostly
empty implementations anyway.

You can see WebXR[3] as the evolution of the deprecated WebVR API
(which I recently removed from the tree). The idea is bringing the
experience of mixed reality worlds (from VR to AR) to the Web by using
the appropriate devices.

This new spec was not born in a semi-deprecated state as WebVR did.
It's currently partially shipped in Chrome/Edge[4]. Firefox has not
shipped it yet but Mozilla has been one of the original authors of the
specs with some proposals dating back to 2017. There is ongoing work to
support the spec[5].

It's worth mentioning that there are already several WPT tests[6] for
the feature (my plan is to import them ASAP and make them work as APIs
are implemented).

Another important difference from the WebVR era is that right now we
have a multiplatform Khronos standarized API for accessing VR/AR
devices and platforms called OpenXR[7]. My plan is to implement all the
platform code using OpenXR as a reference. This would allow us to use
even the same platform code for different ports. AFAIK there is no
OpenXR implementation and loader available at the moment for MacOS/iOS
but I guess it'll eventually happen (in any case the platform code
could be implemented without using OpenXR of course).

Privacy has been always a concern in the WebKit project and now it
gained the status of project goal. That's why I'd also like to mention
here that privacy&security was also considered[8] since the very
beginning. For example, when I attended the TPAC F2F meeting of the
WebXR WG there was a joint session with the privacy CG where
fingerprinting and other potential threat vectors were discussed.

Last but not least, I'll focus this early stages of development in the
WPE port, meaning that for example I'll be maintaining just the WPE
build configuration (other ports won't be affected). My plan is to
extend the support to other ports as the implementation matures.

Opinions?

BR

[1] https://bugs.webkit.org/show_bug.cgi?id=208702
[2] https://immersive-web.github.io/webxr/
[3] https://github.com/immersive-web/webxr/blob/master/explainer.md
[4] https://caniuse.com/#search=webxr
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1614496
[6] 
https://wpt.fyi/results/webxr?label=experimental&label=master&aligned
[7] https://www.khronos.org/openxr/
[8] https://github.com/immersive-web/privacy-and-security

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

[webkit-dev] PSA: WebVR (and OpenVR) removed from the tree

[Sergio Villar Senin]

Hi,

my Igalia colleague Žan Doberšek and myself worked on the
implementation of WebVR1.1 some time ago. We used the OpenVR library to
implement the required platform interfaces. We managed to implement the
whole API although the stereo rendering part was mostly stubs. WebVR1.1
was shipped in some VR browsers but quickly became deprecated as all
the efforts were moved to the development of the WebXR API. 

It was never shipped in any WebKit port, actually it was only buildable
for GTK and WPE ports AFAIK. The fact that it's an unshipped deprecated
API along with the current lack of interest/time to maintain it
(actually it became a maintenance burden) lead us to the decision of
removing it from the tree. The patch[1] has just landed.

Does it mean that VR (XR) is not interesting for the WebKit project?
Personally I don't think so, but I'd focus any future effort on WebXR,
a more mature API which BTW fits very well with the OpenXR
standarization effort from Khronos.

BR

[1] https://bugs.webkit.org/show_bug.cgi?id=206739



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

Re: [webkit-dev] Using compile_command.json in sources that go into Unified Sources

[Sergio Villar Senin]

O Lun, 26-03-2018 ás 14:30 +0100, Adrian Perez de Castro escribiu:
> 
> I *think* that many tools like scan-build should work equally well
> regardless
> of whether the compilation database contains the unifies or the
> individual
> sources. But of course it's difficult to predict what every other
> tool will
> do, so it's impossible to be sure :-\

There are many tools that do require to have the individual sources.
For example ycm (we already have a config file for it in tree) requires
the user to define a callback which just receives a file name (the one
being opened in the IDE) and returns the compilation flags for that
file. Should we have a way to get the unified source where each
individual file was added we could solve this easily. 

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

Re: [webkit-dev] Using compile_command.json in sources that go into Unified Sources

[Sergio Villar Senin]

O Sáb, 24-03-2018 ás 23:03 +, Cadu Bentzen escribiu:
> Hi WebKit developers,
> 
> Recently I started coding in WebKitGTK+ on Linux and I realized that
> source files that are batch-compiled in UnifiedSources don't get an
> entry in compile_commands.json, making it difficult to get flags for
> autocompletion, "go-to definition" and conditional highlighting
> feature in IDEs.

I opened https://bugs.webkit.org/show_bug.cgi?id=182689 some time ago
to track this issue.

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

Re: [webkit-dev] WebVR on WebKit

[Sergio Villar Senin]

O Mér, 02-08-2017 ás 19:55 +0200, Sergio Villar Senin escribiu:
> Hi,
> 
> some weeks ago I uploaded [1] a patch (based on previous work by my
> colleague at Igalia Zan) which basically adds the IDLs for WebVR 1.1
> spec along with the required stubs and the cmake build configuration.
> As Sam Weining perfectly pointed out, this needs some previous
> discussion in the list in order to go ahead.

[...]

> [1] https://bugs.webkit.org/show_bug.cgi?id=174202

The patch has been there for a while. All EWS are happy with it. It
would be awesome if any reviewer could take a look. Thanks!

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

Re: [webkit-dev] Growing tired of long build times? Check out this awesome new way to speed up your build... soon (HINT: It's not buying a new computer)

[Sergio Villar Senin]

O Lun, 28-08-2017 ás 17:37 -0700, Keith Miller escribiu:
> Hello fellow Webkittens,
> 
> Are you growing tired of long cat naps while waiting 45 minutes for
> WebKit to build? (I’ve definitely never done this 🤐!)
> Do you want WebKit to build up to 3-4x faster on a clean build?*
> Does seeing your incremental build… stay the same sound good?
> 
> You’ll be purring with excitement after you switch to unified source
> builds!**

[...]

> Are there other issues that people think might occur with unified
> sources? Note, It’s also likely that there are some source files that
> need to be excluded from the unified source builds for various
> reasons.

I wonder whether the unified sources builds would still allow us to
keep using compiler caches like ccache.

Second question/caveat is, wouldn't the bundle build penalize too much
incremental builds? If your data is correct we would get a <20% build
time increment for a single change in a cpp file which is I think the
most common scenario for a WebKit developer.

Don't get me wrong, I'm really excited about this change, just wanted
to make sure that it does not penalize too much other scenarios.

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

Re: [webkit-dev] CSS Typed OM

[Sergio Villar Senin]

O Mar, 22-08-2017 ás 07:54 +1000, Dean Jackson escribiu:
> 
> 
> > On 19 Aug 2017, at 5:44 am, Olmstead, Don 
> > wrote:
> > 
> > I'd like to begin an implementation of CSS Typed OM (CSSOM) and
> > wanted to gauge interest for supporting the feature.
> 
> Go for it! While the specification is probably not completely stable,
> I think it is worth starting now.

Indeed, one of the informal conclusions of the last Houdini F2F meeting
was that the API was in much better shape than 1 year ago and
definitely starting to look stable enough for implementors.

BR

> 
> Dean
> 
> >  
> > CSSOM provides typed style access to improve performance by
> > removing the need to do lots of string parsing. Its also the basis
> > of other Houdini specifications so working through it will enable
> > those specifications to be implemented.
> >  
> > If there's interest I can begin implementation after finishing up
> > some outstanding patches. Any particular pointers on good places to
> > begin are greatly appreciated as this is the first feature we here
> > at Sony have attempted.
> >  
> > Thanks
> > Don
> >  
> > Spec:
> > https://drafts.css-houdini.org/css-typed-om/
> >  
> > WebKit Bugzilla:
> > https://bugs.webkit.org/show_bug.cgi?id=175733
> > ___
> > 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] WebVR on WebKit

[Sergio Villar Senin]

O Xov, 03-08-2017 ás 10:56 -0700, Alexis Menard escribiu:
> Hi,
> 
> > On Aug 3, 2017, at 9:19 AM, Sergio Villar Senin  > > wrote:
> > 
> > O Xov, 03-08-2017 ás 08:44 -0700, Alexis Menard escribiu:
> > > Hi,
> > > 
> > > > On Aug 3, 2017, at 7:52 AM, Dean Jackson 
> > > > wrote:
> > > > 
> > > > 
> > > > 
> > > > > On 2 Aug 2017, at 19:55, Sergio Villar Senin  > > > > com>
> > > > > wrote:
> > > > > 
> > > > > 
> > > > > Our main interest is to eventually have some implementation
> > > > > working on
> > > > > WebKitGtk and/or WPE on Linux but obviously there is a lot of
> > > > > cross-
> > > > > platform work that needs to be done as well. Our initial idea
> > > > > would be
> > > > > to use the OpenVR API as Valve released a Linux version of
> > > > > their
> > > > > SDK
> > > > > some months ago. Looks like a safe bet as other vendors like
> > > > > Firefox or
> > > > > Chromium already include it in their trees as third party.
> > > > 
> > > > I agree with the idea to assume use of the OpenVR SDK at the
> > > > moment. It
> > > > is the only major VR SDK that is available for macOS, Linux and
> > > > Windows.
> > > > 
> > > > So maybe our platform API should be very similar to the OpenVR
> > > > API?
> > > > I haven't looked at other SDKs like Oculus, but hopefully it
> > > > isn't
> > > > too
> > > > different.
> > > 
> > > You should also keep an eye on OpenXR which is being discussed in
> > > Khronos. These seems like the future standard API for
> > > applications to
> > > hook into to support VR (independently of the underlaying VR
> > > runtime). More info there : https://www.khronos.org/openxr
> > 
> > Right I'm aware of that effort. The thing is that using OpenXR does
> > not
> > imply that you can get rid of native SDKs anyway. From
> > conversations I
> > had with some other people involved in WebVR efforts it looks like
> > the
> > main SDKs (like Oculus or Vive's) will be used anyway if available
> > and
> > that OpenXR would be more like a fallback for the hundreds of
> > devices
> > that will hit the market soon.
> 
> That’s correct that native VR runtimes will still be a requirements
> but they are going to be under the OpenXR application layer (read
> Oculus and Steam will most likely make their runtime OpenXR
> compliant). The benefits of OpenXR for WebKit (or any engine) is that
> you’ll have a unique backend to talk to a VR runtime (whatever the
> user has installed).

That's clear, having a unified interface for VR is something that was
never there and one of the reasons why the market has been always that
fragmented.

> Please note that OpenXR is two folds, an application interface/API
> for applications (say in this case WebKit) to talk to a VR runtime
> and render stuff (as well as getting information from the device) and
> a Device Layer used by HMDs manufacturers (or hundred devices as you
> say) so that VR runtimes can talk to any OpenXR compliant devices.
> This will help for example SteamVR or Oculus Runtime to be compatible
> with the gazillions of devices flooding the market at some point
> provided the later are compliant with OpenXR.

Right, let's hope that those two extra layers wouldn't cause any
significant performance issue, something that is still not clear IMO.

> But OpenXR is 2018 material so indeed OpenVR is probably a good bet
> for immediate support. Please note that SteamVR allows you to use
> Oculus Rift HMD not just HTC Vive so in theory (but I haven’t tried
> it with OpenVR) you shouldn’t need a dedicated backend for Oculus.

That supports my point, but that's only for Windows (as it requires
Oculus SDK if I am not wrong), isn't it? In any case, from the WebKit's
POV, OpenVR must not be a requirement, it is just one of the potential
platform libs and we'd have to design some platform API anyway. Should
we base it on OpenVR is something that could be changed in the future
to make it more friendly for other backends (like OpenXR). After all,
all the SDKs share more or less the same concepts.

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

Re: [webkit-dev] WebVR on WebKit

[Sergio Villar Senin]

O Xov, 03-08-2017 ás 08:44 -0700, Alexis Menard escribiu:
> Hi,
> 
> > On Aug 3, 2017, at 7:52 AM, Dean Jackson  wrote:
> > 
> > 
> > 
> > > On 2 Aug 2017, at 19:55, Sergio Villar Senin 
> > > wrote:
> > > 
> > > 
> > > Our main interest is to eventually have some implementation
> > > working on
> > > WebKitGtk and/or WPE on Linux but obviously there is a lot of
> > > cross-
> > > platform work that needs to be done as well. Our initial idea
> > > would be
> > > to use the OpenVR API as Valve released a Linux version of their
> > > SDK
> > > some months ago. Looks like a safe bet as other vendors like
> > > Firefox or
> > > Chromium already include it in their trees as third party.
> > 
> > I agree with the idea to assume use of the OpenVR SDK at the
> > moment. It
> > is the only major VR SDK that is available for macOS, Linux and
> > Windows.
> > 
> > So maybe our platform API should be very similar to the OpenVR API?
> > I haven't looked at other SDKs like Oculus, but hopefully it isn't
> > too
> > different.
> 
> You should also keep an eye on OpenXR which is being discussed in
> Khronos. These seems like the future standard API for applications to
> hook into to support VR (independently of the underlaying VR
> runtime). More info there : https://www.khronos.org/openxr

Right I'm aware of that effort. The thing is that using OpenXR does not
imply that you can get rid of native SDKs anyway. From conversations I
had with some other people involved in WebVR efforts it looks like the
main SDKs (like Oculus or Vive's) will be used anyway if available and
that OpenXR would be more like a fallback for the hundreds of devices
that will hit the market soon.

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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Sergio Villar Senin]

O Mér, 02-08-2017 ás 12:43 +0300, Konstantin Tokarev escribiu:
> Also, AFAICS WebAudio is not widely used across the Web. Can anyone
> point me to real
> website which is not WebAudio demo but makes use of this API somehow?

Check www.webaudioweekly.com for several examples.

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

[webkit-dev] WebVR on WebKit

[Sergio Villar Senin]

Hi,

some weeks ago I uploaded [1] a patch (based on previous work by my
colleague at Igalia Zan) which basically adds the IDLs for WebVR 1.1
spec along with the required stubs and the cmake build configuration.
As Sam Weining perfectly pointed out, this needs some previous
discussion in the list in order to go ahead.

WebVR is an API which provides support for exposing virtual reality
devices (like HMDs) to web apps so that the info coming from those
devices could be converted into position, orientation and interactions
with virtual worlds. Note that for a complete VR experience some other
APIs would be needed as for example de Gamepad API for controller
support (some extensions were proposed).

Although the spec[2] mentions that 1.1 is deprecated it is what
browsers are shipping initially as 2.0 is still in a "do not implement"
state.

Regarding interest from other vendors, WebVR is already supported in
Edge, Firefox nightly and experimental builds of Chromium. Other
browsers supporting it are Samsung Internet and Oculus Carmel.

Our main interest is to eventually have some implementation working on
WebKitGtk and/or WPE on Linux but obviously there is a lot of cross-
platform work that needs to be done as well. Our initial idea would be
to use the OpenVR API as Valve released a Linux version of their SDK
some months ago. Looks like a safe bet as other vendors like Firefox or
Chromium already include it in their trees as third party.

WDYT?

BR

[1] https://bugs.webkit.org/show_bug.cgi?id=174202
[2] https://w3c.github.io/webvr/spec/1.1/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Port For Android

[Sergio Villar Senin]

O Mar, 07-03-2017 ás 20:07 -0500, Patrick Wright escribiu:
> 
> However, in the source code of android. There is an implementation of
> Webkit show here: https://developer.android.com/reference/android/web
> kit/package-summary.html . it is just very slow and restrictive. 

That's the Android WebView which is based on Blink (Chromium). The
architecture is completely different to desktop Chromium though due to
platform limitations in Android.

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

Re: [webkit-dev] perf.webkit.org has been updated

[Sergio Villar Senin]

O Mar, 17-01-2017 ás 21:38 -0800, Ryosuke Niwa escribiu:
> I've deployed the latest v3 UI on https://perf.webkit.org/
> New UI is a lot more polished compared to the old "v1" UI, and
> provides more functionality.

Really awesome work, thanks Ryosuke for working on this!

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

Re: [webkit-dev] About unprefixing CSS Grid Layout (implementation status summary included)

[Sergio Villar Senin]

On 27/04/16 17:59, Simon Fraser wrote:
>> On Apr 27, 2016, at 4:39 AM, Manuel Rego Casasnovas  wrote:
>>
>> Hi,
>>
>> as announced yesterday it seems that the WebKit prefixing policy has
>> been updated [1].
>>
>> Right now CSS Grid Layout implementation is prefixed in WebKit and
>> behind a compilation flag.
>> We'd like to ask about the possibility to unprefix it and put it behind
>> a runtime flag (probably removing the compilation flag too).
> 
> I approve of this proposal.
> 
> Simon

Awesome. We'll unprefix it ASAP (adding the runtime flag and removing
the build one).

BR

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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Sergio Villar Senin]

On 11/11/15 11:15, Sergio Villar Senin wrote:
> On 11/11/15 08:04, Yusuke SUZUKI wrote:
>> Hello WebKittens,
>>
>> JavaScriptCore use in non-OSX environment looks emerging[1].
>> In addition to that, sometimes, people would like to build
>> JavaScriptCore to see what is happning in JavaScriptCore development[2].
>> However, if you don't have an OSX machine, it is a little bit difficult.
>> One possible solution is GTK+ port, it is nice way to build JSC in Linux.
>> But it involves many dependencies (Mesa, glib etc.), that are not
>> necessary for JavaScriptCore and this is a barrier to join JSC
>> development from non OSX world.
> 
> The gtk port has several external dependencies as any other port and
> indeed most of them are not needed for building JSC. However I don't see
> those dependencies being a barrier, mainly because we build them using a
> jhbuild environment, so even if your distro don't provide the required
> dependencies you could build them with Tools/Scripts/update-webkitgtk-libs.

BTW, as KaL points out on irc, we could teach our build scripts to not
build all the dependencies when building JSC only. I shouldn't be
difficult to create a update-jsc-libs as I think glib should be the only
dependency of WTF and JSC.

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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Sergio Villar Senin]

On 11/11/15 08:04, Yusuke SUZUKI wrote:
> Hello WebKittens,
> 
> JavaScriptCore use in non-OSX environment looks emerging[1].
> In addition to that, sometimes, people would like to build
> JavaScriptCore to see what is happning in JavaScriptCore development[2].
> However, if you don't have an OSX machine, it is a little bit difficult.
> One possible solution is GTK+ port, it is nice way to build JSC in Linux.
> But it involves many dependencies (Mesa, glib etc.), that are not
> necessary for JavaScriptCore and this is a barrier to join JSC
> development from non OSX world.

The gtk port has several external dependencies as any other port and
indeed most of them are not needed for building JSC. However I don't see
those dependencies being a barrier, mainly because we build them using a
jhbuild environment, so even if your distro don't provide the required
dependencies you could build them with Tools/Scripts/update-webkitgtk-libs.

Do you have issues doing that?

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

Re: [webkit-dev] JavaScriptCore slowdown

[Sergio Villar Senin]

On 28/06/15 16:27, Rodney Dowdall wrote:
> The only other question I have is if there is some sort of throttle on
> the JavaScript callbacks.  The reason I ask is because no matter what I
> do, the following page:
> 
> http://bubblemark.com/dhtml.htm
> 
> I only get 60 fps.  For this page the "fps" is a bit of misnomer because
> they are just measuring the number of times they get a call in to their
> JavaScript code.  It doesn't seem to matter how many balls I draw on the
> screen, I always get 60 fps .

Not completly sure about the mac port but I think it does the same as
gtk, i.e, they used that magic value of 60fps as a reference for the
accelerated compositor to know when to generate new frames.

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

[Sergio Villar Senin]

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.

BR

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

Re: [webkit-dev] Easy bugs for grab

[Sergio Villar Senin]

On 23/09/14 10:28, Benjamin Poulain wrote:
> -Unprefix your favorite CSS property (easy to hard depending on the
> property).

What's the policy for unprefixing properties? I thought that they're
prefixed as long as the feature was experimental/under heavy
development. Has it changed? (I'm particularly interested in unprefixing
grid layout properties).

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

Re: [webkit-dev] ftlopt merge - basically done

[Sergio Villar Senin]

On 06/08/14 23:35, Filip Pizlo wrote:
> Hi everyone,
> 
> The JSC “ftlopt” branch is basically merged.  I think I have one more 
> revision to merge over, and it is a minor one.  Please don’t land more things 
> on the branch.  Landing on trunk is fine; it’s unlikely to get in my way as I 
> merge the last revision over.
> 
> Thanks to everyone who helped with diagnostic problems and fixing things!

For those not following the development in that branch, mind sharing
details about what that work was about?

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

Re: [webkit-dev] WebKit Remote Web Inspector

[Sergio Villar Senin]

On 21/06/14 03:07, Vienneau, Christopher wrote:
> However your response leads me to believe that it could be as easy as
> enabling a define?  Searching my code for INSPECTOR_SERVER I only find
> it in FeatureDefinesNix.hbut no source code wrapped by it. 
> REMOTE_INSPECTOR does not show up at all.  Should I see source using
> these defines or do I misunderstand?  I’m guessing the port being used
> here doesn’t have the things you mentioned in it; which is “Cairo”.  I
> expect the server portion needed to implement isn’t too difficult, and I
> suppose the other ports could be used as examples.

As Joseph mentioned, INSPECTOR_SERVER is likely the way to go for you if
you are not using a mac port. As you can see from the list that he sent
with the files containing that compiler guard most of the code is
totally port independent. Ports just need to implement a couple of stuff
to get it working (apart from enabling the guard at build time).

Regarding the port, there is no port called "cairo", cairo is just a 2D
library used by various ports (gtk, wincairo) to render content. As you
mentioned that file, I guess you're using an old check out of WebKit
that still contains WebKitNIX which was removed from the tree some time
ago. Basically just check what GTK or EFL do and do the same.

BR

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

Re: [webkit-dev] web timing

[Sergio Villar Senin]

En 06/05/14 01:40, Alex Christensen escribiu:
> I’m working on web timing based on 
> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html
>  and the current ResourceLoadTiming class has more information than is 
> required for the spec.  I’ve trimmed it down, but it appears to be used in 
> ResourceHandleSoup.cpp and a partially-implemented 
> PerformanceResourceTiming.cpp.  Would anyone be opposed to conforming to the 
> w3c spec?  Does anyone want to keep the current structure?  I’m not sure what 
> to do with the efl and gtk build failures in 
> https://bugs.webkit.org/show_bug.cgi?id=132574 and it would be nice if we 
> could unify the code more.

I'm definitely in favor of conforming to the w3c spec. Any idea why the
recent versions provide less detailed information?.

Regarding the issues in the GTK build it looks like most of them are
trivial replaces like the ones you did for the other platforms: dnsEnd
-> domainLookupEndTime, connectStart -> connectStartTime etc...

For the values no longer present in the specs I'm fine with the removal.

BR

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

Re: [webkit-dev] Enabling CSS JIT on Linux x86_64 for EFL and GTK?

[Sergio Villar Senin]

En 01/04/14 10:58, Sergio Villar Senin escribiu:
> En 31/03/14 23:09, Benjamin Poulain escribiu:
>> Hi,
>>
>> Now that EFL and GTK use CMake, can someone look at what is missing to
>> enable the CSS JIT on Linux x86_64?
>>
>> Last time I tried, there were some issues with the headers. It is likely
>> trivial to fix with a local build.
>>
>> I would be happy to fix any problem with the compiler if it does not
>> work on Linux.
> 
> Filed https://bugs.webkit.org/show_bug.cgi?id=131022 for WebkitGtk

We finally reverted the patch enabling it as it was causing tons of
crashes. I attached a backtrace to the bug.

BR

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

Re: [webkit-dev] Enabling CSS JIT on Linux x86_64 for EFL and GTK?

[Sergio Villar Senin]

En 31/03/14 23:09, Benjamin Poulain escribiu:
> Hi,
> 
> Now that EFL and GTK use CMake, can someone look at what is missing to
> enable the CSS JIT on Linux x86_64?
> 
> Last time I tried, there were some issues with the headers. It is likely
> trivial to fix with a local build.
> 
> I would be happy to fix any problem with the compiler if it does not
> work on Linux.

Filed https://bugs.webkit.org/show_bug.cgi?id=131022 for WebkitGtk

BR

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

Re: [webkit-dev] *.webkit.org downtime Tuesday, 3/11

[Sergio Villar Senin]

En 13/03/14 09:56, Osztrogonác Csaba escribiu:
> Hi,
> 
> There are still issues after downtime:
> 
> - Apple EWS bots are still broken (Last Pass: 1 day, 16 hours ago)
> - login on build.webkit.org is broken:
> "The username or password you entered were not correct. Please go back
> and try again."

I'd add:

- login on the Wiki is not possible either (Internal Server Error).

BR

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

Re: [webkit-dev] Webkit lab downtime 5/14 - 5/15

[Sergio Villar Senin]

En 10/03/14 19:19, Lucas Forschler escribiu:
> Hello WebKit developers,
> 
> All Apple owned WebKit slaves will be going down Friday night, 5/14.  They 
> should come back online during the evening on Saturday, 5/15.
> *.webkit.org services (svn/trac/build) will NOT be affected by this outtage. 
> 
> If you have any questions, feel free to email me directly.

Could you clarify what "Friday night" means? I guess you're talking
about PST time.

BR

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

Re: [webkit-dev] Credit change set & author when merging changes

[Sergio Villar Senin]

En 14/02/14 10:09, Gyuyoung Kim escribiu:
> Hi,
> 
> When we merge own blink patch into WebKit, should we credit the original
> author in ChangeLog ?

In those cases I don't personally do that.

BR

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

Re: [webkit-dev] On web-exposing features disabled at runtime

[Sergio Villar Senin]

En 11/02/14 21:04, Maciej Stachowiak escribiu:
>> > 
>> > Why not enabling the feature entirely on trunk? (and disable it when
>> > shipping product by disabling the compile time flag?).
>> > I think feature doing that tends to become stable a lot quicker.
> Occasionally a feature is so experimental you don't even want it in nightly 
> builds - it would cause too much instability.
> 
> But it's true, a lot of the time a feature is ready for testing in nightlies 
> or developer builds, but should not be shipped just yet. I think a runtime 
> flag is actually a good way to do that. The code that will actually compile 
> and ship can more easily be tested that way (by testing with both modes of 
> the flag).

So if I understood correctly the idea would be to bring the feature flag
back and at the same time switch the runtime flag on by default for all
the ports right?

BR


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

Re: [webkit-dev] On web-exposing features disabled at runtime

[Sergio Villar Senin]

En 10/02/14 21:55, Maciej Stachowiak escribiu:

>> The question is whether this is an acceptable behavior or not, and how
>> to fix it in case we don't like it. I guess it's safe to conclude that
>> it isn't something that we want in general, as it might confuse web
>> authors (they see the how properties are available but do nothing).
>> Regarding how to fix it, I guess the idea is to do something similar to
>> what Eric did in Blink last year[2], i.e., filtering out the list of
>> properties that are runtime disabled.
> 
> It's not a good behavior, in my opinion. I am not an expert on the CSS 
> parser, but I think we should hide the CSS interface for runtime-disabled 
> features. That would allow us to consider runtime disabling instead of 
> prefixing as a tool for early testing in more cases.

Not sure why you mention the parser here, but as I mentioned in my
email, the parser currently rejects those properties associated to
runtime disabled features. The problem is that, even in those cases
we're exposing them to the JS world.

In any case I totally agree with you that runtime disabling can be a
nice replacement of prefixed properties.

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

Re: [webkit-dev] On web-exposing features disabled at runtime

[Sergio Villar Senin]

En 10/02/14 22:38, Benjamin Poulain escribiu:
> On 2/10/14, 10:40 AM, Sergio Villar Senin wrote:
>> The question is whether this is an acceptable behavior or not, and how
>> to fix it in case we don't like it. I guess it's safe to conclude that
>> it isn't something that we want in general, as it might confuse web
>> authors (they see the how properties are available but do nothing).
>> Regarding how to fix it, I guess the idea is to do something similar to
>> what Eric did in Blink last year[2], i.e., filtering out the list of
>> properties that are runtime disabled.
>>
>> Opinions?
> 
> Can't we add a compile time flag instead?
> The chromium patch you linked is inelegant and it touches some hot paths.
> 
> Another advantage of compile time flag is Andreas eventually notice when
> they become useless and remove all the unnecessary cruft ;)

Heh, then I won't make his life easier ;)

Seriously speaking, there was a feature flag that was removed in
https://bugs.webkit.org/show_bug.cgi?id=86767. Let's bring it to life.

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

[webkit-dev] On web-exposing features disabled at runtime

[Sergio Villar Senin]

Hi folks,

I'm sending this to the list because it might affect different
components inside the project.

So as smfr correctly reported here[1] for all those features that don't
have a feature flag (like grid layout) we're web-exposing the CSS
properties of the feature even if it's disabled at runtime (we're
exposing them as well for features enabled at build time but disabled at
runtime).

If I am not wrong, we just disable the parsing of those properties that
are not runtime enabled, but the properties are exposed anyway,
something easy to check doing for example:
Object.getOwnPropertyDescriptor(document.body.style, property-name).

The question is whether this is an acceptable behavior or not, and how
to fix it in case we don't like it. I guess it's safe to conclude that
it isn't something that we want in general, as it might confuse web
authors (they see the how properties are available but do nothing).
Regarding how to fix it, I guess the idea is to do something similar to
what Eric did in Blink last year[2], i.e., filtering out the list of
properties that are runtime disabled.

Opinions?

BR

[1] https://bugs.webkit.org/show_bug.cgi?id=128271
[2] https://codereview.chromium.org/14324009
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Should we explicitly disallow indentation to align lines or add an example?

[Sergio Villar Senin]

On 22/01/14 04:34, Ryosuke Niwa wrote:

> Consider what happens if someFunction was renamed to someOtherFunction.
>  If we left the second and subsequent lines intact, we'll have unaligned
> indentations.  If we did update the subsequent line to be aligned, then
> we'll be making unnecessary whitespace changes in those lines and
> clutters the subversion blame history.

This is actually a good point, I second adding that to the style guide.

BR

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

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Sergio Villar Senin]

On 03/01/14 19:55, Cosmin Truta wrote:
> On Fri, Jan 3, 2014 at 1:11 PM, Alexey Proskuryakov  > wrote:
>> One shouldn't need even basic familiarity with style system to see
> whether code leaks, introduces refcount thrashing, or copies too much.
> Using auto tends to make such mistakes much more opaque.
> 
> How about preserving not only the ptrs and refs, but also the
> CV-qualifiers, when applicable?
> 
> Example 1:
> auto* cache = new Cache; // right
> auto cache = new Cache; // wrong, should be auto*
> Cache* cache = new Cache; // wrong, should be auto*
> 
> Example 2:
> const ClipboardFormatMap& formatMap = getClipboardMap(); // right
> const auto& formatMap = getClipboardMap(); // also right
> auto& formatMap = getClipboardMap(); // wrong, missing const
> auto formatMap = getClipboardMap(); // wrong, missing const and &

IMHO by using auto preserving the qualifiers we gain nothing and lose
the type information.

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

Re: [webkit-dev] Importing W3C tests for HTML template elements

[Sergio Villar Senin]

On 21/11/13 09:16, Ryosuke Niwa wrote:
> Maciej says he'd rather see w3c directory under imported directory so
> I'm doing that.

That was not done for other set of imported tests. Are you planning to
move them also to that same place?

BR

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

Re: [webkit-dev] Range based loops

[Sergio Villar Senin]

On 08/11/13 10:08, Žan Doberšek wrote:
> These types of loops don't appear to be available in MSVC 2010, which
> AFAIK still needs to be supported.
> http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx

Yeah so I guess the question becomes whether there are plans to move to
MSVC 2012 or not.

BR

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

[webkit-dev] Range based loops

[Sergio Villar Senin]

As the project steadily moves to C++11 I was wondering whether range
based loops are desirable or not. I don't remember any specific
discussion about which C++11 features people like to use in the project
(I know we're using some of them auto, std::move semantics, rvalues...).

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

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

[Sergio Villar Senin]

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

I think Martin Robinson is the one to ask here but AFAIK we're always in
AC mode unless some error occurs, like if we're unable to create the GL
context. Oh, and I think AC is not working either when running WK2 in
Wayland.

BR

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

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

[Sergio Villar Senin]

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

GTK is not using coordinated graphics, we do WebProcess compositing.

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

Re: [webkit-dev] Use BlinkMergeCandidate to merge/back port Blink changes

[Sergio Villar Senin]

En 21/05/13 06:06, Ryosuke Niwa escribiu:
> Hi,
> 
> We’ve added BlinkMergeCandidate keyword to Bugzilla to track any Blink
> changes we might want to merge.  Please add this keyword when you’re
> filing a bug or posting a patch to merge a Blink change.

There is an interesting question about merging fixes from Blink. Should
we keep the original author in the ChangeLog appending the name of the
merger maybe?

BR

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

Re: [webkit-dev] Turning CSS Variables Off

[Sergio Villar Senin]

En 16/05/13 00:07, Bear Travis escribiu:
> Hi Sergio,
> 
> It's great to hear your interest in the project. As a bit of background,
> CSS Variables is a feature that was originally proposed and developed by
> some folks over at Google. Since the Blink fork, they have continued to
> work on the feature there, but there is no current feature owner (at least
> to my knowledge), in WebKit.

Yeah I know. That's why I tried to get in contact with Luke Macpherson,
the author of the current implementation, but it looks like he isn't
working in Chromium any more.

> My take on the matter is that the feature is incomplete in WebKit, and
> very much needs an active owner to move forward. Without one, it will not
> be able to keep up with the rest of the project, causing snafus like the
> recent run-in with shape-inside (bug 115802 mentioned below). And that
> doesn't even include progress on the feature itself.

Yeah I understood the same from the "Cleaning house"-like recent
threads. I agree that unmaintained features are undesired sources of
issues and even side effects as you mention.

> Is this a responsibility you would be interested in taking on? I wasn't
> sure from your previous email if that was the case. At a minimum, you
> would probably need to fix up bugs that cause issues with other features,
> and stay attentive to regressions.

What I wanted to state in my email is that ideally, the owner should be
someone that had previously participated in the spec definition and/or
the current implementation. I don't fulfill such requirements, but I
have experience contributing to other parts of the project, I think the
feature is interesting and nobody else have stepped up. Summing up, yes,
I'd be happy to try to fix bugs and track regressions while also aiming
to advance the feature.

BR

> -Bear
> 
> On 5/14/13 3:46 AM, "Sergio Villar Senin"  wrote:
> 
>> En 14/05/13 00:36, Bear Travis escribiu:
>>> Hello WebKit,
>>>
>>> There has already been some discussion about removing the CSS Variables
>>> code [1], and some early looks at what removing it from the code base
>>> would look like [2].
>>> Currently, the EFL and GTK ports enable CSS Variables in the
>>> Source/cmake/Options[Efl/GTK].cmake files. I am proposing turning them
>>> off and excluding the CSS Variables tests until someone steps up to
>>> maintain the feature, or the feature is removed.
>>
>> While not being an expert on CSS stuff I plan to devote some time from
>> now on to the CSS variables stuff (I fixed a minor issue recently
>> https://bugs.webkit.org/show_bug.cgi?id=115802). I'm currently working
>> on fixing some bugs and I regularly check Blink also (looks like google
>> seems much more interested in the feature).
>>
>> So I am not really sure I could be considered as "maintainer" but
>> definitely could try to keep the feature alive.
>>
>> 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] Turning CSS Variables Off

[Sergio Villar Senin]

En 14/05/13 00:36, Bear Travis escribiu:
> Hello WebKit,
> 
> There has already been some discussion about removing the CSS Variables
> code [1], and some early looks at what removing it from the code base
> would look like [2].
> Currently, the EFL and GTK ports enable CSS Variables in the
> Source/cmake/Options[Efl/GTK].cmake files. I am proposing turning them
> off and excluding the CSS Variables tests until someone steps up to
> maintain the feature, or the feature is removed.

While not being an expert on CSS stuff I plan to devote some time from
now on to the CSS variables stuff (I fixed a minor issue recently
https://bugs.webkit.org/show_bug.cgi?id=115802). I'm currently working
on fixing some bugs and I regularly check Blink also (looks like google
seems much more interested in the feature).

So I am not really sure I could be considered as "maintainer" but
definitely could try to keep the feature alive.

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

Re: [webkit-dev] Overtype mode in WebKit for editable content?

[Sergio Villar Senin]

En 12/04/13 19:00, Ryosuke Niwa escribiu:
> On Fri, Apr 12, 2013 at 9:50 AM, Sergio Villar Senin  Well, I have a pretty compact patch more or less ready to be uploaded to
> bz that in the case of the caret being placed at (3) just draws the
> classical 1px width bar (it also draws the thin bar in the case of being
> after the last character), so although the replaced character is in any
> case the 1, the insanity you mention is somehow minimized.
> 
> 
> That doesn't sound right either.  It's much more confusing than not
> setting any width at all because the overtype mode is still on.
> 
> What we need to do is here to use selection.  We need to have
> 1-character long text selection at all time except at the end of each
> line when overtype is on since selection code already deals with the
> said bidi craziness.  Anything short of that isn't landable quality.

Ok, sounds like a very different approach. Just to clarify, do you mean
to skip the caret painting in overtype mode and just use the 1-character
selection as if it were the caret?

BR

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

Re: [webkit-dev] Overtype mode in WebKit for editable content?

[Sergio Villar Senin]

En 12/04/13 18:17, Ryosuke Niwa escribiu:
> On Fri, Apr 12, 2013 at 4:40 AM, Sergio Villar Senin  For example consider the strongly LTR letters
> "abc" inside a RTL block, which will be rendered as "abc". If we either
> place the caret at the beginning (before 'a') or at the end (after 'c')
> the next typed character will be placed at the opposite side the user
> might expect based on the caret position.
> 
> 
> That's expected.

I know it's expected :) but that does not mean that characters appearing
at remote locations (from caret POV) is not weird. I know that WK
follows the NSTextView implementation but FF for example does not show
the remote insert issue.

> The problem here is that caret will be on top of a wrong character.
>  That's much worse than a character being inserted at a remote location.
>  Using my existing example, what user sees is:
> 123CBA or 123CBA
> yet what will be replaced is 1.  That's insane.
> 
> This is orders of magnitude worse than caret showing up as a vertical
> line at this location:
> 123|CBA

Yeah I understood you example, it was very descriptive. What I wanted to
share with you is that, in your same example, in "Insert" mode, placing
the caret at (3) will insert the next character before the 1. Isn't that
insane too?

> And this is why just setting the width of caret will never work.

Well, I have a pretty compact patch more or less ready to be uploaded to
bz that in the case of the caret being placed at (3) just draws the
classical 1px width bar (it also draws the thin bar in the case of being
after the last character), so although the replaced character is in any
case the 1, the insanity you mention is somehow minimized.

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

Re: [webkit-dev] Overtype mode in WebKit for editable content?

[Sergio Villar Senin]

En 12/03/13 18:31, Ryosuke Niwa escribiu:
> That doesn't work. At a bidi-level boundary, offset can jump from one
> place to another. Consider a much simpler example; the same sequence of
> letters, in logical order, ABC123 in a RTL block, which will be rendered as:
> 123CBA
> with logical/DOM offsets placed at:
> (6)1(4)2(5)3(3)C(2)B(1)A(0)
> 
> Again, at offset 3, what we're going to replace is "1" so we can't place
> the block caret on top of either "C" or "3".

The problem is that such kind of "weird" behaviors are happening now
without overtype mode. For example consider the strongly LTR letters
"abc" inside a RTL block, which will be rendered as "abc". If we either
place the caret at the beginning (before 'a') or at the end (after 'c')
the next typed character will be placed at the opposite side the user
might expect based on the caret position.

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

Re: [webkit-dev] Unmaintained feature list

[Sergio Villar Senin]

En 08/04/13 19:57, Julien Chaffraix escribiu:
>> Sounds like a great idea:
>> http://trac.webkit.org/wiki/UnmaintainedFeatureList
> 
> Thanks for starting this.
> 
> Added CSS Grid Layout to the list as I don't think I would be able to
> do merges back. I would be more than happy to remove the code if
> people feel the need.
> 
> If anyone wants to take over, I would be more than happy to provide
> any needed assistance. The opened bugs on bugzilla should be an
> accurate representation of the amount of work remaining **

I'll have some time in a couple of weeks or so to start looking at it,
so expect me to request your assistance :)

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

Re: [webkit-dev] Overtype mode in WebKit for editable content?

[Sergio Villar Senin]

En 12/03/13 05:11, Ryosuke Niwa escribiu:
> So I guess the question boils down to something like: if we have
> changes that are generally useful, but not used in the major WebKit
> applications (i.e. Chrome, Safari, Opera), does it make sense to
> upstream it to WebKit for the benefit of the general community?
> 
> 
> Yes. It makes a lot of sense for this feature to be in WebKit. We can
> probably expose some member functions on Editor or add new execCommand
> only executable via menu/keyboard binding to toggle this feature.  I
> don't think it makes a sense for WebCore to detect Insert Key and
> automatically move into the inse
> 

Will handle it here http://wkb.ug/112126 then.

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

[webkit-dev] Overtype mode in WebKit for editable content?

[Sergio Villar Senin]

Hi,

I was wondering if WebKit as a project would be interested in having
overtype mode support for editable content. This in indeed the mode in
which the cursor, when typing, overwrites any text that is present on
and after its current location [1].

Looks like something like that could be useful to implement online
editing tools. Just for reference, both IE and Opera support it while in
Firefox the bug was closed as WONTFIX [2] after a lot of discussion.

Thoughts?

[1] http://en.wikipedia.org/wiki/Insert_key
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=38415
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)

[Sergio Villar Senin]

En 22/01/13 09:52, Maciej Stachowiak escribiu:
>> That'd be awesome, at least an overview document that could help people
>> to understand the whole picture and the main advantages/drawbacks of the
>> selected design.
> 
> What topics are you interested in? I could probably write decent explanations 
> of:
> 
> - NetworkProcess: tradeoffs for making it a process vs a thread in the UI 
> process
> - Load interception for proxying - ResourceHandle vs. ResourceLoader layer, 
> pros and cons for each
> - What code runs inside the network process, exactly?
> 
> Any other topics folks would be interested in?

Those are pretty interesting topics that you both (you and Adam I mean)
touched in this thread, but actual information was mixed with personal
opinions I think so it'd be nice to have it in separate docs.

Regarding any other additional topics, what about a discussion about how
sandboxing is supported by the design (also part of the thread)?

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

Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)

[Sergio Villar Senin]

En 21/01/13 23:07, Maciej Stachowiak escribiu:
> 
> On Jan 21, 2013, at 11:23 AM, Adam Barth  wrote:
> 
>> Some folks have pointed out to me off thread that I'm coming off as
>> angry and harsh.  I would like to apologize for my tone.
>>
>> My goal here is not to obstruct or block your progress on the
>> NetworkProcess.  My goal is to end up with a common design that we can
>> share between WebKit2 and Chromium or at least have a common way of
>> interfacing with WebCore.  My concern is that I don't believe that the
>> current path the NetworkProcess is taking leads to a common design or
>> interface.
>>
>> Anyway, it's probably best to continue this conversation another time.
>> We can certainly iterate on the approach once you all are feeling
>> less schedule pressure.
> 
> Thanks, Adam. It's fine to pick up the conversation later, and we're 
> certainly open to iterating beyond what we do first.
> 
> We're also happy to meet with anyone interested in this topic to discuss in 
> person, or to document more of our design decisions in writing if the 
> community would find that helpful. 

That'd be awesome, at least an overview document that could help people
to understand the whole picture and the main advantages/drawbacks of the
selected design.

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

Re: [webkit-dev] distributed build for WebKit on Mac OS 10.8

[Sergio Villar Senin]

En 21/01/13 19:39, Zeno Albisser escribiu:

> I was more successful using distcc
> from: http://www.opensource.apple.com/source/distcc/
> This one seemed to work fairly well. The only problem I had was that Qt
> is not actually using xcodebuild.
> Therefore I could not make use of any bonjour service to update my hosts
> list and had to do that manually.
> But if you know the machines in your network and can rely on them being
> available, keeping a static list might be an option.

JFTR this can be easily done in linux just by adding +zeroconf to the
list of hosts. It will then use the DNS-SD discovery services to find
your distcc nodes in the local network.

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

Re: [webkit-dev] the new TestExpectations syntax is landing soon

[Sergio Villar Senin]

En 14/09/12 18:34, Sergio Villar Senin escribiu:
> En 13/09/12 01:29, Dirk Pranke escribiu:
>> Hi all,
>>
>> The new format of the much-debated TestExpectations syntax will be
>> landing soon (hopefully in the next couple days).
> 
> Dirk I was wondering, does the new format support the case of tests
> working fine in WK2 but failing in WK1?

Beh, I guess we can just use PASS in a WK2 specific TestExpectations...

BR

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

Re: [webkit-dev] the new TestExpectations syntax is landing soon

[Sergio Villar Senin]

En 13/09/12 01:29, Dirk Pranke escribiu:
> Hi all,
> 
> The new format of the much-debated TestExpectations syntax will be
> landing soon (hopefully in the next couple days).

Dirk I was wondering, does the new format support the case of tests
working fine in WK2 but failing in WK1?

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

[webkit-dev] New WK2 tests bot for the GTK port

[Sergio Villar Senin]

Hi,

as you might have noticed in http://build.webkit.org, there is a new
64-bit release GTK bot since yesterday. That new bot was setup to run
the WebKit2 tests.

As the main focus of people involved in the GTK port development is
steadily moving to WebKit2, we see this as a must for the port. There is
still stuff to tune in the bot, but in general the main pieces are
ready, and this new bot will hopefully help a lot the WebKit2 development.

Thx to all that helped setting it up.

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

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

[Sergio Villar Senin]

En 21/06/12 19:54, William Siegrist escribiu:
> On Jun 21, 2012, at 10:43 AM, Jon Lee  wrote:
> 
>> Is something being upgraded right now?
>>
> 
> No, the config file has a problem in it which is unrelated to our upgrade as 
> far as I can tell. I'm trying to track down what happened. 
> 
> $ buildbot checkconfig

Do we have any tool that allows to check locally changes in the slaves
configuration?

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

Re: [webkit-dev] webkit debug build error - memory exhausted even on 32GB Ram

[Sergio Villar Senin]

En 13/06/12 10:25, Navanshu Mahor escribiu:
> Hello webkit.org  community,
> 
> 
> i am trying to build webkit in debug mode on server that is 64bit and
> 32GB RAM system.
> Inspite of having such large ram it is showing following memory
> exhausted error :
>  
> /usr/bin/ld: failed to set dynamic section sizes: Memory exhausted
> collect2: ld returned 1 exit status
> make[1]: *** [libwebkitgtk-3.0.la ] Error 1
> 
> Hope to get a satisfactory response.

I can build debug wk builds with no problems with 8GB of RAM. What exact
build options are you using?

Have you tried to use the gold linker (binutils-gold package on debian
for example) ?

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

Re: [webkit-dev] NPN_InvokeDefault failure

[Sergio Villar Senin]

En 26/04/12 19:47, tmals...@codeaurora.org escribiu:
> Hello,
> 
> Calling NPN_InvokeDefault from a plugin fails sometimes using the latest
> built for gtk (using JavaScriptCore).  The failure occurs because the
> if (!rootObject || !rootObject->isValid())
> check fails in NP_jsobject.cpp@_NPN_InvokeDefault.

Looks like a bug, could you please file a bug about that? Also add me on
CC please.

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

Re: [webkit-dev] Top 100 sites browsing tests proprosal

[Sergio Villar Senin]

En 27/04/12 01:19, Ryosuke Niwa escribiu:
> See my posts about archive.org-based performance tests. We can use the
> same infrastructure to make sure WebKit doesn't crash :)

Yeah that's great! I just forgot to replay to that thread :)

> In fact... running top 100 websites as performance tests might just do
> the trick because we'll catch any crashes (can't catch assertion
> failures though :( ).

Having performance tests will indeed catch the "obvious" crashes, but I
was not specially concerned about them because our Layout tests would
likely catch them first. I was mainly interested in assertions. Why not
just use debug builds with the same cool infrastructure you're
developing and call it top-100/assertion/whatever tests?

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

Re: [webkit-dev] [GTK] GtkLauncher segfault

[Sergio Villar Senin]

En 20/03/12 15:42, 박상호 escribiu:
> hi,
> 
> I meet this seg-fault always. somebody help me?

That's an already known bug in WebKit, the code hits an ASSERT whenever
you try to convert icon image data to port specific image data. See
https://bugs.webkit.org/show_bug.cgi?id=67582 for more details.

If you still want to use the debug version of GtkLauncher you can
workaround the assert just by commenting the whole iconLoadedCb()
function in Tools/GtkLauncher/main.c (by doing that you won't get
favicons in the url entry).

BR

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

Re: [webkit-dev] NPAPI plugin crashes while calling npnfuncs->invoke in GtkLauncher

[Sergio Villar Senin]

En 15/03/12 08:13, souvik.da...@wipro.com escribiu:
> Hi,
> 
> I am trying to load my NPAPI plugin in GtkLauncher ( built from source
> version-1.6.1  under Ubuntu 10.10). The plugin is used to communicate
> with a native shared library.  Although I am able to load the plugin (
> Got NP_Initialize and NP_GetEntryPoints calls on the console ) and make
> successful calls to my native shared library from Java Scripts (through
> my plugin), but when I am trying to call a java script function "from"
> my plugin using :
> 
> err = npnfuncs->invoke(npp_, console, id, args_temp,
>  sizeof(args_temp) / sizeof(args_temp[0]),
>  &voidResponse);
> 
> I am observing a segmentation fault. This is always happenning.

Can you get a trace?

BR

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

Re: [webkit-dev] Moving to Git?

[Sergio Villar Senin]

En 08/03/12 13:35, Ashod Nakashian escribiu:
> WebKittens,
> 
> 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).

Please correct me if I'm wrong but IIRC the main blocker was that any
user with an standard OS X setup should be able to start hacking on
WebKit without having to install any additional dependency. SVN is
shipped with OS X and git is not.

Anyway I'd be really pleased if that move happens.

BR

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

Re: [webkit-dev] (no subject)

[Sergio Villar Senin]

En 29/02/12 18:42, Ojan Vafai escribiu:
> On Wed, Feb 29, 2012 at 12:43 AM, Sergio Villar Senin
> > Do you know how to use git rebase -i?
> 
> Konstantin, that's why I meant with "merge several commits in a single
> one". You do not normally want to do that while you're developing a
> patch as having multiple commits gives you a lot of flexibility while
> developing. I normally have to create a new branch to rebase the commits
> I want in a single patch to upload it to the bz. That is annoying,
> that's why I said that having something like webkit-patch upload
> range_of_commits will be nice to have, as you wouldn't have to create a
> new branch and rebase several commits, just to upload a new patch to
> the bz.
> 
> 
> You can do this with the current -g option by adding a commit range,
> e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently
> with -g is pass a commit range *and* include the staged/working copy
> changes.

Good to know. Thx Ojan for the clarification.

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

Re: [webkit-dev] (no subject)

[Sergio Villar Senin]

En 29/02/12 09:33, Konstantin Tokarev escribiu:

>> Although I normally use it for cherry-picking a commit to upload, I have
>> always missed the option to upload a bunch of commits as a single patch.
>> Basically, as you said, forcing people to merge several commits in a
>> single one to upload a patch to bz totally breaks the typical git
>> workflow (micro-commits and so).
> 
> Do you know how to use git rebase -i?

Konstantin, that's why I meant with "merge several commits in a single
one". You do not normally want to do that while you're developing a
patch as having multiple commits gives you a lot of flexibility while
developing. I normally have to create a new branch to rebase the commits
I want in a single patch to upload it to the bz. That is annoying,
that's why I said that having something like webkit-patch upload
range_of_commits will be nice to have, as you wouldn't have to create a
new branch and rebase several commits, just to upload a new patch to the bz.

BR


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

Re: [webkit-dev] (no subject)

[Sergio Villar Senin]

En 28/02/12 22:06, Dirk Pranke escribiu:
>> I'm beginning to think it probably makes sense to add a different
>> commandline argument that works exactly like diff (e.g. takes an optional
>> second value). --git-diff perhaps?
>>
> 
> Based on the responses on this thread, I agree with you. It looks like
> a fair number of people either want "cherry-pick" or "diff against
> remote master". I will probably implement a separate switch for "pure
> git".

Although I normally use it for cherry-picking a commit to upload, I have
always missed the option to upload a bunch of commits as a single patch.
Basically, as you said, forcing people to merge several commits in a
single one to upload a patch to bz totally breaks the typical git
workflow (micro-commits and so).

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

Re: [webkit-dev] (no subject)

[Sergio Villar Senin]

En 28/02/12 04:46, Ryosuke Niwa escribiu:
> Do people really use "git diff" that often? I don't use git much but
> when I do I always get annoyed by the way "git diff" works because I
> almost always want "git diff master".

>From my own experience, when you're used to a git workflow, you almost
never mean "git diff master" when you do "git diff".

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

Re: [webkit-dev] How to prevent conditional interfaces from being added as supplemental interfaces

[Sergio Villar Senin]

En 23/02/12 19:08, Adam Barth escribiu:
> Hi Sergio,
> 
> This sounds like a bug in the code generator.  The intent is that
> supplemental interfaces can be disabled using the Conditional
> attribute, just like other interfaces.  Would you be willing to file a
> bug at bugs.webkit.org and CC Kentaro and myself?

Done. Pasting here the link for those interested

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

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

Re: [webkit-dev] Web Inspector tests for DOM node highlights

[Sergio Villar Senin]

En 22/02/12 20:10, Max Vujovic escribiu:
> Hello,
> 
> I was wondering if there are any Web Inspector tests that check the
> appearance, size, or position of a DOM node highlight. By DOM node
> highlight, I mean the translucent margin box, border box, padding box, and
> content box combination that WebKit draws over a DOM node when you inspect
> it.

Could be also useful to test text highlighting in searches.

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

[webkit-dev] How to prevent conditional interfaces from being added as supplemental interfaces

[Sergio Villar Senin]

Hi,

I've been trying to build the GTK port without geolocation support and
found that is no longer possible (after r108610). The reason is because
that commit removes an #ifdef guard that was hiding the actual issue IMO.

Thing is that NavigatorGeolocation.idl specifies a conditional interface
to be added to the Navigator interface. It seems fine as the conditional
clearly specifies that it needs the GEOLOCATION feature. The generated
code properly has the #ifdef guards to ensure that the generated code is
only built if geolocation is enabled. The problem is that it generates a
function whose signature is something like

WebKitDOMGeolocation*
webkit_dom_navigator_get_geolocation(WebKitDOMNavigator* self);

It does not matter that the implementation is correctly surrounded by
the proper #ifdefs as the doc says[1] because the compiler will always
complain due to the lack of WebKitDOMGeolocation object.

So my question is, shouldn't the platform specific bindings generators
(resolve-supplemental.pl maybe?) skip the addition of supplemental
interfaces to their parents if the specified conditions are not met?

BR

[1]: http://trac.webkit.org/wiki/IdlAttributes
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Top 100 sites browsing tests proprosal

[Sergio Villar Senin]

En 22/01/12 20:24, Thiago Marcos P. Santos escribiu:
> On Sun, Jan 22, 2012 at 1:06 PM, Pablo Flouret  Maybe instead of storing a local snapshot (assuming you need static
> content for the tests), you can use a online snapshot of a top 100
> website from http://web.archive.org for validation. Not sure if by doing
> that you can face the same copyright issues, and... IANAL. :)

Maybe I didn't explain myself correctly, but my idea was not to store
snapshots in the WebKit SVN, it will not be a developer's tool like the
Layout tests or ref tests but something that will act similar to the
EWS. You will not be supposed to run those tests manually, bots will.

That's the reason why I was not understanding the copyright concerns. I
know that they won't work offline, but again their purpouse will not be
to detect regressions ASAP as the layout tests, but to complement them.

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

Re: [webkit-dev] Top 100 sites browsing tests proprosal

[Sergio Villar Senin]

En 21/01/12 14:31, Zoltan Herczeg escribiu:
> Just be careful with copyright issues.

Could you elaborate on that?

BR


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

[webkit-dev] Top 100 sites browsing tests proprosal

[Sergio Villar Senin]

Hi,

I've been thinking about this for some time now, but only a recent bug
I'm constantly hitting these days
(https://bugs.webkit.org/show_bug.cgi?id=76574) triggered this email
[1]. What I would like to propose here is to have a battery of tests
that would check that the most visited sites (let's say the top 100 for
example) are correctly loaded by WebKit. By correctly loaded, I don't
mean layout or ref tests, they'll just check that the page poad ends
without any assertion.

I know that trunk is for raw development but having >25k layout tests
passing is nothing if a so popular site as Wikipedia triggers an
assertion while being loaded. The obvious answer is "ok so we need more
tests", we all agree on that, but having like "real-word" permanent
tests would not harm I guess (and probably help defining more layout tests).

I haven't took a detailed look at them, but maybe these main sites
browsing tests could be part of the perf tests rniwa and others recently
setup.

What do you think?

BR

[1] note that I am not blaming anyone in particular, we all add bugs,
just that this one finally flipped the switch :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] [PATCH] JSCore with GDB

[Sergio Villar Senin]

En 28/12/11 12:38, Sanjoy Das escribiu:
> I've not included ChangeLog entries since they are a pain to rebase,
> I'll add them once the code has been reviewed.

Add the following to your .gitconfig

[merge "changelog"]
driver = resolve-ChangeLogs --merge-driver %O %A %B

and assuming you have Tools/Scripts is in your PATH it will
automatically rebase the ChangeLogs for you.

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

Re: [webkit-dev] About 165 Editing Tests Require Rebaselines per Bug 51389

[Sergio Villar Senin]

En 02/03/11 10:53, Benjamin escribiu:
> On Wed, Mar 2, 2011 at 7:36 AM, Ryosuke Niwa  > wrote:
> 
> I'm specifically asking for the convenient time for Chromium, GTK,
> Qt, and Windows ports since they have test bots running on
> build.webkit.org .
> 
> 
> For Qt, most people are in CET timezone.

Same happens for GTK+.

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