Re: [webkit-dev] [webkit-help] ResizeObserver

[Antonio Gomes]

moved to webkit-dev, bcc'ing webkit-help
+Cathie

I know Cathie is working on it. Cathie, feel free to provide a status update.

On Tue, Jan 22, 2019 at 4:06 PM Eric Gorr  wrote:
>
> Will do.
>
> Might be worth mentioning this feature on https://webkit.org/status ... ?
>
> On Tue, Jan 22, 2019 at 2:57 PM Simon Fraser  wrote:
>>
>> On Jan 22, 2019, at 11:46 AM, Eric Gorr  wrote:
>>
>> I was just wondering when we might expect the ResizeObserver ( 
>> https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver ) to be 
>> supported in webkit ?
>>
>>
>> Please express your interest on 
>> https://bugs.webkit.org/show_bug.cgi?id=157743
>>
>> I don't' have anything to share about a schedule for this feature. As 
>> always, we're taking patches!
>>
>> Simon
>>
> ___
> webkit-help mailing list
> webkit-h...@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-help
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Incorrect expectation for fast/forms/range/slider-delete-while-dragging-thumb.html

[Antonio Gomes]

Does it pass (or is un-skipped) for any platform/port?

If so, how does its result differ from Gtk/Qt's?

On Wed, Jul 27, 2016 at 7:32 AM, Konstantin Tokarev  wrote:
> Hello,
>
> Test fast/forms/range/slider-delete-while-dragging-thumb.html is marked as [ 
> Failure ] on many platforms.
>
> Attached expected result passes on GTK and Qt ports. Would it be correct to 
> replace contents of 
> LayoutTests/fast/forms/range/slider-delete-while-dragging-thumb-expected.txt 
> with this file?
>
> Diff:
>
>  dragging slider
>  mousemove
>  mousedown
> +mousemove
> +input
>
>  deleting slider
>
>
>
> --
> Regards,
> Konstantin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Building Webkit on Windows

[Antonio Gomes]

Hi Rakesh.

See "GoodFirstBugs" or "EasyFix" classes of bugs in bugs.webkit.org,
e.g. https://bugs.webkit.org/buglist.cgi?quicksearch=EasyFix&list_id=1643027
.

On Wed, Mar 30, 2016 at 4:39 AM, Rakesh Sadhu  wrote:
>
> Hi Alex  and all Friends here  ,
> Its finally build .
> I have a question, I wanna contribute and i would like to start with easy
> and baby steps kinda bugs.
> Any suggestions ?
>
>
> regards
> RSadhu
>
>
> 
> Subject: Re: [webkit-dev] Building Webkit on Windows
> From: achristen...@apple.com
> Date: Mon, 29 Feb 2016 10:26:00 -0800
> CC: thomas.br...@porabo.ch; bfulg...@apple.com; mmaxfi...@apple.com;
> webkit-dev@lists.webkit.org
> To: rakeshsa...@hotmail.com
>
>
> Rakesh, you are building the AppleWin port of WebKit, which only has 32-bit
> binaries available, but you probably want to use the WinCairo port because
> the license of WebKitSupportLibrary.zip says you’re not allowed to
> redistribute it.  To build the WinCairo port, you will need to run
> update-webkit --wincairo and build-webkit --wincairo --64-bit.
>
> This is not the source of your build failure, though.  It looks like you
> have your gperf executable inside of C:\Program Files… somewhere, and I
> believe we have never had anyone build WebKit with a configuration like
> this.  I think the solution is to put quotes around the %s at the very end
> of Source/WebCore/platform/network/create-http-header-name-table.  There
> might be a few more places where this is needed.  Could you please file a
> bug a bugs.webkit.org with a patch if you get it working?
>
> On Feb 27, 2016, at 2:01 AM, Rakesh Sadhu  wrote:
>
>
> Hi Thomas,
> Thank for your  answer .
> However my build suddenly fails and I notice , its creating 32 bit binaries
> .
> I am attaching a build log file here .
>
> regards
> RSadhu
>
>
> 
> To: achristen...@apple.com
> From: thomas.brodt.li...@porabo.ch
> Date: Fri, 26 Feb 2016 09:15:06 +0100
> CC: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Building Webkit on Windows
>
> Hi Alex
>
> thank you for your prompt answer. That is good news because in the past I
> had different difficulties in setting up a functional environment with
> several trial and error steps inbetween, although I tried to exactly follow
> the installation guide. I tend to create a virtual machine for a reliable
> building environment, so with my next one I will try without the cygwin
> installation.
>
> We use Webkit via COM interface on Windows in our application here, so I
> build rather infrequently, and with a working build, we then can live for
> some time. But for our use we would need 32bit dependencies, and if I
> understood correctly, there are currently only 64bit available. That doesn't
> matter at the moment, but when I am ready for our next build, I would ask
> again if you don't mind.
>
> Thanks for your help!
>
> Thomas
>
> Am 25.02.2016 um 19:17 schrieb Alex Christensen:
>
> That also applies to the WinCairo port.  I don’t think you’ll need GNU Make
> any more now that we use CMake for Windows.  You also shouldn’t need to
> install iTunes to build and run WinCairo.  With WinCairo, you will also need
> the WinCairoDependencies.zip which you can get by running
> Tools/Scripts/update-webkit-wincairo-libs.  Right now, only the 64-bit
> dependencies are included in that zip, but let me know if you need 32-bit
> dependencies.  They are from https://github.com/peavo/WinCairoRequirements
> Then you should be able to build with Tools/Scripts/build-webkit --wincairo
> --64-bit
>
> We really should update the instructions on webkit.org
>
> On Feb 25, 2016, at 12:17 AM, Thomas Brodt 
> wrote:
>
> Does this also apply for the WinCairo port? Or does this port still require
> cygwin?
>
> Thomas
>
> Am 24.02.2016 um 20:32 schrieb Alex Christensen:
>
> Those instructions are out of date.  The most up-to-date instructions about
> building on Windows are http://trac.webkit.org/wiki/WindowsWithoutCygwin
>
> On Feb 24, 2016, at 9:57 AM, Myles C. Maxfield  wrote:
>
> What is the error you are seeing?
>
> On Feb 24, 2016, at 9:26 AM, Rakesh Sadhu  wrote:
>
> Hello ,
> I am trying to build webkit on Windows .
> I am following  steps from https://webkit.org/building-webkit-on-windows/
> However I am unable to find a way to build webkit using MSVS2015 or  Cygwin
> .
> Can anyone guide here please?
> regards
> RSadhu
>
> ___
> 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
> w

Re: [webkit-dev] Should overridden methods use 'virtual' keyword in addition to 'override'?

[Antonio Gomes]

On a side node, there are lots of lines like

virtual void foo(..) override final;

.. ending up like:

void foo(..) override final;

Ideally though, "override" could also get removed and it would read as

void foo(..) final;

It is a good follow up once the first patch bakes for a while in ToT
(without regression).

On Fri, Mar 4, 2016 at 12:47 PM, Darin Adler  wrote:
>> On Mar 4, 2016, at 6:54 AM, Konstantin Tokarev  wrote:
>>
>> I have WebCore patch ready for upload.
>
> Yes, I had already done this last night 
> . Just haven’t landed it yet 
> because tiled-drawing tests were failing. Fixing that now.
>
> — 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] support for navigator.cores or navigator.hardwareConcurrency

[Antonio Gomes]

(I am not in favor of this feature but not strongly opposed neither but..)

I think a similar analogy is:

$ make -jX #where X is the number of physically available cores.

If I am working/browsing/text editing, etc and building say WebKit in the
background, I really do not set X to actually number of cores. When I do,
it actually slows my whole system.


On Wed, May 7, 2014 at 5:47 PM, Oliver Hunt  wrote:

>
> On May 7, 2014, at 2:41 PM, Rik Cabanier  wrote:
> >
> > When would I as a user, not want a page or web application to be as fast
> as possible? Has a user ever complained about a desktop app that uses too
> many of his CPU's? I think Oliver's point was that other processes might
> fight for the same CPU resources but that is not unexpected for users.
>
> What happen if i go to your website while i'm doing something else in the
> background?  What if i'm playing a game while waiting for my machine to do
> something else? What if your page is in the background? Or my battery is
> running low.
>
> You need to stop thinking in terms of a user wanting only one thing to
> happen at a time.
>
> --Oliver
>
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Heads-up: ENABLE_GESTURE_EVENTS removal

[Antonio Gomes]

+1 for that.

On Thu, Oct 10, 2013 at 6:18 PM, Anders Carlsson  wrote:
> Hello,
>
> I’m planning to remove the ENABLE_GESTURE_EVENTS ifdef and related code. It 
> was used by Chromium (and perhaps to some extent Qt) as well as WebKit2 for 
> trackpad events before we switched over to wheel events (which is the 
> recommended way to do things). From what I can see all the code in both 
> WebKit2 and WebCore is dead.
>
> - Anders
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Announcement: CSS3_TEXT_DECORATION flag

[Antonio Gomes]

All (?wincairo I'm not sure?) ports on trunk use the new Inspector,
and the old one is being removed:
https://bugs.webkit.org/show_bug.cgi?id=122295

On Fri, Oct 4, 2013 at 2:24 PM, Sam Weinig  wrote:
> Or better yet, enable it for all ports on ToT.
>
> -Sam
>
>
> On Oct 4, 2013, at 11:03 AM, Timothy Hatcher  wrote:
>
> Can we enable CSS3_TEXT_DECORATIONS on the Apple ports once you add it?
>
> I have a legitimate use for -webkit-text-decoration-color that would allow
> me to eliminate a hack in the Inspector.
>
> — Timothy Hatcher
>
>
> On Oct 4, 2013, at 10:45 AM, Myles C. Maxfield  wrote:
>
> Hello, all!
>
> Between the current and previous versions of the CSS3 Text spec, the text
> decoration section was split out into its own spec [1] [2] [3]. Because of
> this shift, I’m going to be creating a new compile-time flag:
> CSS3_TEXT_DECORATIONS. Proposal for the features themselves was mentioned in
> [4]. For those who wish to follow progress, the feature bug is at [5]. The
> first thing I am working on is the text-decoration-skip: ink property [6]. I
> will also be migrating existing text-decorations code from behind the
> existing CSS3_TEXT flag to behind this new CSS3_TEXT_DECORATIONS flag.
>
> Thanks,
> Myles C. Maxfield
>
> [1] http://www.w3.org/TR/2012/WD-css3-text-20120814/
> [2] http://www.w3.org/TR/css3-text/
> [3] http://www.w3.org/TR/css-text-decor-3/
> [4] https://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html
> [5] https://bugs.webkit.org/show_bug.cgi?id=58491
> [6] https://bugs.webkit.org/show_bug.cgi?id=121806
> ___
> 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] Announcing new port: Nix

[Antonio Gomes]

So will you advocate your users to use your external GitHub version or
the one in
WebKit?

Please consider not being half upstream.

On Fri, Sep 13, 2013 at 2:37 PM, Hugo Lima  wrote:
> On Fri, Sep 13, 2013 at 3:00 PM, Anders Carlsson  wrote:
>>
>> On Sep 12, 2013, at 1:58 PM, Hugo Lima  wrote:
>>
>>> On Thu, Sep 12, 2013 at 4:14 PM, Ryosuke Niwa  wrote:
 Interesting. That sounds a lot like Chromium's WebKit API layer.  If I
 remember correctly, that layer had to be modified constantly as
 WebCore/WebKit code was refactored so I'm a bit worried about this.
>>>
>>> Yes, in fact we got some API from them.
>>
>> This is my biggest concern with the Nix port; that it will end up exposing 
>> implementation details of our platform layer, making it harder for us to 
>> perform sweeping changes to said layer (for example, like what Darin is 
>> doing with his pasteboard cleanup patches).
>>
>> In fact, it reminds me of the WebKit2 situation (before we instituted the 
>> build policy) where some changes that should in theory take days would end 
>> up taking weeks because of:
>>
>> - Churn waiting for the EWS bots to do their thing.
>> - Churn due to patches being rolled out for breaking other ports (due to 
>> certain build flags being enabled in said ports).
>> - Churn due to patches being rolled out for breaking other ports (due to 
>> misconceptions about the correct WebKit2 semantics in said ports).
>>
>> Maybe we would need a similar build policy for WebCore?
>>
 But it sounds like you're suggesting that Nix port's maintainers will be
 responsible for making any code changes necessary to support
 WebCore/WebKit/WebKit2 refactoring?
>>>
>>> Yes, this is the idea, is our concern to keep our code working.
>>
>> I am glad to hear that. Does that mean that we’re allowed to break the Nix 
>> port without having patches rolled out by members of the Nix team?
>
> This already happen nowadays, so it would not change too much our
> development. Even after nix upstream process we will probably keep a
> copy on github with few additional patches that may not fit on e.g.
> WebKit2 or need to be landed a bit faster on our tree due to some
> customer needs.
>
> I didn't talk with other team members about it, but IMO it's not a big
> deal to break it on these kind of WebCore changes that affect all
> ports, I'm saying this because the chance of having these patches
> breaking other ports as well is considerable too, besides if the
> change get announced on this ML before get landed we'll have enough
> time to adapt to it.
>
>> - 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] Are Qt and GTK+ intentionally returning false in shouldShowPlaceholderWhenFocused?

[Antonio Gomes]

On Tue, Aug 20, 2013 at 1:52 PM, Ryosuke Niwa  wrote:
> Thanks for the confirmation, Martin!
>
> I've started to wonder if we can tie this to the editing behavior instead.
> Isn't this more about the platform UI than each framework?

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

Re: [webkit-dev] Scrolling overflow:hidden boxes..

[Antonio Gomes]

I did not test exhaustively (various different scenarios), but
hopefully it is of help:

- text selection drag-scrolling of overflow:hidden :
http://jsfiddle.net/auk9S/8/

Safari/Chrome/Opera15: perform scroll
Mozilla: does not perform scroll
Opera12 (pre-blink): does not perform scroll

- programmatic scrolling of overflow:hidden (via
element.scrollIntoView):
LayoutTests/fast/transforms/scrollIntoView-transformed.html

Sarafi/Chrome/Opera15: perform scroll
Mozilla: perform scroll
Opera12 (pre-blink): perform scroll


On Fri, Aug 16, 2013 at 6:26 PM, Simon Fraser  wrote:
> On Aug 16, 2013, at 2:45 PM, Antonio Gomes  wrote:
>
>> Hi.
>>
>> Bug https://bugs.webkit.org/show_bug.cgi?id=119760 (Text dragging can
>> scroll overflow:hidden boxes) caught  my attention to the following
>> situation:
>>
>> - imagine a page has an input field within a overflow:hidden ,
>> and user starts text selecting from the input field text by dragging
>> with the mouse. At some point it goes outside of the input boundary,
>> reaches the outer  boundary. By then, 'autoscroll' takes place
>> (see WebCore/page/AutoscrollController.cpp/h), and scrolls the outter
>> . In my opinion, it should not happen, due to div's
>> overflow:hidden style.
>>
>> A natural solution for that could be hardening
>> RenderLayer::scrollRectToVisible, when its upwards recursion occurs;
>> so instead of picking the current layer parent, it picks the enclosing
>> scrollable layer instead.
>>
>> However, it seems acceptable that overflow:hidden div's RenderLayers
>> are  scrollable in certain situations. Consider the case of
>> Element.scrollIntoView(), for example: as of now, WebKit scrolls an
>> container overflow:hidden div, if it is to bring an HTML element into
>> view.
>>
>> Both situations go through the same RenderLayer::scrollRectToVisible method.
>>
>> Introducing a ScrollSource parameter to indicate where the scrolling
>> action came from (user interaction or not), and relax or harden the
>> recursion criteria accordingly would not help, because it would break
>> autoscrolling within shadow DOM content (think of autoscrolling an
>> input's shadow DOM div).
>>
>> Do you guys have thoughts on that?
>
> How do other browsers behave in terms of drag-scrolling of overflow:hidden,
> revealing content in overflow:hidden, and programmatic scrolling of 
> overflow:hidden?
>
> Simon
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Scrolling overflow:hidden boxes..

[Antonio Gomes]

Hi.

Bug https://bugs.webkit.org/show_bug.cgi?id=119760 (Text dragging can
scroll overflow:hidden boxes) caught  my attention to the following
situation:

- imagine a page has an input field within a overflow:hidden ,
and user starts text selecting from the input field text by dragging
with the mouse. At some point it goes outside of the input boundary,
reaches the outer  boundary. By then, 'autoscroll' takes place
(see WebCore/page/AutoscrollController.cpp/h), and scrolls the outter
. In my opinion, it should not happen, due to div's
overflow:hidden style.

A natural solution for that could be hardening
RenderLayer::scrollRectToVisible, when its upwards recursion occurs;
so instead of picking the current layer parent, it picks the enclosing
scrollable layer instead.

However, it seems acceptable that overflow:hidden div's RenderLayers
are  scrollable in certain situations. Consider the case of
Element.scrollIntoView(), for example: as of now, WebKit scrolls an
container overflow:hidden div, if it is to bring an HTML element into
view.

Both situations go through the same RenderLayer::scrollRectToVisible method.

Introducing a ScrollSource parameter to indicate where the scrolling
action came from (user interaction or not), and relax or harden the
recursion criteria accordingly would not help, because it would break
autoscrolling within shadow DOM content (think of autoscrolling an
input's shadow DOM div).

Do you guys have thoughts on that?

Cheers,

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

[Antonio Gomes]

Ah, thanks for clarifying. That changes the scenario then. Question is
back to open: is there any port that would be willing to have this
feature's build flag ON by default?

Cheers,

On Thu, Jul 25, 2013 at 3:38 PM, Martin Robinson  wrote:
> On Thu, Jul 25, 2013 at 7:01 AM, Antonio Gomes  wrote:
>> Given that we have a port shipping it (GTK), and usage and interest
>> from on the TV industry and that Opera is working hard to get it
>> included to CSS3 UI spec, it looks good to me for implementing this
>> feature. If there is no objections, please proceed and guard it behind
>> a build flag.
>
> For the sake of clarity: as far as I know, WebKitGTK+ does not have
> nor is shipping this feature. It may be shipping on some downstream
> and proprietary version of the GTK+ port, though.
>
> --Martin
___
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.

[Antonio Gomes]

Given that we have a port shipping it (GTK), and usage and interest
from on the TV industry and that Opera is working hard to get it
included to CSS3 UI spec, it looks good to me for implementing this
feature. If there is no objections, please proceed and guard it behind
a build flag.

Cheers,

On Thu, Jul 25, 2013 at 7:04 AM, Mario Sanchez Prada
 wrote:
> Hi Kyounga,
>
>> [...]
>> First, I filed up my new patch based on the latest webkit without new
> feature-name even though this discussion wasn't concluded.
>
> I did not find any patch in bugzilla for bug 66027 newer than the one from
> Jan 2012 when I started doing the experiments, so that's why I came up with
> my own rebased version. Now I see you posted a newer version already, thanks
> for doing that.
>
>> If you think this feature should be behind ENABLE_CSS_DIRECTIONAL_FOCUS,
> I'll make a new patch.
>
> That's probably a good idea but first we need to clarify whether this might
> fit or not integrated in webkit.org. And in order to do that, as Benjamin
> mentioned, we need to have at least one port using and maintaining that
> feature, so that's why I proposed that we could help doing that work for the
> WebKitGTK+ port, besides helping with the development of your patch, if you
> wish.
>
>> If this feature is widely used in TV industry and is included in next
> CSS4,
>> it is not bad implementing this feature in Webkit. Isn't it?
>
> I agree with you, but for the feature to make it to upstream WebKit some
> more things are needed, as it was explained previously in this thread.
>
>> And then, should I mark the 66027 bug as "Reopended" to review it?
>
> I would say so, but before asking for review over it, and besides the
> ongoing discussion here, I believe the patch needs still some changes in
> addition to being rebased, such as adding tests to it and probably
> re-writting the part based on the now called DeprecatedStyleBuilder which,
> according to r148363, should not be used to add new properties since a while
> ago.
>
> Thanks for your reply,
> Mario
>
> [1] http://trac.webkit.org/changeset/148363
>
>> -Kyounga
>>
>> > 2013/7/25 Mario Sanchez Prada 
>> > Hi,
>> >
>> > For the sake of completeness, I'd like to mention that this feature is
> also
>> > used in the Hbbtv browser shipped with Samsung TVs, as Giuseppe Pascale
> from
>> > Opera already pointed out in a recent discussion[1].
>> >
>> > That, together with what it was mentioned about the SmartTV Alliance
> using
>> > it, means that pretty much the whole TV world is relying quite a bit on
> this
>> > thing nowadays, so it would be great if we could have it integrated and
>> > supported upstream.
>> >
>> > That being said, we at the Samsung would be happy to support this
> feature
>> > actively in WebKit, both by helping with the patch that's already in
>> > Bugzilla [2] *and* maintaining it in at least one port. Should that be
> the
>> > case, the obvious choice for us would be the WebKitGTK port, since
> that's
>> > what we currently have on our TVs.
>> >
>> > Problem is that the patch in [2] is quite old already (Jan 2012), so it
>> > would be awesome if Kyounga Ra attached a newer version of it, since
> that
>> > one depends on some parts that are now deprecated or simply refactored
> in
>> > some way, as I could check today while experimenting with it on top of
>> > latest WebKit [3].
>> >
>> > Last, regarding to tests, just to mention that Opera has recently
> submitted
>> > tests for this feature (see [4]). This would be IMHO another good point
> to
>> > keep in mind here, since we could import them in WebKit too.
>> >
>> > What do you think?
>> > Mario
>> >
>> > [1] http://lists.w3.org/Archives/Public/www-style/2013Jun/0332.html
>> > [2] https://bugs.webkit.org/show_bug.cgi?id=66027
>> > [3]
> https://github.com/mariospr/webkit/commit/5bda577699599aa4f99192380b46ad73e5
> ea1672
>> > [4]
> http://lists.w3.org/Archives/Public/public-css-testsuite/2013Jul/0004.html
>>
>> > -Original Message-
>> > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
>> > boun...@lists.webkit.org] On Behalf Of Danilo Cesar Lemes de Paula
>> > Sent: 24 July 2013 14:52
>> > To: webkit-dev@lists.webkit.org
>> > Subject: Re: [webkit-dev] Adding ENABLE_CSS_DIRECTIONAL_FOCUS to
>> > WebCore.
>> >
>> > On 07/23/2013 09:26 PM, Kyounga Ra wrote:
>> > > -Which browsers are shipping the feature?
>> > > -Which browsers are planning to ship the feature?
>> > > A) other major browsers? opera presto
>> > > also Webkit-based TV browsers support it.
>> > >
>> > > -Is it a mature standard (or an amazing feature) that one of the
>> > > WebKit ports wants to maintain?
>> > > A) not matured yet. but these properties are widely used by the TV
>> > > industry.
>> > >  TV industry people like me want to maintain.
>> > >
>> >
>> > nav-[dir] is a required part of the SmartTV Alliance spec, so it's
>> > probably being used by Phillips, LG and Toshiba TVs.
>> >
>> > Danilo Cesar
>> >
>> > 

Re: [webkit-dev] webkit-patch and clearing flags

[Antonio Gomes]

I found it very useful while reviewing to look at a bug and see what a
patch has been r-'ed before. Even if it has been marked as obsolete by a
follow up patch.

It is a valuable quick reference of the patch/bug/work history.


On Wed, May 29, 2013 at 12:21 PM, Bem Jones-Bey  wrote:

> Hey WebKit,
>
> Would it be reasonable for webkit-patch to not clear flags on an
> attachement when it obsoletes it if there's an r+? Maybe it doesn't
> actually matter (i.e. I know I can still commit the patch), but it bothers
> me when it clears away an r+ because I forgot to tell it --no-obsolete when
> I'm updating a patch for nits.
>
> - Bem
> ___
> 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] Christophe Dumez is now a WebKit reviewer

[Antonio Gomes]

Congratulations, Chris.

--Antonio Gomes
Software Engineer
Samsung Research America - Silicon Valley.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feature announcement: WebCL

[Antonio Gomes]

Hi.

The input received, including during the WebKit meeting, will be discussed
within the WebCL working group, before proceeding with any upstream action.

In the meantime, feel invited to check our current implementation [1], and
to express their views on WebCL either here or on the Khronos mailing list (
public_we...@khronos.org).

Thanks,

[1] https://github.com/SRA-SiliconValley/webkit-webcl
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feature announcement: WebCL

[Antonio Gomes]

On Wed, May 1, 2013 at 8:41 PM, Oliver Hunt  wrote:

>
> On May 1, 2013, at 5:29 PM, Antonio Gomes  wrote:
>
> - 4.3 Out-of-Range Memory Access
>
> The validator will perform static analysis on WebCL kernels to
> determine violations of WebCL kernel behavior and language restrictions.
> The results from the analysis will also be used to determine any
> necessary instrumentation to bring the WebCL kernels in compliance with
> security and syntactic requirements of the WebCL API.  The RFQ for the
> WebCL Validator located at
> https://cvs.khronos.org/wiki/index.php/WebCL_Validator provides
> information on the approach recommended by the WebCL working group.
>
>
> How do you statically verify the all memory accesses are within bounds
> without limiting a WebCL kernel to the functionality already offered by
> shaders in WebGL?
>

Basically there are three different cases to consider when adding checks to
a memory access:
1. We know at compile time that the access will be inside memory allocated
to the program.
2. We know at compile time the limits which the access must respect.
3. We don’t even know the limits at compile time (this causes most overhead
to support).

I think you are talking about 3? If that is the case, the WebCL validator
will handle this case.

> - 4.6 Prevention of potential denial of service (DoS) from long running
> kernels:
>
> This is addressed by the OpenCL CL_CONTEXT_TERMINATE extension. In
> http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf ,
> please refer to section "9.16 Terminating OpenCL contexts".
>
> I haven't seen any real evidence of widespread support for responsive
> termination in WebGL shaders yet, and given that the same hardware is
> involved when you want GPU backed WebCL I don't see how much this will help.
>

First, from a GPU vendor perspective, OpenCL and OpenGL drivers are
different things.

When WebCL working group proposed this OpenCL security extension, it had to
pass through an internal approval process, by vote, where the Khronos
members, including GPU vendors,  approved it.

In the case of OpenGL/WebGL, I would prefer to defer to someone who is part
of these WGs to state on why it was not requested.

> It is chicken-egg problem: without Browser vendors commitment to WebCL,
> the  motivation for hardware vendors to implement, for example, OpenCL 1.2
> "Memory Initialization" and "Context termination" extensions, required by
> WebCL, is not as strong.
>
>
> The extensions mentioned above are required by WebGL shaders, and WebGL
> has been around for a lot longer (and has even more stringent requirements
> than WebCL) - are there any GPUs that support the WebGL restrictions
> natively?
>
> If you are talking about  GL_ARB_robustness, it is supported by NVIDIA and
Mesa3D, among others.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feature announcement: WebCL

[Antonio Gomes]

On Tue, Apr 30, 2013 at 8:33 PM, Geoffrey Garen  wrote:

> Over the past weeks, some discussion involving WebCL took place in this
> mailing list ([2]), when some concerns were raised, and to which I later on
> tried to address in [3].
>
>
> I believe your answer in [3] to the security problems posed by WebCL was
> that a standards group is working on a security specification, which future
> GPUs might implement. Do any GPUs implement that specification?
>
>
Hi Geoff.

It is chicken-egg problem: without Browser vendors commitment to WebCL, the
 motivation for hardware vendors to implement, for example, OpenCL 1.2
"Memory Initialization" and "Context termination" extensions, required by
WebCL, is not as strong.

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

Re: [webkit-dev] Feature announcement: WebCL

[Antonio Gomes]

On Tue, Apr 30, 2013 at 8:14 PM, Benjamin Poulain wrote:

> On Tue, Apr 30, 2013 at 5:10 PM, Antonio Gomes wrote:
>
>> At this time, I would like to contribute our WebCL prototype
>> implementation [4] to WebKit.org.
>>
>> Feature would be defined behind a ENABLE(WEBCL) feature flag, and work
>> will be tracked onhttps://bugs.webkit.org/show_bug.cgi?id=115457.
>>
>> Let me know if you have any comments or concerns.
>>
>
> Which ports intent to ship that?
>

Hi Benjamin.

WebKit/EFL is our primary target platform.

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

Re: [webkit-dev] Feature announcement: WebCL

[Antonio Gomes]

Hi Oliver. Thanks for your comments and suggestions. Here's an update on
WebCL security.

First some background: within Khronos a cross working group security
initiative was started by the WebCL working group to engage with the
OpenCL, WebGL, OpenGL and OpenGL-ES working groups and representatives from
the hardware, driver, browser and developer communities. The WebCL WG
worked closely with the OpenCL WG, and has defined two OpenCL security
extensions which have been ratified by Khronos.

Looking at the various security requirements you mentioned from the WebCL
working draft.

- 4.2 Cross-Origin Information Leakage

WebCL's position is that this be handled by the same mechanism as used for
WebGL, ie https://www.khronos.org/registry/webgl/specs/latest/#4.2 . A bug
will be filed to request update of wording in the working draft.

- 4.3 Out-of-Range Memory Access

The validator will perform static analysis on WebCL kernels to
determine violations of WebCL kernel behavior and language restrictions.
The results from the analysis will also be used to determine any
necessary instrumentation to bring the WebCL kernels in compliance with
security and syntactic requirements of the WebCL API.  The RFQ for the
WebCL Validator located at
https://cvs.khronos.org/wiki/index.php/WebCL_Validator provides information
on the approach recommended by the WebCL working group.

- 4.4 Memory Initialization to prevent information leakage:

This is addressed by the OpenCL CL_CONTEXT_MEMORY_INITIALIZE extension. In
http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf , please
refer to section "9.15 Local and Private Memory Initialization".

- 4.6 Prevention of potential denial of service (DoS) from long running
kernels:

This is addressed by the OpenCL CL_CONTEXT_TERMINATE extension. In
http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf , please
refer to section "9.16 Terminating OpenCL contexts".

With regards to HALF/SINGLE/DOUBLE, you can see that as tracked in
https://www.khronos.org/bugzilla/show_bug.cgi?id=808 , it was agreed that
support is through extensions ("khr_fp64" and "khr_fp16") and not
supported, at this time, in the core API.

I wanted to note that the WebCL API working draft is work in progress.
 Once completed by the WebCL WG, and approved by the Khronos Promoters, its
availability will be announced to public as a specification.  Khronos
generally works on specifications internally, before they are made public.
 However, for web-based APIs, such as WebGL and WebCL, the members were
allowed to share working drafts of the APIs, prior to completion.

--Antonio Gomes

On Tue, Apr 30, 2013 at 8:36 PM, Oliver Hunt  wrote:

> Before i saw any patches landed i would expect the specification to state
> exactly what kernel features are allowed and required.
>
> Additionally the specification language of the security section is fairly
> weak - 4.2 doesn't say how CORS will be used to achieve security.
>  Presumably WebCL just wants the WebGL security resource semantics, but the
> language needs to be explicit.
>
> How is 4.3 enforced?
>
> The only way to reliably enforce 4.4 is to either restrict the valid
> kernel constructs (see my first point - you aren't defining the kernel
> semantics sufficiently well), or to avoid ever pushing the kernels onto a
> gpu.  On the plus side not pushing the kernel to the GPU means executing on
> the CPU, and so having the benefit of sane interruption and memory access
> behavior, which neatly solves 4.6.
>
> I'd rather not support the half-float format anywhere, as that simply
> means at some point in the communication paths we end up having to do a
> software double or single to half conversion, and back again later, all in
> order to support older GPUs that don't support single, assuming we even let
> the kernel get anywhere near the gpu.
>
> In general I don't like the design of the API, I believe it over-exposes
> system information and doesn't sufficiently define edge case behavior.
>
> --Oliver
>
> On Apr 30, 2013, at 5:10 PM, Antonio Gomes  wrote:
>
> Hello.
>
> As discussed before, Khronos has been working on a specification
> for WebCL, a JavaScript API that exposes GPUs and multi-core processors
> for intensive compute tasks. The latest version of the working draft is
> available here: [1].
>
> Over the past weeks, some discussion involving WebCL took place in this
> mailing list ([2]), when some concerns were raised, and to which I later on
> tried to address in [3].
>
> At this time, I would like to contribute our WebCL prototype
> implementation [4] to WebKit.org.
>
> Feature would be defined behind a ENABLE(WEBCL) feature flag, and work
> will be tracked onhttps://bugs.webkit.org/show_bug.cgi?id=115457.
>
> Let me know if 

[webkit-dev] Feature announcement: WebCL

[Antonio Gomes]

Hello.

As discussed before, Khronos has been working on a specification for WebCL,
a JavaScript API that exposes GPUs and multi-core processors for intensive
compute tasks. The latest version of the working draft is available here:
[1].

Over the past weeks, some discussion involving WebCL took place in this
mailing list ([2]), when some concerns were raised, and to which I later on
tried to address in [3].

At this time, I would like to contribute our WebCL prototype implementation
[4] to WebKit.org.

Feature would be defined behind a ENABLE(WEBCL) feature flag, and work will
be tracked onhttps://bugs.webkit.org/show_bug.cgi?id=115457.

Let me know if you have any comments or concerns.

Cheers,

[1]
https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html

[2] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024546.html
[3] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024747.html
[4] https://github.com/SRA-SiliconValley/webkit-webcl

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

[webkit-dev] obtaining webkit.org address?

[Antonio Gomes]

Previously people used to get SVN accounts associated to a
@webkit.orgalias. Today it seems like it is preferable to get a
company email as
alias, and credential to write-access SVN.

On Sunday, April 28, 2013, Glenn Adams wrote:

> How does a committer/reviewer obtain a webkit.org address? I notice that
> the majority of existing committers and reviewers have either a webkit.orgor a
> chromium.org address listed in contributors.json. I think it an important
> part of being part of the WK community to be able to identify oneself as
> being in that community, and having a usable webkit.org address seems a
> good way to effect that.
>
> G.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Antonio Gomes]

On Fri, Apr 26, 2013 at 2:19 AM, Oneal Bluce  wrote:

> Hi Mikhail,
>
>  Like what's you said, now WebCL have some serious security issues, we
> also try to some approach to fix this issue or make the security issue in a
> limited scope.  such as we can use provide some high level parallelization
> data structure , like what's done in RiverTrail . At the same time , we can
> set a independent running environment for each web application or web site.
>
>

Please refer to
https://lists.webkit.org/pipermail/webkit-dev/2013-April/024747.html regarding
WebCL security aspects discussion.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Some thoughts on WebCL

[Antonio Gomes]

Hi.

Over the past year and a half Khronos has been working on a specification
for WebCL - a JavaScript API that exposes GPUs and multi-core processors
for computational tasks.

Samsung and others have developed various prototype implementations.
Recently we have been updating our WebKit-based implementation to reflect
the latest draft spec and to be more consistent with WebKit design. Our new
version is located here:
https://github.com/SRA-SiliconValley/webkit-webcl

The WebCL working draft itself has evolved, and the feedback received by
the community has been discussed and addressed where applicable. The latest
version is available here:
https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html


There has been some discussion about WebCL and parallel computing in the
mailing list and we'd like to express our views on the role of WebCL.

First, we think of WebCL more like a specialized toolbox for
JavaScriptlibrary providers, specifically those targeting compute
intensive use
cases. Areas such as image/photo editing, video and audio processing,
physical simulation, data visualization are natural candidates. That said,
it is unrealistic to expect every web developer to take WebCL and create,
say, a new vision library. Nonetheless, libraries using WebCL would be of
interest to large groups of developers simply because of the performance
gains.

Another issue that has been mentioned are potential security concerns.
WebCLuses "compute kernels", which like
WebGL shaders, are written in a C-like language. WebCL kernels can use
pointers to potentially access memory that should not be visible to the
application. This could compromise the browser or even the host device.
Protecting against out-of-bounds memory access, and other vulnerabilities,
such as denial-of-service, has been a priority in the design of WebCL since
its inception. Khronos has defined a series of security extensions designed
to harden the OpenCL drivers on which WebCL is based. Two OpenCL extensions
proposed by the WebCL Working Group (WG), have been ratified and are
currently part of the OpenCL extension specification. The "Context
Termination" extension provides protection against denial-of-service, and
the "Memory Initialization" extension enforces protection against memory
leakage. In addition, the WebCL WG has started a project for a "WebCL
Kernel Validator". The validator will enforce out-of-bounds memory
protection, and will provide syntax validation for WebCL kernels. As GPU
vendors start to implement the context termination and memory
initialization extensions in their respective OpenCL drivers, the broader
browser community has an opportunity to provide feedback to this process.

Some alternatives to WebCL have been mentioned in the mailing list. These
include Intel's ParallelArray and some form of beefed-up web workers. These
other approaches do not necessarily conflict with WebCL since their focus
is not really GPU compute. We do see some definite benefits for WebCL.
First WebCL gives flexibility in specifying GPU computation through its
compute kernels - kernels can be written for media processing, physical
simulation etc. Secondly, it dovetails nicely with WebGL - WebCL supports
sharing GPU objects with WebGL. For example, a VBO created by WebGL could
be passed to WebCL for manipulation. This type of exchange can be done
completely on the GPU, no need to read the potentially large objects back
into host memory.

Our current WebCL prototype is mature and open for review by the
WebKitcommunity. In addition to our efforts, others are also working
on
WebCL implementations. Nokia has contributed a WebCL prototype which can be
accessed through a special Firefox build. Additional details on other
WebCLimplementations can be found here:

https://www.khronos.org/assets/uploads/developers/library/2013-march-meetup-WebCL/WebCL-March-Meetup-2013.pdf


We encourage the WebKit community to participate in the WebCL discussions (
public_we...@khronos.org) and invite your feedback.

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

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Antonio Gomes]

Hi

On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert  wrote:

>
> Yes, leveraging multicore and the power of GPUs for general computations
> is great and very powerful but first, securing such kernels is hard, and
> authoring these would be pretty brutal to most web developers, I think this
> is what Benjamin was referring to.
>
> With WebCL, you are basically writing C style kernels that you load and
> run to drive the computations, initiatives like RiverTrail are more
> restrictive but way more approachable and closer to the web, exposing
> higher level primitives on top of WebCL (ParallelArray for example) and
> integrated at the language level, which makes a lot of sense.
>
>
Security is a primary goal of WebCL, and both WebCL and OpenCL working
groups are working together to ensure a safe parallel programming
environment to the Web, as you can see in [1]. If you have specific
concerns, please raise it in the Khronos working group mailing list ([2])
or file a bug ([3]) against the draft spec.

[1]
https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html#4
[2] http://www.khronos.org/webcl/public-mailing-list/
[3] https://www.khronos.org/bugzilla/enter_bug.cgi?product=WebCL
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Antonio Gomes]

Hi Oneal.

As pointed out by Jesus, Samsung is working on a WebCL implementation for
WebKit. https://github.com/SRA-SiliconValley/webkit-webcl is being our
staging repo.

As for your question, it is a bit unclear that if by "multi-process
support" you are referring the Web/UI process model provided by WebKit2, or
the Web/GPU processes implemented by the Chromium port (now on Blink).

Our roadmap, which includes announcing the feature here on webkit-dev very
soon, has WebKit2 based ports as a first target. As a secondary goal,
Chromium (and its GPU-process architecture) would be targeted.

Cheers,


On Tue, Apr 9, 2013 at 5:40 AM, Oneal Bluce  wrote:

> Hello, I'm a researcher and I just focusing on the multi-process
> supporting and WebCL supporting in browser engin. so I have some concerns
> about the both features.
> In recently, Google has pronounced that they will support the
> multi-process in their browser egin(Blink) which is forked from the webkit.
> but Google will not supporting the WebCL in Blink.  so I just want to know
> is there a plan supporting the multi-process and WebCL in webkit.
>
>
> Cheers,
> Oneal
>
> ___
> 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] Is there a plan for supporting multi-process and WebCL in webkit

[Antonio Gomes]

Hi.

Correct WebCL link is https://github.com/SRA-SiliconValley/webkit-webcl .
Cheers,


On Tue, Apr 9, 2013 at 8:01 AM, Jesus Sanchez-Palencia wrote:

> Hi,
>
> WebKit already support a split process model which is what we call WebKit2
> [1].
> I'm not aware of any official plans of supporting WebCL but I believe
> Samsung was doing some research on this [2].
>
> [1] http://trac.webkit.org/wiki/WebKit2
> [2] https://code.google.com/p/webcl/
>
> Cheers,
> jesus
>
>
> 2013/4/9 Oneal Bluce :
> > Hello, I'm a researcher and I just focusing on the multi-process
> supporting
> > and WebCL supporting in browser engin. so I have some concerns about the
> > both features.
> > In recently, Google has pronounced that they will support the
> multi-process
> > in their browser egin(Blink) which is forked from the webkit. but Google
> > will not supporting the WebCL in Blink.  so I just want to know is there
> a
> > plan supporting the multi-process and WebCL in webkit.
> >
> >
> > Cheers,
> > Oneal
> >
> > ___
> > 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] Do any ports still disable SVG?

[Antonio Gomes]

QtWebKit has a --minimal option where SVG is disabled IIRC.

On Fri, Jan 25, 2013 at 2:27 PM, Jochen Eisinger  wrote:
> Many chromium developers disable svg for faster building.
>
> Jochen
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Antonio Gomes]

Hi Sam. Some comments below.

Cheers,

--Antonio

>> Curious about this myself, I just reviewed a patch only affecting the
>> GTK-specific parts of WebKit2, I believe that is OK? Should we ammend
>> the Owners file to include information about port-specific directories
>> and reviewers?
>>
>> Cheers,
>
> At this point, we ask that all completely non-trivial patches be reviewed by 
> an owner, even if in port specific code.

First, I would like to say that I understand the frustration you guys
might have faced by not being able to move Core WebKit2 development at
the speed you guys think you could go due to other WebKit2 ports. That
is indeed not the goal of the project, and likely the first time the
project has seen it at this scale (correct if I am wrong, please).
Further, although I do not fully support the direction pointed out as
the solution to this problem, I have to agree that it might work.

However, I am wondering if the new Core WK2 owners would really feel
comfortable in reviewing Qt, Gtk and EFL specific WK2 patches - given
that they are likely unfamiliar with the code. Does not it go against
the primary *rule* of the WebKit reviewership process, where a
reviewer is only allowed to R+ a patch he/she fully understands?

If we had a concept of a super-review instead, like Firefox, where
owners sometimes rubber stamp patches even when they do not have the
know-how to reliably review it, given that the patch has got an r+ of
someone else that actually does.

Maybe your last email was that one that actually "scared" me.

Looking forward for you reply,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] MS Open Tech - Initial Prototype of Pointer Events

[Antonio Gomes]

Please read this:
http://lists.webkit.org/pipermail/webkit-dev/2012-November/022949.html
On Dec 19, 2012 4:45 AM, "Kenneth Rohde Christiansen" <
kenneth.christian...@gmail.com> wrote:

> Hi there,
>
> First of all I want to say that it is great that Microsoft are
> contributing towards WebKit and I want to congratulating you with the
> new MS Open Tech organization.
>
> The best way to provide feedback on a spec like this is through the
> W3C, and the best way to provide feedback on the code itself is
> through a patch on WebKit bugzilla. Our web site explains very well
> how to contribute code to WebKit and you should have a look. When
> adding new features we usually announce it on webkit-dev to see if
> people are generally interested in the feature. I would say that you
> have already done so with this email. Whether people are interested or
> not, I would suggest creating a bug and uploading your code so that
> anyone interested can give you some initial feedback on your work so
> far.
>
> Good luck and welcome
>
> Kenneth
>
> On Wed, Dec 19, 2012 at 2:07 AM, Scott Blomquist (MS OPEN TECH)
>  wrote:
> > We are part of the engineering team of Microsoft Open Technologies, Inc.
> (MS Open Tech, a Microsoft subsidiary; see our initial announcement at
> http://aka.ms/introMSOpenTech). We have developed an initial proof of
> concept of a WebKit implementation of the Pointer Events W3C Working Draft (
> http://www.w3.org/TR/pointerevents/). It is based on a proposal that
> Microsoft initially submitted to the W3C. You can find more details in our
> blog post at http://aka.ms/PointerEventsWebkitPrototypeBlog.
> >
> > Right now, this is only a very early proof of concept that implements
> selected mouse and touch events. You can find the code as a WebKit patch on
> our HTML5 Labs website here: http://aka.ms/PointerEventsWebkitPrototype.
> We would love to have some feedback on the code, work with the WebKit
> community on a complete implementation of whatever final spec will be
> defined by the W3C Pointer Events WG and if the community is interested in
> our contribution get some advice on how/when to submit this patch to the
> main WebKit trunk.
> >
> > (For those wondering why we are doing this, we are obviously interested
> in moving forward existing and new input types on the open web and, as the
> spec evolves, maintain interoperability between WebKit and Internet
> Explorer.)
> >
> > --
> > Scott Blomquist
> > Senior Development Engineer
> > Microsoft Open Technologies, Inc.
> > A subsidiary of Microsoft Corporation
> >
> > Adalberto Foresti
> > Principal Program Manager
> > Microsoft Open Technologies, Inc.
> > A subsidiary of Microsoft Corporation
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> --
> Kenneth Rohde Christiansen
> Senior Engineer, WebKit, Qt, EFL, Intel Corporation
> Phone  +45 4093 0598 / E-mail kenneth at webkit.org
>
> ﹆﹆﹆
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Chromium for Android upstreaming has been completed!

[Antonio Gomes]

Nothing but awesome work, guys! Congrats.

On Tue, Nov 6, 2012 at 1:56 PM, Peter Beverloo  wrote:

> Hi WebKit!
>
> Following Adam’s progress update on the Chromium-Android port in July[1],
> we’re happy to tell you that our upstreaming has been completed and that
> the Chromium-Android port is now fully supported. We’ve closed the master
> bug:
> https://bugs.webkit.org/show_bug.cgi?id=66687
>
> To give you a quick summary:
> * Chromium for Android builds upon the existing Chromium architecture,
> code and port.
> * Build bots are available on the WebKit waterfall, with layout tests
> being run on actual devices.
> * There are EWS bots building all patches as they’re being uploaded to
> Bugzilla.
>
> Of course there are more loose ends to address, but we expect to finish
> these not too long from now. Most notably, a Performance bot will be added
> to the WebKit waterfall and all tools, including garden-o-matic, will be
> brought up to speed for Android.
>
> Once again, huge thanks to the WebKit community for being supportive and
> helping us out not just on upstreaming, but also in development of features
> such as Text Autosizing[2].
>
> Cheers,
> Peter and Adam
>
> [1] http://lists.webkit.org/pipermail/webkit-dev/2012-July/021516.html
> [2] https://bugs.webkit.org/show_bug.cgi?id=84186
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>


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

Re: [webkit-dev] New WebKit Reviewer: Caio Marcelo de Oliveira Filho

[Antonio Gomes]

Parabéns, Caio! :-)

On Mon, Oct 8, 2012 at 10:32 PM, Zoltan Horvath  wrote:

>
> Cool! Congratulations Caio!
>
> On Mon, Oct 8, 2012 at 2:20 PM,  wrote:
>
>> I am pleased to announce that Caio (@cmarcelo) is now a WebKit reviewer.
>> Caio has been working in many areas in the past years, starting with
>> focus on the Qt port with improvements to the Qt/JS bridge, font test
>> results and render-theme.
>> More recently has also work on the UndoManager and other aspects of
>> editing code and CSS parsing, his latest contributions being around WTF
>> HashMap iterators.
>> Since Caio has been involved in so many parts of WebKit, I'm probably
>> forgetting a few other contributions...
>>
>> Please join me in congratulating Caio for his new reviewer status!
>> No'am
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>
> _______
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>


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

Re: [webkit-dev] Chromium for Android builders have been added to the EWS

[Antonio Gomes]

Nice work. I assume your upstreaming is done.

On Fri, Aug 10, 2012 at 6:47 AM, Kenneth Rohde Christiansen <
kenneth.christian...@gmail.com> wrote:

> Nice to hear and congratulation with getting so far!
>
> I am very happy that you are aiming at having a working mobile port in
> trunk; similar goals that we have for the Qt port.
>
>
Same for the BlackBerry port.

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

Re: [webkit-dev] can we stop using Skipped files?

[Antonio Gomes]

> Untested code is inherently harder to maintain in my experience. Most of
> the time, committing untested code is just implanting technical debt that
> someone will have to pay later.
>
>
I think the above, by its own, summarizes what people advocating in favor
of tests (for any area of the project, and tooling is not an exception) are
arguing for.

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

Re: [webkit-dev] EFL Debug Buildbot Green

[Antonio Gomes]

Amazing work, guys!

On Thu, May 10, 2012 at 3:04 PM, Dirk Pranke  wrote:

> +1 :).
>
> On Thu, May 10, 2012 at 12:01 PM, Ojan Vafai  wrote:
> > That's a great milestone. Congratulations!
> >
> > On Thu, May 10, 2012 at 8:43 AM, Dominik Röttsches
> >  wrote:
> >>
> >> Hi all,
> >>
> >> We're happy to share with you that yesterday the EFL Linux Debug
> Buildbot
> >> has turned green for the first time.
> >> http://build.webkit.org/builders/EFL%20Linux%20Debug
> >>
> >> This has been an example of a great team effort [1]. We'd like to thank
> >> the friendly reviewers and committers who helped us for their support!
> >>
> >> We'll keep a close eye on our buildbot lamp http://goo.gl/ei1gL from
> now
> >> and set up a gardening schedule to keep it green and tidy in the future.
> >>
> >> Dominik
> >>
> >> [1] http://wkb.ug/85601
> >>
> >> --
> >> Dominik Röttsches 
> >>
> >>
> >> ___
> >> 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
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] Moving to Git?

[Antonio Gomes]

Hi Geoff. I might have missed your point. Who is trying to force you to
change something?

I would love to understand the "other side" for sure...

On Thu, Mar 8, 2012 at 3:20 PM, Geoffrey Garen  wrote:

> IMO, none of the arguments used here so far seem like a real problem for a
> switch. Of course, SVN people would have to adapt their workflow and it
> could take days (no more than that, trust me), but it is for a greater goal
> at the end.
>
>
> This is an example of what I mean by "fiat":
>
> Step 1: Force a change upon people
> Step 2: …
> Step 3: A greater good is achieved
>
> Geoff
>



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

Re: [webkit-dev] Moving to Git?

[Antonio Gomes]

(For those valuable contributors who are against Git and have manifested
somehow here, please do not take it personally)

IMO, none of the arguments used here so far seem like a real problem for a
switch. Of course, SVN people would have to adapt their workflow and it
could take days (no more than that, trust me), but it is for a greater goal
at the end.

In my opinion, SVN concepts are completely obsolete these days. It is hard
to me to even hear someone arguing in favor of SVN against GIT, but I
respect anyone's opinion. I just do not feel them strong enough given the
whole context.

On Thu, Mar 8, 2012 at 3:05 PM, Joe Mason  wrote:

> It seems to me that there's no need to use multiple local branches in git
> if you find it confusing - it's an additional feature, but I don't see
> anything that requires it.
>
> What workflow do you have that requires you to have multiple branches
> locally in git, and how do you solve it in svn without using branches?
>
> What precisely do you find difficult about merging remote changes, and how
> is the svn equivalent easier?
> 
> From: webkit-dev-boun...@lists.webkit.org [
> webkit-dev-boun...@lists.webkit.org] on behalf of Ryosuke Niwa [
> rn...@webkit.org]
> Sent: Thursday, March 08, 2012 3:00 PM
> To: Ashod Nakashian
> Cc: WebKit Development
> Subject: Re: [webkit-dev] Moving to Git?
>
> On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian  <mailto:ashodnakash...@yahoo.com>> wrote:
> >And that's a show stopper for me. For build bot maintenance, regression
> fixes, etc... being able to easily tell the number of commits between two
> revisions (in my head as opposed to using a tool) or the ordering of
> commits is crucial.
>
> I think this is an interesting point. It seems there are two solutions. We
> can enforce fast-forward as many have pointed out and we can maintain an
> SVN mirror. Although I don't like the idea of maintaining an SVN repo, and
> it's almost universally agreed that git offers superior tools to SVN.
>
> I don't think so. I like the simplicity of svn. While git client works
> great, I always get frustrated by the complexity of having multiple
> branches locally and the amount of work required to merge the remote
> changes on the branch I'm working on.
>
> - Ryosuke
>
>
> -
> 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
>



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

[webkit-dev] Bugzilla request

[Antonio Gomes]

Hi all,

I would like to request a "WebKit / BlackBerry" new component in
bugs.webkit.org, as well as a 'blackberry' keyword. Could we please get
help from the bugzilla maintainers to get them set up?

Thanks in advance.

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

Re: [webkit-dev] Users of PlatformGestureRecognizer?

[Antonio Gomes]

I remember it being added, and yes I think it is not being used by any
upstream port.

What is chromium using instead now, btw? :-)

On Mon, Jan 30, 2012 at 5:41 PM, Adam Barth  wrote:

> On Mon, Jan 30, 2012 at 2:35 PM, Robert Kroeger 
> wrote:
> > As best as I can tell, only Chromium uses PlatformGestureRecognizer
> > and its Chromium-specific implementation. Since Chromium no longer
> > needs the code, would anybody object if I removed it?
>
> If it's used only by Chromium, then it seems safe to remove if
> Chromium no longer plans to use it.
>
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] Question regarding rebaseline for Layout Test Result for EFL port

[Antonio Gomes]

I would say GTK's way is pretty acceptable in this case.

On Mon, Jan 16, 2012 at 3:21 AM, Gyuyoung Kim wrote:

> Hello WebKit folks.
>
> It looks that the result of layout test for EFL port needs rebaseline
> because of 101343. The revision modified line spacing of font in
> SimpleFontDataFreeType.cpp, and it seems that the existing layout test
> result of EFL port was influenced by it. (
> http://trac.webkit.org/changeset/101343)
>
> 3,936 test cases are failed after the revision (101343).
>* EFL port's layout test result with r101343
>  => Results: 16139/27915 tests passed (57.8%)
>  => Tests to be fixed (11776):
>4423 text diff mismatch   (37.6%)
>9 image mismatch   ( 0.1%)
>7344 skipped  (62.4%)
>
>* EFL port's layout test Result without r101343
>  => Results: 20074/27915 tests passed (71.9%)
>  => Tests to be fixed (7841):
>1 test timed out   ( 0.0%)
>487 text diff mismatch   ( 6.2%)
>9 image mismatch   ( 0.1%)
>7344 skipped  (93.7%)
>
> It looks GTK port also did rebaseline due to the revision.
>  - http://trac.webkit.org/changeset/101354
>  - http://trac.webkit.org/changeset/101352
>  - http://trac.webkit.org/changeset/101351
>  - And so on.
>
> I think EFL port also needs to do rebaseline for layout test result. GTK
> port did rebaseline without review because patch is too huge. Is there any
> processes for rebaseline ?
>
> - gyuyoung
> _______
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] The Purpose of Core Builders

[Antonio Gomes]

What makes Brent's statement even more understanable is that since the last
three weeks I've been waiting for a "green" state on at least a few bots to
land a test, and it simply has not happened. All bots, including Apple's
and Chromium's have been red for a while, and a "green state" spot seems
like an exception in this meanwhile.

The bot that has been mostly green lately is Qt's (due to the hard work of
Ossy and his crew).

On Tue, Nov 8, 2011 at 8:09 PM, Brent Fulgham  wrote:

> A week or two ago, Adam Barth elected to remove my WinCairo build bot
> from the list of core builders. In the check-in comment, he noted that
> the WinCairo bot rarely built, and was never green.
>
> I do not agree with either of these statements -- the WinCairo build
> bot had been green for a number of weeks after I activated tests
> (instead of just building), and the bot generally builds properly (and
> has done so for the past couple of years).
>
> I admit to being lax in keeping the bot green over the past few weeks,
> which was an unusual case due to external factors. I generally attempt
> to maintain the bot every day, but was not able to keep close tabs on
> it for most of October.
>
> The build failures (which I fixed this afternoon) took all of five
> minutes to correct, and were due to additions to symbol export files
> that were not applied to the WinCairo version of these files. Surely
> these small errors could have been corrected by the committer -- which
> is surely the point of the build bots?
>
> While I understand that a Red bot is annoying, I feel that removing
> the bot simply masked the problem.
>
> At the very least, I would hope that in the future that the build bot
> owners should be notified if a third party makes the arbitrary
> decision to remove a bot from the core set. The information is clearly
> provided in the build bot configuration page.
>
> Thanks,
>
> -Brent
> _______
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] NRWT Migration Update

[Antonio Gomes]

Hi Eric.

So does it it mean that any "being upstream'ed" port which was also
providing a ORWT based bot, should actually switch to NRWT instead?

Cheers,

On Thu, Oct 20, 2011 at 12:59 AM, Eric Seidel  wrote:

> After a long hiatus, I'm back working on NRWT.
>
> As of this evening all of the blocking issues to switching the WK2 bot
> are resolved:
> https://bugs.webkit.org/show_bug.cgi?id=56729
>
> Just waiting for the WK2 bot to have some smaller number of failures,
> then I'll pull the trigger.
>
>
> After WK2 is switched to NRWT, there is only --leaks and Windows to
> switch, before we can consider deleting ORWT.
>
> Interested parties can continue to track the NRWT migration here:
> https://bugs.webkit.org/show_bug.cgi?id=34984
>
> -eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] NeedHelp_In_SpatialNavigation

[Antonio Gomes]

Hi

1) When we use spatial navigation, to find the nearest node it traverse DOM
> tree, is that node information can not be retrieved from render tree?
>
>
As per my understanding render tree (after layout) will have the position
> information for each node.
>

Code tranverses the DOM, yes, but it gets the position information from the
associated node renderer. So it gets it from the RenderTree.

So is there any way we can get the nodes information of any particular area.
>

Not sure if I understood you here. Could you  elaborate?

2) If from render tree we can get the nodes according to position then we
> can skip the traversing of whole DOM tree.
>

If the RenderTree can tell us what elements in the DOM tree are 'focusable'
(which I do not think it can), yes.


>
> 3) Is Spatial navigation is related to Hit testing?
>

Not at the moment.


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

Re: [webkit-dev] NeedHelp_In_SpatialNavigation

[Antonio Gomes]

Hi.

As far as I can tell, the whole DOM is traversed every time a movement is
going to happen. I've discussed with Yael briefly on the WebKit summit about
some cache mechanisms, but we could not get a nice heuristic to invalidate
the cache.

Have you profiled it?

On Mon, Oct 17, 2011 at 7:29 AM, Sanjeet Pratap Singh <
sanjeetpratapsi...@gmail.com> wrote:

> Hi All,
> I am a beginner to WebKit, looking into "*Spatial-Navigation*" feature of
> WebKit.
> I am looking further for some optimisations in the same.
>
> I find there "*findFocusCandidateInContainer() "* in which we start
> from first child of "container" and iterate until the we get the focus
> candidate.
>
> My question is,"Are we checking the whole DOM tree to find the closest node
> or we have a small area(container) accordingly?"
>
> What does the function*
> "container=scrollableEnclosingBoxOrParentFrameForNodeInDirection()"* do?
>
>
>
> Waiting for the reply.
>
> Thanks & Regards,
> Sanjeet
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


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

Re: [webkit-dev] Adding "Scroll Padding" to allow scroll beyond the edge of the page (within some bounds)

[Antonio Gomes]

>From what I tested on iOS5 Mobo Safari, it also overscroll's the
overflow:scroll case (generally div's).

On Thu, Oct 6, 2011 at 1:47 PM, Fady Samuel  wrote:

> Hi Anders,
>
> At this point in time, we see no reason to allow for non-zero padding in
> overflow:scroll regions because you can always just move the page into a
> unobstructed area and then scroll through that overflow region.
>
> Thanks,
>
> Fady
>
>
> On Thu, Oct 6, 2011 at 1:43 PM, Anders Carlsson wrote:
>
>> Do you envision this being useful on overflow:scroll regions as well or is
>> it just frames? If it's just frames, then it seems like something we could
>> keep in ScrollView? (I haven't looked at the patch yet).
>>
>> - Anders
>>
>> On Oct 6, 2011, at 10:41 AM, Fady Samuel wrote:
>>
>> Hi Anders,
>>
>> Thanks for your reply.
>>
>> Yes, you are correct. This padding would be between the content and the
>> overhang area.
>>
>> Thanks,
>>
>> Fady
>>
>> On Thu, Oct 6, 2011 at 1:32 PM, Anders Carlsson wrote:
>>
>>> Hi Fady,
>>>
>>> so if I'm understanding correctly, in the context of rubber-band
>>> scrolling, this padding would be between the content and the overhang area?
>>>
>>> As far as constrainsScrollingToContentEdge goes, I'd like to get rid of
>>> it and just have two scroll functions, one that constrains to the content
>>> edge and one that doesn't.
>>>
>>> - Anders
>>>
>>> On Oct 6, 2011, at 10:03 AM, Fady Samuel wrote:
>>>
>>> Hi all,
>>>
>>> We'd like to provide a general mechanism in WebKit for embedders to
>>> scroll page content so that it is not hidden by embedder-provided UI
>>> elements that overlap the page.
>>>
>>> In some cases, if a floating UI element overlaps the edge of the page,
>>> we'd like to allow the embedder to scroll beyond the edge of the page to
>>> allow the hidden content to move to an area that isn't overlapped by UI
>>> elements. This feature is orthogonal to rubber band scrolling.
>>>
>>> One approach we considered taking is to allow the platform to set "scroll
>>> padding" to a FrameView/ScrollableArea to allow scrolling beyond the edge of
>>> the page.
>>>
>>> As a more concrete example, one can imagine a persistent Chromium
>>> extension that floats above the edge of the page. A link may lie behind the
>>> floating window.  That link would be inaccessible unless the page is allowed
>>> to scroll beyond its edge.
>>>
>>> An experimental and incomplete implementation of this idea can be found
>>> here: https://bugs.webkit.org/show_bug.cgi?id=68184
>>>
>>> After some additional consideration since this patch was posted, I don't
>>> believe scroll padding should interact with
>>> ScrollView::constrainsScrollingToContentEdge the way it does in the patch.
>>> Instead, I feel that scroll padding should be ignored
>>> if constrainsScrollingToContentEdge is false. That way rubber band scrolling
>>> is not affected at all by this.
>>>
>>> What are your thoughts and suggestions? Is this feature sufficiently
>>> general to be implemented in WebCore? What are your thoughts about its
>>> interaction with ScrollView::constrainsScrollingToContentEdge?
>>>
>>> Thanks,
>>> Fady
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>>
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


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

Re: [webkit-dev] Enable -webkit-tap-highlight-color on all ports which support TOUCH_EVENTS?

[Antonio Gomes]

What we have to be careful here is to the fact that it is not a standand
yet.

I know upcoming versions of the BlackBerry browser will make use of it, and
that Nokia's N9 likely supports it already (kenneth or qt friends, please
confirm). Also, iirc I remember Mozilla Mobile (aka Fennec) might have added
support to this property.

So what we need to be sure as well is that at some point it will be worked
on making it a standand. Usually UAs implement specs, but sometimes specs
write up UA features when it is relevant.

On Wed, Sep 28, 2011 at 11:22 AM, Johnny Ding  wrote:

> Hi Folks,
>
> You may know the css property "-webkit-tap-highlight-color" which is now
> only supported by Safari on iOS. (Please see 
> here<http://developer.apple.com/library/safari/#documentation/appleapplications/reference/SafariCSSRef/Articles/StandardCSSProperties.html>
>  for
> the details.)
> Now I am working on enabling it for all WebKit ports which support
> TOUCH_EVENTS. This css property (not standard yet) benefits the web
> developers who want to change the tap highlight color to fit their
> websites/webapps.
> Please go to https://bugs.webkit.org/show_bug.cgi?id=48544 for the
> details.  Suggestions and comments are definitely welcome.
>
> Thanks!
> --
> Best Regards.
> Johnny
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


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

Re: [webkit-dev] On touch based device touch/click response looks a bit flaky

[Antonio Gomes]

See this discussion long
http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11533.html

For now it is very port specific to adjust the clicking spot before
submitting it to webcore. We should/could generalize it though for all ports
would share the logic.

On Friday, September 16, 2011, Arko Saha  wrote:
> Hi,
> My observation is "on touch based device touch/click response looks a bit
flaky"(if we put a plain webkit build on the touch device, say GTK port).
> Some time we want to click a smaller link without doing zoom-in the
webpage on touched based device. In this situation the hit test does not
return a clickable node hence the click does not work(some times trigger the
click event to a wrong link which we can not fix) , but user feels that he
already clicked and device is not responding. Does any body has some thought
on improving this responsiveness , say ex. "by having multiple hit test on
surrounding area to find the nearest clickable element,if hit test fails
first time."
> Also I have checked on FireFox plugin which does similar thing with some
magic numbers. here is the link for the same:
> https://addons.mozilla.org/en-US/firefox/addon/lazy-click/
> Any Thoughts/Suggestions.
> Thanks in advance.
> Arko Saha
>

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

Re: [webkit-dev] A Media Element ie: or , without tabindex cannot be selected with keyboard (TAB Key). BUG: 67190

[Antonio Gomes]

> > What would script see as focused if we allow subcontrols be focusable?
>
> Since controls are part of shadow DOM, scripts wont be able to see
> that. In this case then they would probably end up with respective
> media element.
>
>
Well, then that should be layout tested as well.

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

Re: [webkit-dev] Do you maintain OS(WINCE)?

[Antonio Gomes]

I believe it was maintained by Torch Mobile, and, according to George
Staikos, it is not part of the plans any more (Torch was acquired by RIM).

Not sure of others using it though. If no one speak up, I would say it is
safe to remove at this point.

Cheers,

On Mon, Sep 12, 2011 at 7:46 PM, Geoffrey Garen  wrote:

> Hi folks.
>
> It looks like another build variant that relies on threads not existing in
> WebKit and JavaScriptCore is OS(WINCE).
>
> Do you maintain OS(WINCE)? If so, are you interested in implemented
> JavaScriptCore threading primitives for it?
>
> If nobody maintains OS(WINCE), I'm inclined to remove it in a follow-up
> patch.
>
> Thanks,
> Geoff
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] how about nav-up, nav-right, nav-down, nav-left in CSS3-ui ?

[Antonio Gomes]

It sounds like a interesting idea.  Some questions:

- Is there any other vendor implementing it?
- How is it better than a good Spatial Navigation implementation (like
webkit's or opera's)? I see that it makes it possible to limit which
elements in the page are actually css-directionally-focusable...


On Tue, Aug 9, 2011 at 9:18 PM, Ra Kyounga  wrote:

> Hi, CSS developers.
>
> I'm wondering if anyone is trying to implement new css properties for
> directional focus navgation. (nav-up, nav-right, nav-down, nav-left)
> They are defined in CSS3-ui module.
> http://www.w3.org/TR/css3-ui/#nav-dir
>
> Although, CSS3-UI standards has not been updated for long time,
> if there is no one to be addressed, I'd like to start to implement this
> feature.
>
> I think we can re-use the function for a fragment link.
>
> How about my idea?
> or Is it better just to start implementation through bugs.webkit.org than
> e-mail communication?
>
> Well, you should file a bug anyways, imo :).

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

Re: [webkit-dev] Extra review requirement for web-facing API? (Was: Re: Spellcheck API for WebKit)

[Antonio Gomes]

> On Wed, Jun 22, 2011 at 11:41 AM, Dimitri Glazkov 
>  wrote:
>
>> To prevent this from happening again, we should remind everyone to:
>>
>> 1) Only review things they are comfortable with;
>> 2) Seek WebKit elder's review for public-facing APIs
>>
>> I don't think we need an explicit two-level review policy. If
>> anything, we need super-reviewers instead.
>
>
> I'm supportive of super-reviewers idea.
>
>
I suport the super review process too for Web facing API addition, including
new css properties and friends. BUT conditionally to the extra level of
reviewing being exclusive for such cases. For other cases, looking for a
reviewer that domains this code is still the best thing to do.


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

Re: [webkit-dev] review flags (was bugs in pending-commit)

[Antonio Gomes]

Personally, I like this pattern a lot.

Would it also be helpful when sheriff bot rolls out a patch to attach the
rolled out patch with a nice description like ROLLOUT(rX) to the bug?

On Sun, Jun 19, 2011 at 8:36 PM, Eric Seidel  wrote:

> On Sun, Jun 19, 2011 at 11:31 AM, Darin Adler  wrote:
> > On Jun 18, 2011, at 9:01 PM, Antonio Gomes wrote:
> >
> >> I actually do not like the way the review flags are cleared today only
> in order to make the tools and pending-xxx pages happier. IMO the review
> flags give much about the history of the bug. In that matter, I dislike
> webkit-patch's ways of clearing "r-" flags of patches while it marks it as
> obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very
> helpful to me to understand the chronological progresses in the bug.
> >
> > I agree that it would be clearer to leave review flags for clarity about
> the history of a patch. I also have been irritated by our work flow that
> involves clearing review flags to appease the tools.
> >
> > However, even if we fixed everything so that was no longer necessary, I
> would still want a way to clearly communicate “this patch is known to be bad
> and not suitable for landing, despite the fact that a reviewer approved it
> at one point”.
> >
> > And I also think that if we were redesigning the bug system it would be
> good if there was a way to communicate that a patch was landed other than
> having a bug marked RESOLVED, because people continue to put multiple
> patches in a single bug, and so the bugs state can’t really tell us the
> status of a patch.
>
> I'm happy to change webkit-patch to change the descriptions on patches
> to prefix "LANDED(r12354):" when landing/obsoleting, etc. if you think
> that would help.
>
> -eric
>
> >-- Darin
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] review flags (was bugs in pending-commit)

[Antonio Gomes]

Hi Darin. Few comments inlined.

On Sun, Jun 19, 2011 at 2:31 PM, Darin Adler  wrote:

> On Jun 18, 2011, at 9:01 PM, Antonio Gomes wrote:
>
> > I actually do not like the way the review flags are cleared today only in
> order to make the tools and pending-xxx pages happier. IMO the review flags
> give much about the history of the bug. In that matter, I dislike
> webkit-patch's ways of clearing "r-" flags of patches while it marks it as
> obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very
> helpful to me to understand the chronological progresses in the bug.
>
> I agree that it would be clearer to leave review flags for clarity about
> the history of a patch. I also have been irritated by our work flow that
> involves clearing review flags to appease the tools.
>

I agree.


> However, even if we fixed everything so that was no longer necessary, I
> would still want a way to clearly communicate “this patch is known to be bad
> and not suitable for landing, despite the fact that a reviewer approved it
> at one point”.
>
>
And I also think that if we were redesigning the bug system it would be good
> if there was a way to communicate that a patch was landed other than having
> a bug marked RESOLVED, because people continue to put multiple patches in a
> single bug, and so the bugs state can’t really tell us the status of a
> patch.
>

See what I do myself in patches in bug
https://bugs.webkit.org/show_bug.cgi?id=50666 , for example. We could/should
teach toosl to do that.

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

Re: [webkit-dev] 194 bugs in pending-commit

[Antonio Gomes]

IIRC, Mozilla's bugzilla can "hide" obsolete patches (?). If so, why can not
webkit's bugzilla?

I actually do not like the way the review flags are cleared today only in
order to make the tools and pending-xxx pages happier. IMO the review flags
give much about the history of the bug. In that matter, I dislike
webkit-patch's ways of clearing "r-" flags of patches while it marks it as
obsolete and uploads a new one. Reason: an easy-to-see r-'ed patch is very
helpful to me to understand the chronological progresses in the bug.

What is the reason for clearing r- flag while uploading a new one, instead
of only making it obsolete?

On Sat, Jun 18, 2011 at 2:23 AM, Adam Barth  wrote:

> On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting 
> wrote:
> > On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth  wrote:
> >> 2) Mark the patch as obsolete / clear the review flag if we're not
> >> going to land the patch.
> >
> > Does the slash mean "do both"?  I
> > have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and the
> only
> > r+ed patch on it is already marked obsolete.
>
> Yeah, Bugzilla kind of sucks.  That page isn't smart enough to hide
> the obsolete patches.  If you have EditBugs, you can run "webkit-patch
> clean-pending-commit", which will automatically remove the review
> flags from obsolete patches.  Eric and I have been meaning to having
> one of the bots do that periodically, but we haven't set that up yet.
>
> Adam
> _______
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] Expected behavior of "scrolling" attribute for IFrame element

[Antonio Gomes]

One code path to scroll is through ScrollbarClient inheritance (see
RenderLayer). So it relies on scrollbars code.

On Tuesday, June 14, 2011, Mustafizur Rahaman  wrote:
> The real problem to fix would be not have scrolling tied to having or not 
> scrollbars, as I see it.
>
>
> Antonio, Do you mean we should scroll depending on the content size 
> irrespective of whether the scrollbar is shown or not.If so, that is the 
> current behavior anyway.
>
> The other way I was thinking (not sure whether this is possible) if my 
> content size is larger (i.e. i need scrolling ), i should ignore the 
> "scrolling" attribute & show the scrollbar (this needs a change in the spec 
> as well). Will this behavior have any side effect?
>
> Thanks,
> Rahaman
>
> On Tue, Jun 14, 2011 at 12:01 AM, Antonio Gomes  wrote:
>
>
>
>
> overflow:hidden divs are used to implement custom scrollbars.
> That, by itself sounds likea hack :)
>
>
>
> While find-in-page breaking wouldn't be too bad, breaking autoscrolling on 
> these sites would likely require us to rollback the change. Maybe we should 
> expose an attribute or CSS property to allow controlling this to give sites a 
> workaround?
>
>
> The real problem to fix would be not have scrolling tied to having or not 
> scrollbars, as I see it.
>
> --Antonio Gomes
>
>
> _______
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>

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

Re: [webkit-dev] Expected behavior of "scrolling" attribute for IFrame element

[Antonio Gomes]

> overflow:hidden divs are used to implement custom scrollbars.
>

That, by itself sounds likea hack :)


> While find-in-page breaking wouldn't be too bad, breaking autoscrolling on
> these sites would likely require us to rollback the change. Maybe we should
> expose an attribute or CSS property to allow controlling this to give sites
> a workaround?
>
>
The real problem to fix would be not have scrolling tied to having or not
scrollbars, as I see it.

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

Re: [webkit-dev] Expected behavior of "scrolling" attribute for IFrame element

[Antonio Gomes]

Hi.

What does happen on other browsers? I know firefox does not scroll it (just
tested), but maybe Opera and IE are good to be tested too.

Particularly speaking, I do not think it should scroll. Btw, it is a similar
case to if user uses the find-in-page feature, and the word is offscreen the
scrolling=no iframe. But it is a valid discussion, I think ...

On Mon, Jun 13, 2011 at 7:18 AM, Mustafizur Rahaman
wrote:

> Hi,
>
> As per w3cschools (http://www.w3schools.com/tags/att_iframe_scrolling.asp), 
> the scrolling attribute of an iFrame element is expected to behave as per
> following
> Attribute Values Value Description  auto Scrollbars appear if needed (this
> is default)  yes Scrollbars are always shown (even if they are not needed)
> no Scrollbars are never shown (even if they are needed)
> My question is: When scrolling="no" & still if scroll bar is needed (i.e.
> if the content is larger than the iframe.), what would happen if i drag the
> content inside the iFrame? Will the iFrame content be scrolled OR would it
> not allow the user to scroll?
>
> This is w.r.t. https://bugs.webkit.org/show_bug.cgi?id=61558 that I am
> currently investigating.
>
> Thanks,
> Rahaman
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


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

Re: [webkit-dev] Cherry-Pick Bug Comments

[Antonio Gomes]

> An important question: besides the notification e-mails, does the rest of
> our release process bothers someone?
>
> Not me. It works fine and is very transparent.


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

Re: [webkit-dev] Cherry-Pick Bug Comments

[Antonio Gomes]

Use-case: years from now someone finds a particular bug report on

> bugzilla. It's useful for them to know that it was fixed in
> QtWebKit-2.2.
>
>
Well, comment could go to the meta bug? Or maybe your cherry-pick reports
would be google'able, as you said below.


> To know the list of bug(fix) included in a particular version of
> QtWebKit, I parse git-log and generate weekly reports, which are sent
> to the announcement mailing list and published on the wiki when a
> final release is made. See
> http://lists.qt.nokia.com/pipermail/qtwebkit-announce/2011-May/03.html
> and http://trac.webkit.org/wiki/QtWebKitRelease21 for example.
>
> I review commits from the trunk looking for critical fixes and
> cherry-pick them directly to our stable branch(es), avoiding the
> block/unblock of our meta-bugs (otherwise you would get one more
> e-mail) :-)
>
>
The real problem is that bugzilla is not made for less-simple release
processes like this. Well, at least not the bugzilla webkit uses now. I know
Mozilla's bugzilla has a bunch of "block-release-xx -, +, ?" fields, or
'whiteboard' field so that people add useful general information to the bug,
and they make it much less noisy. However, it is one product, one company,
and on interest (in general), which it Firefox. See this one, for example:
https://bugzilla.mozilla.org/show_bug.cgi?id=563548 ... WebKit is different
and definitively would need a different approach.

Good that we all agree that it is really not ideal as it is now. Not sure
how Apple's internal bugtracking work on that matter, but  there is the
'InRandar' keyword. Maybe Qt could get something similar and JIRA could be
used for tracking progresses on QtWebKit releases?

Well, as I said, it is not an easy problem :).

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

Re: [webkit-dev] Cherry-Pick Bug Comments

[Antonio Gomes]

We had this exactly discussion in qtwebkit mailing list days ago:
https://lists.webkit.org/pipermail/webkit-qt/2011-May/001555.html . It is
worth reading through if you are interested in this topic!

We would really like to reduce the noise of "management bugmails", but
without a clear good solution for now yet. The "silent" comments suggested
by Evan would be a great alternative to the problem if bugzilla could get
expanded to support it, imo...


On Thu, May 26, 2011 at 7:05 PM, Evan Martin  wrote:

> On Thu, May 26, 2011 at 3:54 PM, Eric Seidel  wrote:
> > I get a lot of these:
> > Revision r86028 cherry-picked into qtwebkit-2.2 with commit 7e1bab1
> > <http://gitorious.org/webkit/qtwebkit/commit/7e1bab1>
> > as bug mail.  Probably because I'm CC'd on a zillion bugs (and actually
> read
> > my bug mail).
> >
> > This is probably the pot calling the kettle black, since I wrote many of
> the
> > bots which comment daily on bugs...
> > ...but, I'm wondering if we can do better?
> > Would it better serve the cherry-picker's needs if we instead had a
> separate
> > server to track revision -> cherry-picks?  Or bug ids -> cherry-picks?
> (Like
> > how the EWS bots store their status on queues.webkit.org and display it
> in
> > little bubbles on bugs.webkit.org w/o commenting on the bugs.)
> >
> > I'm strongly supportive of all clients of webkit storing all of their
> > bug-related data in bugs.webkit.org.  It's better than the alternative
> (lots
> > of data buried in old Radars, or Chromium bugs, etc.)
> > But perhaps someone has a good idea how to reduce unnecessary bugmail?
>
> I've seen some bug trackers reduce email by allowing you to comment
> without sending email.  In effect you're just attaching metadata to
> the bug without notifying everyone about it.
>
> However, the comments left by the EWS are intended for the bug authors
> and so they probably should continue sending mail.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] Font Name

[Antonio Gomes]

This should go to webkit.org/articles :)

On Sat, May 21, 2011 at 1:55 PM, Mustafizur Rahaman
wrote:

> Hi,
>
> When you are drawing  some text, you create a RenderText(RenderObject)
> which has all the rendering info & the m_style of RenderText has the style
> info required to render the text.
>
> Let's consider the following style data I have in my html page
> 
> body.rahaman{
> font:30px courier;
> }
> 
>  Rahaman 
>
> Once the HTMLTreeBuilder parses the token, it creates HTMLStyleElement &
> CSSStyleSheet & then asks the CSSParser to parse the StyleSheet. From there
> it comes to CSSParser::parseValue()=>CSSParser::parseFont() as the I have
> only used font property
>
> We create a FontValue (which contain all the attribute a font property can
> have like style, size, variant, family etc=> in this font_family, you can
> actually see the font name you have used ). In CSSParser::parseFont, we
> populate the FontValue structure (you can find the font family name in
> font->family), calls CSSParser::addProperty() where we create a CSSProperty
> with the FontValue/CSSValue being passed & this property is being stored in
> CSSParser::m_parsedProperties.
>
> Then we call CSSParser::createStyleRule where we used the
> m_parsedProperties mentioned before to create a CSSMutableStyleDeclaration &
> set this declaration for the CSSRule.
>
> We then create CSSStyleSelector and call CSSStyleSelector::styleForElement
> for the root element. Here somehow (I don't have much details what happens
> in berween but figured out that we retrieve the same
> CSSMutableStyleDeclaration mentioned above) & call
> CSSStyleSelector::applyProperty(). Here each StyleSelector has its
> RenderStyle (m_style), where from we retrieve the FontDescription & add the
> properties accordingly. On the other hand, each RenderObject (the
> corresponding node in the RenderTree for a node in DOM tree) has
> RenderStyle, which gets the value we retrieved above.
>
> Finally we call GraphicsContext::drawText() passing the Font which we have
> retrieved from the RenderStyle we dsicussed above.
>
> I am not sure if this is what you were looking for, I just shared whatever
> I knew of the related area. Please let me know if you need anything else.
>
> Thanks,
> Rahaman
>
>
> On Fri, May 20, 2011 at 12:22 AM, Soheil Servati Beiragh <
> sserv...@yahoo.com> wrote:
>
>> Hi
>> I want to know after webkit parses the html file where does it save the
>> font that is used for text? It definitely won't save a name for the font but
>> there should be some kind of index or sth to tell the rendering engine which
>> font is being used.
>>
>> Thanks in advance
>>
>> *Soheil Servati Beiragh*
>> *PhD Candidate, ECE Department,
>> *
>> *Research Center for Integrated Microsystems,*
>> *University of Windsor.*
>> Room 268 Essex Hall
>> 401 Sunset Avenue
>> Windsor, Ontario
>> Canada, N9B 3P4
>> Phone: 519-253-3000 Ext 3396
>> Email: serv...@uwindsor.ca
>>
>> ___________
>> 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
>
>


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

Re: [webkit-dev] Adding ENABLE_GESTURE_MANAGER

[Antonio Gomes]

Nice discussion!

I see the value of a cross-platform gesture implementation, but for the
touch interaction models I've seen out there, they are too different from
each other in many aspects, so maybe giving each platform its own spot to
implement it also makes sense.

On Mon, May 9, 2011 at 2:54 PM, Adam Barth  wrote:

> I'm mostly ignorant of how touch works, but would it make sense for
> the gesture recognition engine to be part of WebCore or is this
> functionality that's usually provided by the platform?
>
> Adam
>
>
> On Mon, May 9, 2011 at 11:32 AM, Robert Kroeger 
> wrote:
> > Hi webkit-dev!
> >
> > As suggested by Eric Seidel's email from earlier today, I thought it
> > would be proper to let you know that I am in the process of adding a
> > touch gesture recognition feature to the Chromium port of WebKit. The
> > first part of this feature is
> > https://bugs.webkit.org/show_bug.cgi?id=49345. This patch adds a hook
> > to WebCore to pass touch events to an optional platform-specific
> > gesture recognition engine. The code is turned off by default except
> > in the Chromium port where it is enabled with ENABLE_GESTURE_MANAGER.
> >
> > Patch https://bugs.webkit.org/show_bug.cgi?id=54417 and its successors
> > will add a progressively more useful gesture recognizer implementation
> > to the Chromium platform.
> >
> > All code in this feature will be exercised by the Chromium buildbots.
> >
> > Rob.
> > ___
> > 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
>



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

Re: [webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.

[Antonio Gomes]

CC'ed Konrad, who is one of the web inspector developers/"porters" on the
Playbook side.

On Sat, Apr 30, 2011 at 6:42 AM, Pavel Feldman wrote:

> This is really about the Web Inspector + about the new protocol that is a
> part of Web Inspector. The whole point of the post is that the same protocol
> is used for any WebKit-based product.
>
> Chrome is there as a proof of concept demo only. We need some shiny demo
> material for post so that people could see it and try it themselves.
> Otherwise, it becomes a boring chunk of text. I could use screenshots with
> Playbook's capabilities (
> http://www.berryreview.com/2011/04/15/hot-webkit-web-inspector-on-the-blackberry-playbook-for-web-developers/)
> or both Chrome and Playbook. Any RIM people around?
>



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

Re: [webkit-dev] Who are the EFL reviewers?

[Antonio Gomes]

I think the WebKit/EFL patches are 100% valuable to be submitted to
WebKit.org. ProFusion and Samsung are doing a great job improving the port,
and we should not discourage them to keep contributing.

I've been rubber-stamping and reviewing their contributions as much as I
can, and I have to agree that I feel more confident in certain cases when an
informal review round happens by the port experts. So keep informally
reviewing your colleagues patches, guys. It not only helps the official
reviewer, as it counts for you guys have your own reviewer.

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

Re: [webkit-dev] Who are the EFL reviewers?

[Antonio Gomes]

Mostly myself and Kenneth. We do what we can, but we also to work on our
stuff (as everybody else :). It really needs other reviewers to help out
with reviewing, since EFL port guys are working really hard on it.

On Sun, Apr 10, 2011 at 7:51 PM, Eric Seidel  wrote:

> We seem to have a zillion EFL patches up for review.
>
> Who are the EFL reviewers?
>
> (I think part of the trouble is that it seems the EFL port is trying to do
> too much in WebKit.  I'm not sure where the EFL browser is, but some of the
> patches look like they should be re-directed to that project instead of
> WebKit.)
>
> -eric
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>


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

Re: [webkit-dev] Progress

[Antonio Gomes]

I must say Qt has (the tireless) Ossy and Szeged crew almost 24hours/day :o,
as you had probably noticed/

On Fri, Apr 1, 2011 at 12:11 PM, Martin Robinson wrote:

> On Fri, Apr 1, 2011 at 7:06 AM, Adam Roben  wrote:
> > Jessie Berlin and I have been trying to pitch in as well over the course
> of
> > the week. (We have a rotation similar to Chromium's gardeners inside
> Apple,
> > but it's fairly new.) I think it is definitely helpful to have more eyes
> on
> > the bots.
>
> Igalia has a rotation of people keeping the tree green as well. Here's
> the current list if you're curious who you should poke about GTK+
> redness:
>
> Monday: Alejandro Garcia Castro (alexg)
> Tuesday: Mario Sanchez Prada (msanchez)
> Wednesday: Martin Robinson (mrobinson)
> Thursday: Philippe Normand (pnormand or philn)
> Friday: Sergio Villar Senin (svillar)
>
> --Martin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] bugid in ChangeLog

[Antonio Gomes]

Darin, could you explain your reasons?

On Mon, Mar 28, 2011 at 12:52 PM, Darin Adler  wrote:

> On Mar 27, 2011, at 1:31 AM, Jeremy Orlow wrote:
>
> > I'd even go a bit further and say that if something is worth a review
> (even if it's over the shoulder), it's worth a bug + a bug number.
>
> This is where I do not agree. Review is a requirement, but I don’t think
> bugs.webkit.org should be.
>
>-- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] code review tool changes

[Antonio Gomes]

It absolutely does! Thanks Ojan ... this is a great tool.

On Tue, Feb 15, 2011 at 12:47 AM, Ojan Vafai  wrote:

> shift+click can now be used to extend the context for a comment.
> http://trac.webkit.org/changeset/78530
>
>
> On Mon, Feb 14, 2011 at 4:27 PM, Ojan Vafai  wrote:
>
>> This behavior did change. But ctrl was never involved. If you ever clicked
>> on a line next to an existing review comment line, it would expand to
>> include it. The problem is that it's then difficult to leave comments on
>> adjacent lines.
>>
>> You can still click and drag to expand the context though as long as you
>> start inside the existing context. Alternately, adding ctrl (shift is
>> probably better) to expand the context wouldn't be a difficult addition.
>>
>> Ojan
>>
>>
>> On Mon, Feb 14, 2011 at 4:01 PM, Antonio Gomes wrote:
>>
>>> Previously, I was able to increase the context of my inline review
>>> comments by clicking on consecutive line numbers while pressing CONTROL. It
>>> seems regressed. Am I the only one noticing that?
>>>
>>>
>>> --
>>>  --Antonio Gomes
>>>
>>
>>
>


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

Re: [webkit-dev] code review tool changes

[Antonio Gomes]

Previously, I was able to increase the context of my inline review comments
by clicking on consecutive line numbers while pressing CONTROL. It seems
regressed. Am I the only one noticing that?


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

Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug

[Antonio Gomes]

> It was very common to use this approach on bugzilla.mozilla.org, with each
> component in the system having its own dummy email address auto-added.  This
> allows developers to subscribe / unsubscribe from receiving email for
> various components in the bug system.
>
>
I would *very* much support that.


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

Re: [webkit-dev] More thoughts on cleaning up the root directory

[Antonio Gomes]

> I filed a meta bug for tracking the layering violation.
> https://bugs.webkit.org/show_bug.cgi?id=51662
> It would be great if anyone added dependent bugs for this.

There is a bug about it (
https://bugs.webkit.org/show_bug.cgi?id=21354 ) and it already has a
better-filed dependency list.

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

Re: [webkit-dev] Renaming directories

[Antonio Gomes]

> Do we want to move LayoutTests => RegressionTests?

+1.

RegressionTests would better describe the current testing infra
structure used in the project than LayoutTests. Semantically, one can
even say that "regression tests" can include "layout tests" ...


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

[webkit-dev] Gtk Linux 32btis Release needs a full build.

[Antonio Gomes]

Building has been failing on it since the WebKitTools -> Tools rename (r74301).

(...)
make: *** No rule to make target `../../WebKitTools/GNUmakefile.am',
needed by `../../GNUmakefile.in'.  Stop.

Failed to build WebKit using 'make'!
program finished with exit code 2
elapsedTime=10.943262
(...)


"GTK Linux 32-bit Debug" and "GTK Linux 64-bit Debug" are ok though.


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

Re: [webkit-dev] Is the default height of the replaced elements 150PX ?

[Antonio Gomes]

Please file a bug (https://bugs.webkit.org )saying:

1) why it is wrong
2) how we can reproduce the problem - a reduce test case is desired ...
3) provide info about how other major browsers work, multiple
platforms if that matters.
4) quotation of any part of the spec saying what the default height
should be if unspecified by the page author.

Paste the bug id here.

You can get more attention this way.

2010/12/2 xu bai :
> Hi,all
> I found the default height of iframe is 150px if it has not the
> height. why do this?  It caused there are the blanks on my page. how do
> solved it?
>
> --
> 波澜壮阔心无涟漪
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



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

Re: [webkit-dev] Bools are strictly worse than enums

[Antonio Gomes]

Again, I think enum is better. I am just saying that method(true /*
xxx */) is not as bad as method(true, true, true, false);

On Fri, Dec 3, 2010 at 5:01 PM, Eric Seidel  wrote:
> I think /* explanation of what I'm doing */ is strictly worse than
> readableCode(UnderstandableParameter).
> I'd rather have readable code than comments attempting to excuse unreadable
> code.
> -eric
> On Fri, Dec 3, 2010 at 1:57 PM, Antonio Gomes  wrote:
>>
>> I do not think that XXX:repaint(true /* immediate */) is so bad
>> either, if I understood Hyatt's comment correctly, and I agree with him on
>> it.
>>
>> Having a enum is ideal, but no need for it to be mandatory, as other
>> also pointed out.
>>
>> On Fri, Dec 3, 2010 at 4:54 PM, Eric Seidel  wrote:
>> > I'm not sure we have any examples of bool passing like that in real
>> > code.
>> > The case I'm concerned about is not one of single argument bools:
>> > doSoemthing(bool)
>> > but more of multi-argument functions:
>> > doSomething(something, bool)
>> > I'm trying to write a rule which can be easily automated by
>> > check-webkit-style.
>> > It's possible we could tighten the rule further to only allow
>> > single-argument bools where "set" is in the function name.
>> > It sounds like most folks are in agreement.  We should add a rule like
>> > this
>> > to check-webkit-style.  Sounds like Dave Levin may already have
>> > something
>> > partial in the works.
>> > -eric
>> > On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa  wrote:
>> >>
>> >> On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt  wrote:
>> >>>
>> >>> The only exception I would make to this rule is if all the call sites
>> >>> use
>> >>> variables and never pass in raw true or false.  In that case there's
>> >>> no loss
>> >>> of readability, and whether you use an enum vs. a bool is irrelevant.
>> >>> I think in general the rule should be "Keep your call sites readable,
>> >>> and
>> >>> convert to enums if you find that the call sites are becoming
>> >>> inscrutable."
>> >>
>> >> That rule makes sense to me.
>> >> On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel  wrote:
>> >>>
>> >>> Dave, I'm not sure I understand your exception.  Could you give an
>> >>> example?
>> >>
>> >> I think what he means is that
>> >> bool doSomething();
>> >> void doSomethingElse(bool);
>> >> and the only case we always call doSomethingElse with a return value of
>> >> some function or with a variable:
>> >> doSomethingElse(doSomething());
>> >> doSomethingElse(shouldNotDoSomethingElse);
>> >> etc...
>> >> and we never call it with raw true/false:
>> >> doSomethingElse(true)
>> >> doSomethingElse(false)
>> >> - Ryosuke
>> >>
>> >> ___
>> >> 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
>> >
>> >
>>
>>
>>
>> --
>> --Antonio Gomes
>
>



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

Re: [webkit-dev] Bools are strictly worse than enums

[Antonio Gomes]

I do not think that XXX:repaint(true /* immediate */) is so bad
either, if I understood Hyatt's comment correctly, and I agree with him on it.

Having a enum is ideal, but no need for it to be mandatory, as other
also pointed out.

On Fri, Dec 3, 2010 at 4:54 PM, Eric Seidel  wrote:
> I'm not sure we have any examples of bool passing like that in real code.
> The case I'm concerned about is not one of single argument bools:
> doSoemthing(bool)
> but more of multi-argument functions:
> doSomething(something, bool)
> I'm trying to write a rule which can be easily automated by
> check-webkit-style.
> It's possible we could tighten the rule further to only allow
> single-argument bools where "set" is in the function name.
> It sounds like most folks are in agreement.  We should add a rule like this
> to check-webkit-style.  Sounds like Dave Levin may already have something
> partial in the works.
> -eric
> On Fri, Dec 3, 2010 at 1:45 PM, Ryosuke Niwa  wrote:
>>
>> On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt  wrote:
>>>
>>> The only exception I would make to this rule is if all the call sites use
>>> variables and never pass in raw true or false.  In that case there's no loss
>>> of readability, and whether you use an enum vs. a bool is irrelevant.
>>> I think in general the rule should be "Keep your call sites readable, and
>>> convert to enums if you find that the call sites are becoming inscrutable."
>>
>> That rule makes sense to me.
>> On Fri, Dec 3, 2010 at 1:40 PM, Eric Seidel  wrote:
>>>
>>> Dave, I'm not sure I understand your exception.  Could you give an
>>> example?
>>
>> I think what he means is that
>> bool doSomething();
>> void doSomethingElse(bool);
>> and the only case we always call doSomethingElse with a return value of
>> some function or with a variable:
>> doSomethingElse(doSomething());
>> doSomethingElse(shouldNotDoSomethingElse);
>> etc...
>> and we never call it with raw true/false:
>> doSomethingElse(true)
>> doSomethingElse(false)
>> - Ryosuke
>>
>> ___
>> 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
>
>



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

Re: [webkit-dev] commit ownership and commit-queue

[Antonio Gomes]

Hi William.

I think all developers who got a @webkit.org email set up as primary
email and for some reason switched to use a company email in the
changelog will be affected. This is the main reason right now that
prevents me from using the commit-queue, but if it is only me, then I
can live with it.

ps: why do many people have more than one email in committers.py then?

Cheers,

On Mon, Nov 29, 2010 at 1:56 AM, William Siegrist  wrote:
> On Nov 28, 2010, at 10:21 PM, Antonio Gomes wrote:
>
>> Hi.
>>
>> In committers.py I have "tonikitoo at webkit" and "agomes at rim"
>> subscribed as my working emails.
>>
>> ...
>> Reviewer("Antonio Gomes", ["toniki...@webkit.org", "ago...@rim.com"],
>> "tonikitoo"),
>> ...
>>
>> However, when I use the commit-queue and sign the ChangeLog with the
>> later email (agomes at rim), the commit-queue does not change the
>> ownership to the commit to myself, i.e to my primary email (tonikitoo
>> at webkit), although I think it shoulds. <
>> http://trac.webkit.org/changeset/72780 > is an example of that.
>>
>> Would it be considered a feasible feature request?
>>
>
> Is there a reason you cannot use your committer address in the changelog? The 
> server currently does not use committers.py, so reengineering the author 
> rewriting would take some amount of work. Is there a good reason to do this?
>
> -Bill



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

[webkit-dev] commit ownership and commit-queue

[Antonio Gomes]

Hi.

In committers.py I have "tonikitoo at webkit" and "agomes at rim"
subscribed as my working emails.

...
Reviewer("Antonio Gomes", ["toniki...@webkit.org", "ago...@rim.com"],
"tonikitoo"),
...

However, when I use the commit-queue and sign the ChangeLog with the
later email (agomes at rim), the commit-queue does not change the
ownership to the commit to myself, i.e to my primary email (tonikitoo
at webkit), although I think it shoulds. <
http://trac.webkit.org/changeset/72780 > is an example of that.

Would it be considered a feasible feature request?


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

Re: [webkit-dev] Hunspell based spellchecker

[Antonio Gomes]

It is. See https://bugs.webkit.org/show_bug.cgi?id=44114

On Wed, Nov 17, 2010 at 1:43 PM, Robert Hogan  wrote:
> On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote:
>> Hi WebKit folks,
>>
>> I'm thinking about porting Hunspell-based spellchecking code
>> from Chromium to WebKit/WebCore.
>
> The Qt folks on the list can correct me if I'm wrong but this would be very
> welcome for Qt. I don't see how a WebCore spellchecker could be anything
> but a good thing!
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] WebKitGtk app memory leaks , please help

[Antonio Gomes]

As far as I know you can not listen for DOM event using QWebElement.

On Wed, Nov 3, 2010 at 4:44 PM, Xan Lopez  wrote:
> On Wed, Nov 3, 2010 at 1:20 PM, Fedor Kryukov  wrote:
>>
>> Thanks,
>>
>> As I understand this is a WebkitGtk bug only?
>> So I can temporarily switch to QT WebKit to avoid leaks?
>>
>
> Possibly, but I don't know, you should ask them.
>
> Also, both bindings are not equally feature-complete (I believe in
> general the GTK+ ones have more features), so you'll have to be
> careful with that too.
>
> Xan
>
>>
>> Xan Lopez-3 wrote:
>>>
>>> On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov  wrote:
>>>>
>>>> After calling webkit_web_view_get_dom_document() and similar functions (
>>>> webkit_dom... * ) memory is not freed, what am I doing wrong?
>>>>
>>>> I wrote simple application which handle events (
>>>> load-started/load-finished/etc ) and make some changes in loaded page DOM
>>>> content, so after loading several pages I have a lot of lost memory, no
>>>> idea
>>>> how to release it.
>>>>
>>>> I tried to use g_object_unref, but it destroys something..
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html
>>>> Sent from the Webkit mailing list archive at Nabble.com.
>>>
>>> The memory management of the GObject DOM bindings is still a work in
>>> progress (unfortunately!). We are trying to figure the best to
>>> automatically collect them, but for now you are correct in saying that
>>> they are essentially "leaked" until the process is over.
>>>
>>> See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion
>>> on the topic. Our plan is to have this issue resolved before the next
>>> stable release in April.
>>>
>>> Xan
>>>
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>> --
>> View this message in context: 
>> http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30126515.html
>> Sent from the Webkit mailing list archive at Nabble.com.
>>
>> ___
>> 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
>



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

Re: [webkit-dev] Clobber builds in windows bots needed?

[Antonio Gomes]

Win bots build fixed with http://trac.webkit.org/changeset/70988

> On Sat, Oct 30, 2010 at 12:59 PM, Eric Seidel  wrote:
>> The correct fix is to fix the dependency issue in the build system.
>> Please file a bug so we can prevent these from occurring in the
>> future.

Filed bug https://bugs.webkit.org/show_bug.cgi?id=48721 about it.

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

Re: [webkit-dev] Clobber builds in windows bots needed?

[Antonio Gomes]

Thanks.

I would have done and checked if it worked, but build.webkit.org is
offline atm: "Service Temporarily Unavailable".

On Sat, Oct 30, 2010 at 4:36 AM, Brian Weinstein  wrote:
> In this case you want to touch WebKit.idl, that will force a rebuild of the
> Interfaces project, and should fix the Windows build.
> Brian
> On Oct 29, 2010, at 11:12 PM, Antonio Gomes wrote:
>
> Hi.
>
> After http://trac.webkit.org/changeset/70975, Windows Debug bot
> started failing to build:
> http://build.webkit.org/builders/Windows%20Debug%20%28Build%29 . The
> build error shown is:
>
> ()
> ### COMPILING 1 FILES USING AT MOST 8 PARALLEL INSTANCES OF cl.exe
> ###
>
> LayoutTestControllerWin.cpp
>
> .\LayoutTestControllerWin.cpp(1389) : error C2065:
> 'WebKitEditingUnixBehavior' : undeclared identifier
> ()
>
> however this enum value is clearly declared in
> WebKit/win/Interfaces/IWebPreferences.idl as
>
> 50 typedef enum WebKitEditingBehavior {
> 51 WebKitEditingMacBehavior = 0,
> 52 WebKitEditingWinBehavior,
> 53 WebKitEditingUnixBehavior
> 54 } WebKitEditingBehavior;
>
> Could someone with access to this bot force a complete build? Maybe
> this is needed for this .idl to properly generate the corresponding
> header.
>
> --
> --Antonio Gomes
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



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

[webkit-dev] Clobber builds in windows bots needed?

[Antonio Gomes]

Hi.

After http://trac.webkit.org/changeset/70975, Windows Debug bot
started failing to build:
http://build.webkit.org/builders/Windows%20Debug%20%28Build%29 . The
build error shown is:

()
### COMPILING 1 FILES USING AT MOST 8 PARALLEL INSTANCES OF cl.exe
###

LayoutTestControllerWin.cpp

.\LayoutTestControllerWin.cpp(1389) : error C2065:
'WebKitEditingUnixBehavior' : undeclared identifier
()

however this enum value is clearly declared in
WebKit/win/Interfaces/IWebPreferences.idl as

 50 typedef enum WebKitEditingBehavior {
 51 WebKitEditingMacBehavior = 0,
 52 WebKitEditingWinBehavior,
 53 WebKitEditingUnixBehavior
 54 } WebKitEditingBehavior;

Could someone with access to this bot force a complete build? Maybe
this is needed for this .idl to properly generate the corresponding
header.

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

Re: [webkit-dev] Platform specific editing behaviors

[Antonio Gomes]

Hi.

Thanks for the feedback, Ojan and Ryosuke.

>From the experiments I've been doing, I think it will be a smooth
landind. The platform specific editing behavior code paths are not
that common in the tests in LayoutTests/editing, and the tests that go
through them were converted to use the
LayoutTestController::setEditingBehavior machinery, so should not be
affected. See for example bugs 47471 and 47472 (among others), where
tests touching platform specific editing behaviors were converted to
use LayoutTestController::setEditingBehavior.

For instance, I have access to tree platform builds: Mac port on SL,
and webkit-gtk and qtwebkit on linux. I am able, for example, to run
all tests in editing/ in a Mac build after changing the editing
behavior to "Win" instead of the default "Mac". Similar situation on
gtk and qt builds.

Cheers,

On 10/27/10, Ryosuke Niwa  wrote:
> On Wed, Oct 27, 2010 at 2:17 PM, Antonio Gomes  wrote:
>
>> Well, despite the naming to be used, in the same bug I am proposing
>> that the editing behavior of each platform to be set according to the
>> OS it is running on. As an example, Chromium when built on Mac would
>> have the MacEditingBehavior set, while when built on Windows it would
>> have the Window editing behavior, etc. The same logic would apply to
>> all cross-platform ports, including QtWebKit.
>
>
> I think this is an improvement.  But can we coordinate when landing patches
> so that we can maintain chromium bots green?  I don't want to see 100+
> editing test failures all of sudden without a pre-caution.  This shouldn't
> be too hard given that chromium has a try bot.
>
> - Ryosuke
>


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

[webkit-dev] Platform specific editing behaviors

[Antonio Gomes]

Hi.

In bug https://bugs.webkit.org/show_bug.cgi?id=36627 (Needs a
"LinuxEditingBehavior", perhaps with a better name) , in order to
supply needs that the existing editing behaviors (Mac and Windows) do
not cover, we are going to add a new editing behavior type. The name
is not defined yet, and our current options are LinuxEditingBehavior,
EditingUnixBehavior, EditingFreedesktopOrgBehavior,
EditingFreedesktopBehavior or EditingXWindowsBehavior.

Well, despite the naming to be used, in the same bug I am proposing
that the editing behavior of each platform to be set according to the
OS it is running on. As an example, Chromium when built on Mac would
have the MacEditingBehavior set, while when built on Windows it would
have the Window editing behavior, etc. The same logic would apply to
all cross-platform ports, including QtWebKit. On the other hand, OS
specific ports like Apple's Mac and Windows ports would not have to
worry about it, since they just run on Mac or Windows respectively.

static EditingBehaviorType editingBehaviorTypeForPlatform()
{
return
#if OS(DARWIN)
EditingMacBehavior
#elif OS(WINDOWS)
EditingWindowsBehavior
#elif OS(UNIX)
EditingLinuxBehavior
#else
// Fallback
EditingMacBehavior
#endif
;
}

Before anything I would like to point it our here, and hear  from the
port maintainers any possible objection about it, specially from the
cross-platform ones, including Chromium and Qt.

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

[webkit-dev] Ordering bugmail in committers.py

[Antonio Gomes]

Hi.

The autocompletion feature on bugs.webkit.org is simply great. But for
it to work even better it is needed that all contributors listed in
committers.py (reviewers and committers) properly make their bugmail
(email subscribed to bugs.webkit.org) to be the first one in the list.

As a illustration of the situation here we go two example of failing
CC additions via the autocompletion feature due to the wrong ordering:
Martin Robinson and Adam Treat  ("tr...@kde.org" is the first email
listed but "atr...@rim.com", the third listed, is the bugmail).

It would be great if each contributor  could fix its own ordering, so
the autocompletion works nicely for everyone.

Thanks,

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

Re: [webkit-dev] On frequently hosing other port's WebKit2 builds

[Antonio Gomes]

Maybe making EWS bots build already r+'ed patches could help here as well.

On Wed, Oct 6, 2010 at 7:13 PM, Andras Becsi  wrote:

> Dear WebKit Community,
>
> In the past few weeks there were several occasions where Apple-WebKit2
> developers ignored the red Qt EWS on Bugzilla and nonetheless committed
> their patches and let the Qt bot stay red for several hours without any sign
> of trying to fix the issues (mostly introduced by thoughtlessness), or
> asking for help on IRC, or even the webkit-qt mailing list, or CC'ing
> somebody to the bug who might be able to help fixing the problems before
> hosing the tree, like with these bugs:
>
> https://bugs.webkit.org/show_bug.cgi?id=47281
> https://bugs.webkit.org/show_bug.cgi?id=47239
> https://bugs.webkit.org/show_bug.cgi?id=47097
> https://bugs.webkit.org/show_bug.cgi?id=46585
> https://bugs.webkit.org/show_bug.cgi?id=46432
> https://bugs.webkit.org/show_bug.cgi?id=46054
> https://bugs.webkit.org/show_bug.cgi?id=46043
>
> This is making the lives of the maintainers miserable because if a bot is
> already red it is completely ignored by other developers, which makes it
> really hard to catch up.
> I respectfully think that this kind of arrogant and ignorant way of
> development does real harm to the community.
> We have a really fast Qt EWS and the build failures weren't complex ones,
> the EWS would have only needed a minute more than the style-bot to have a
> nice output where the errors caused by left-in old API calls or old includes
> or left-out extra compiler definitions would have shown themselves, and I do
> not think waiting this few minutes would hurt anyone. Especially because
> this kind of behaviour is not only disrespectful to us, but also to Eric and
> Adam who are working hard to make these awsome QA technologies possible.
>
> Comments like this https://bugs.webkit.org/show_bug.cgi?id=47097#c10 are
> really frustrating, because all contributors are supposed to bother with the
> Mac xcodeproj files and their cryptic hashes, too (not to talk about the
> other nearly dozen build systems) if they implement something, and
> stringently have their patches checked on all the EWS.
>
> Surpassing all my private disappointment, I think IRC, Bugzilla, the EWS's
> and other buildbots aren't there to force some kind of an unwanted ritual on
> developers, in which they only upload patches to Bugzilla to conform some
> policy, but to make collaboration possible.
>
> I do not want my letter to be looked at as an offense or attack, I'd rather
> like to kindly ask the responsile ones to stop the ignorant and
> discriminative way of handling other ports, and at least try to show some
> respect on other developers work.
>
> Sorry, if this souded like an offense.
>
> WBR,
> Andras Becsi
>
> On behalf of the QtWebKit Team at the University of Szeged
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] Fwd: [webkit-changes] [68146] trunk/WebCore

[Antonio Gomes]

Find some details here: https://bugs.webkit.org/show_bug.cgi?id=37205
, specially https://bugs.webkit.org/show_bug.cgi?id=43216#c15 .and
followup comments.

Bug and changelog in bug 46348 are poor, though, I agree.

On Thu, Sep 23, 2010 at 2:03 PM, Alexey Proskuryakov  wrote:
>
> It is unfortunate that this fix changes unused code. Will it be covered by
> existing layout tests when ScriptFunctionCall and ScriptCallback start being
> used?
> The patch and bug were highly confusing. Without any explanation of why this
> assertion was wrong, a test case, or an explanation of why one can't be
> made, I had to spend considerable time figuring out why it shouldn't be
> rolled out immediately.
> - WBR, Alexey Proskuryakov
> Начало переадресованного сообщения:
>
> От: commit-qu...@webkit.org
> Дата: 23 сентября 2010 г. 8:57:01 Тихоокеанское летнее время
> Кому: webkit-chan...@lists.webkit.org
> Тема: [webkit-changes] [68146] trunk/WebCore
>
> Revision 68146 Author commit-qu...@webkit.org Date 2010-09-23 08:56:59 -0700
> (Thu, 23 Sep 2010)
>
> Log Message
>
> 2010-09-23  Luiz Agostini  
>
> Reviewed by Andreas Kling.
>
> Invalid assertion in ScriptCallback
> https://bugs.webkit.org/show_bug.cgi?id=46348
>
> Removing invalid ASSERT from method ScriptCallback::call().
>
> * bindings/js/ScriptFunctionCall.cpp:
> (WebCore::ScriptCallback::call):
>
> Modified Paths
>
> trunk/WebCore/ChangeLog
> trunk/WebCore/bindings/js/ScriptFunctionCall.cpp
>
> Diff
>
> Modified: trunk/WebCore/ChangeLog (68145 => 68146)
>
> --- trunk/WebCore/ChangeLog   2010-09-23 15:51:41 UTC (rev 68145)
> +++ trunk/WebCore/ChangeLog   2010-09-23 15:56:59 UTC (rev 68146)
> @@ -1,3 +1,15 @@
> +2010-09-23  Luiz Agostini  
> +
> +Reviewed by Andreas Kling.
> +
> +Invalid assertion in ScriptCallback
> +https://bugs.webkit.org/show_bug.cgi?id=46348
> +
> +Removing invalid ASSERT from method ScriptCallback::call().
> +
> +* bindings/js/ScriptFunctionCall.cpp:
> +(WebCore::ScriptCallback::call):
> +
>  2010-09-23  Martin Robinson  
>
>  Reviewed by Ariya Hidayat.
>
> Modified: trunk/WebCore/bindings/js/ScriptFunctionCall.cpp (68145 => 68146)
>
> --- trunk/WebCore/bindings/js/ScriptFunctionCall.cpp  2010-09-23 15:51:41 UTC
> (rev 68145)
> +++ trunk/WebCore/bindings/js/ScriptFunctionCall.cpp  2010-09-23 15:56:59 UTC
> (rev 68146)
> @@ -215,9 +215,9 @@
>
>  CallData callData;
>  CallType callType = getCallData(m_function.jsValue(), callData);
> +if (callType == CallTypeNone)
> +return ScriptValue();
>
> -ASSERT(callType != CallTypeNone);
> -
>  JSValue result = JSC::call(m_exec, m_function.jsValue(), callType,
> callData, m_function.jsValue(), m_arguments);
>  hadException = m_exec->hadException();
>
>
> ___
> webkit-changes mailing list
> webkit-chan...@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-changes
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



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

[webkit-dev] Changing API for Document::nodesFromRect

[Antonio Gomes]

Hi all.

A few months back, http://trac.webkit.org/changeset/64272 added
Document::nodesFromRect as a convenient interface for the rect-based
hit testing extension (also added in the same checkin). The intention
behind this checkin is to enable WebKit to enlarge the target area of
mouse events, by building up a fuzzy rectangular area to be processed
by the engine while hit testing, which can be specially useful for
touch devices.

As is today, the method signature looks like this: void
nodesFromRect(int x, int y, int horizontalPadding, int
verticalPadding). Basically, the rectangular area to be processed by
the engine is built up using the original event position as its center
point (x and y), expanding it by the given paddings for each
orientation (vertical and horizontal).

Empirical results from testing the use of nodesFromRect in capacitive
touch screens showed us that users tend to tap below elements. So for
even more accurate results (which means pleasant tapping experience),
it makes sense to use a region that is offset more above the touch
point, favoring elements above the touch point.

The Mozilla mobile team also had the same feeling (as described in
[1]) and adjusted their nodesFromRect API accordingly by making it
possible to specify different offset for each direction (top, right,
bottom, left). I propose we to follow their more flexible approach:
method signature would change to RefPtr nodesFromRect(int x,
int y, int top, int right, int bottom, int left).

Whoever still want to share the same value for vertical offsets will
be happy, and who want it more flexible will also be happy.

Filed bug https://bugs.webkit.org/show_bug.cgi?id=46336 about that.

[1] http://starkravingfinkle.org/blog/2010/05/smart-tapping-in-mobile-firefox/
[2] 
http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindowUtils.idl#416


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

Re: [webkit-dev] Treat warnings as errors by QtWebKit

[Antonio Gomes]

Great work!

2010/9/8 Osztrogonac Csaba :
> Dear WebKit Community,
>
> in the past weeks we have worked on fixing warnings of QtWebKit. Now it's
> time to treat warnings as errors to warrant better code quality. First we
> enabled -Werror on x86/Linux platforms, and in the near future we are going
> to enable it for other Qt platforms. (ARM/Linux, x86/Windows, ...)
>
> From now any warning will break "Qt Linux Release", "Qt Linux Release
> minimal"
> buildbots and the Qt EWS bot. Please take notice of their redness.
>
> FYI: master bug of this topic -
> https://bugs.webkit.org/show_bug.cgi?id=43191
>
> With best regards:
> Csaba Osztrogonác (ossy on #webkit, ossy {at} webkit {dot} org)
> University of Szeged
> http://webkit.sed.hu
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] Updating the tradition for new reviewer blog posts

[Antonio Gomes (:tonikitoo)]

I think that it would be awesome as well. There is so much content to
be blogged by the community. For example, I have myself two nice
subjects of WebCore stuff I've been involved with:

- rect based hit testing;
- spatial navigation.

Would be more than happy to get the contents of two posts published in
Surfing Safari.

ps: Maybe having reviewers feed in planet.webkit.org would be also a good idea.

On Mon, Aug 2, 2010 at 4:56 PM, Adam Barth  wrote:
> I'd be happy to write more posts for Surfin' Safari, but I don't know
> if I need approval, etc.
>
> Adam
>
>
> On Mon, Aug 2, 2010 at 1:31 PM, Eric Seidel  wrote:
>> Woh.  I think that's an awesome idea. :)
>>
>> Would also make sure that all reviewers are blog-enabled.
>>
>> Might be a bit to ask of new reviewers though.
>>
>> -eric
>>
>> On Mon, Aug 2, 2010 at 11:56 AM, Tony Gentilcore  wrote:
>>> The Surfin' Safari blog seems to have fairly wide readership in the web dev
>>> community. Google Reader reports 35k Reader subscribers. For comparison:
>>> blog.chromium.org has 17k and blog.mozilla.com has 10k. However, the last
>>> post with descriptive content was back on April 18th. Since that post, we've
>>> written 8 "X is a now a WebKit reviewer" posts. One recent commenter said:
>>> "I don’t suppose there’s anything more interesting going on in WebKit land
>>> worth blogging about, is there? So-and-so is a new WebKit reviewer isn’t
>>> nearly as interesting as whatever new hotness is coming down the pipe. And I
>>> know I’m not the only one who thinks so… Feel like blogging about WebKit
>>> awesomeness?"
>>>
>>> I propose we increase the amount of blogging about WebKit awesomeness by
>>> changing the tradition for new reviewer posts.
>>>
>>> Instead of defaulting to:
>>>
>>>   So-and-so is now a WebKit reviewer
>>>   Posted by Someone-else
>>>   So-and-so has worked on awesome-feature or awesome-infrastructure...
>>>
>>> We encourage (or just allow?) a format more like:
>>>
>>>   How awesome-infrastructure works
>>>   Posted by So-and-so, the latest WebKit reviewer
>>>   Here's my description of how awesome-infrastructure works in WebKit...
>>>   -OR-
>>>
>>>   Awesome-feature is the new hotness
>>>   Posted by So-and-so, the latest WebKit reviewer
>>>   Web developers can now use awesome-feature. Here's how it works...
>>>
>>> Thoughts?
>>> -Tony
>>> ___
>>> 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
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] SIL Open Font License and WebKit

[Antonio Gomes (:tonikitoo)]

Again, maybe something like http://gitorious.org/qtwebkit/testfonts as
QtWebKit does for the exactly same propose?

On Tue, Jul 20, 2010 at 11:24 AM, Alex Milowski  wrote:
> On Tue, Jul 20, 2010 at 4:11 PM, Darin Adler  wrote:
>> On Jul 20, 2010, at 4:39 AM, Alex Milowski wrote:
>>
>>> We can't really download them from stixfonts.org.
>>
>> Why?
>
> Well, because the zip file is behind a form that requires you to
> "accept" the license.  It doesn't seem right to try to hack our way
> through that form to run tests.  Besides, some organization
> should accept the terms of the license and the responsibility
> for distributing this font to test systems (or developers running
> tests).
>
> --
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
>
> Bertrand Russell in a footnote of Principles of Mathematics
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] STIX Fonts and MathML Tests

[Antonio Gomes (:tonikitoo)]

Hi Alex.

On QtWebKit, it is requered a set of fonts to be available on the
local system, and WEBKIT_TESTFONT environment variable to be exported
pointing to the font location path. See [1].

[1] 
http://trac.webkit.org/wiki/QtWebKitContrib#InstallingthelayouttestfontsUsingrun-webkit-tests

In case it is unset, all tests will just crash. For that to go smooth,
we provide a git repository for the requered fonts, so one can easily
clone and do the set up steps by himself.

Would something like this work in your case?

On Wed, Jul 7, 2010 at 6:48 AM, Alex Milowski  wrote:
> Sausset François has been looking at using the newly released STIX
> fonts [1] for the MathML implementation.  If we start requiring STIX
> font support for MathML, how do we guarantee:
>
>   * these fonts exist in the build process so the tests will succeed,
>   * these fonts exist on the target platform.
>
> Certainly, we can create a stylesheet that degrades when the
> fonts are missing.  We could also do something with web fonts [2]
> but that seems like a bad idea for WebKit as a core platform for
> a variety of browsers.
>
> In general, we're working towards a point where we'd like to turn
> on MathML by default and, at that point, the tests must be run.  For
> the tests to succeed, we'd need the STIX fonts available.
>
> Is there any precedence for this or default policy for tests requiring
> fonts?
>
> [1] http://www.stixfonts.org/
> [2] http://hublog.hubmed.org/archives/001931.html
>
> --
> --Alex Milowski
> "The excellence of grammar as a guide is proportional to the paucity of the
> inflexions, i.e. to the degree of analysis effected by the language
> considered."
>
> Bertrand Russell in a footnote of Principles of Mathematics
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>



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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

>>>> In the later sample output, note that it did not reach  , whose
>>>> boundary obvious intersects any possible given Z rect. That would
>>>> happen if the  in case encloses the rect Z completely, and it
>>>> would be the stop point for the hit test.
>>>>
>>>> In Mozilla's implementation, nodesFromRect does not care if a node
>>>> encloses the hit test rect completely or partially. The test will
>>>> continue until the .
>>>>
>>>> What would be the preferable behavior for our implementation?
>>>
>>> The latter behavior may actually make the method useful for things other
>>> than hit testing, if that sways your decision at all. I can imagine page
>>> authors finding it useful to be able to find out all the elements that are 
>>> under
>>> a given point (which in turn suggests that elementsFromRect with zero 
>>> padding
>>> should still find all the hit elements in z-order).
>>
>> Exactly the point. For hit test matters, stopping as soon as it gets
>> fully enclosed makes total sense to me. On the other hand, as you
>> said, I bet there might be use cases like "give me all nodes under X,
>> Y, with padding W, H" (where they can be '0'). I thought about making
>> this "stop" an optional flag for HitTestResult or HitTestRequest.
>> Would it be acceptable?
>
> I'd resist adding this until we have a use case for it.

Maybe you've already have a internal use case (see below :)

Jun 16 18:04:01 tonikitoo: i need to talk to some people here
at apple too
Jun 16 18:04:12 tonikitoo: we've gotten a request for e.g.,
all the nodes that intersect the visible rect
Jun 16 18:04:16 that's a common desire
Jun 16 18:04:20 this api kind of does that
Jun 16 18:04:29 i think other browsers would be interested too 
etc

It would be great it we could use this opportunity to address this
request. But, well, in order to make it work that way ("give *all*
nodes under rect X"), there would be some less simple changes needed,
so we can go first for with what we have working at the moment.

Cheers,

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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

Hi Simon. Thank you join the discussion!

On Tue, Jul 6, 2010 at 1:46 AM, Simon Fraser  wrote:
> On Jul 5, 2010, at 7:35 PM, Antonio Gomes (:tonikitoo) wrote:
>
>> * adds a Document::nodesFromRect method, exposing the functionality to
>> the dom. It returns a NodeList with all nodes that intersect the given
>> hit-tested area.
>
> Is there a reason to use different terminology from the existing 
> "elementFromPoint",
> which would suggest that yours be named "elementsFromRect"?

We (dhyatt and I) originally considered that on irc, but for now it
was decided to keep it as nodesFromRect, specially because text nodes
are being returned, which is interesting for hit testing matters, in
fact. Do you see other objections against the naming, apart from the
terminology discrepancy with elementFromPoint?

>> As-is nodesFromRect will be store all nodes whose area intersects the
>> given rect hit test 'til it finds a node whose boundary encloses it
>> completely. At this point hit test will stop at any node in the tree
>> hierarchy. Sample outputs of nodesFromRect for an hypothetical rect X
>> and a html Y are [ , , ]. For another hypothetical rect
>> Z and the same html Y, nodesFromRect might return [,]
>
> I assume the nodes are listed in front-to-back z-order?

They are, yes.

>> In the later sample output, note that it did not reach  , whose
>> boundary obvious intersects any possible given Z rect. That would
>> happen if the  in case encloses the rect Z completely, and it
>> would be the stop point for the hit test.
>>
>> In Mozilla's implementation, nodesFromRect does not care if a node
>> encloses the hit test rect completely or partially. The test will
>> continue until the .
>>
>> What would be the preferable behavior for our implementation?
>
> The latter behavior may actually make the method useful for things other
> than hit testing, if that sways your decision at all. I can imagine page
> authors finding it useful to be able to find out all the elements that are 
> under
> a given point (which in turn suggests that elementsFromRect with zero padding
> should still find all the hit elements in z-order).

Exactly the point. For hit test matters, stopping as soon as it gets
fully enclosed makes total sense to me. On the other hand, as you
said, I bet there might be use cases like "give me all nodes under X,
Y, with padding W, H" (where they can be '0'). I thought about making
this "stop" an optional flag for HitTestResult or HitTestRequest.
Would it be acceptable?

>
> One thing that this functionality does not allow you to do is to find the 
> *closest*
> node to the given point that matches some set of criteria (like being 
> clickable).
> This might be a more useful thing for a mobile browser.

Right, as for mozilla's implementation, this method main goal is to
provide the list of nodes. Any post-processing over the resulting list
would be responsibility of the caller site, including calculating the
shortest distance rect, or consider the more frequently visited
elements (in case of links), etc.

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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

Hi guys.

We've uploaded a patch for review in bug
https://bugs.webkit.org/show_bug.cgi?id=40197 (attachment
https://bugs.webkit.org/attachment.cgi?id=59789 - chromium build fixed
in r61955) - Grace and I joint effort in fixing this issue.

As ways to expose the functionality, the patch:

* extends hitTestResultAtPoint method of the EventHandler with an
extra 'padding' parameter, defaulting to IntSize(0,0). The rect-based
hit test is performed when a non-zero padding is passed in;

* adds a Document::nodesFromRect method, exposing the functionality to
the dom. It returns a NodeList with all nodes that intersect the given
hit-tested area.

I would like to discuss how the later should work.

As-is nodesFromRect will be store all nodes whose area intersects the
given rect hit test 'til it finds a node whose boundary encloses it
completely. At this point hit test will stop at any node in the tree
hierarchy. Sample outputs of nodesFromRect for an hypothetical rect X
and a html Y are [ , , ]. For another hypothetical rect
Z and the same html Y, nodesFromRect might return [,].

In the later sample output, note that it did not reach  , whose
boundary obvious intersects any possible given Z rect. That would
happen if the  in case encloses the rect Z completely, and it
would be the stop point for the hit test.

In Mozilla's implementation, nodesFromRect does not care if a node
encloses the hit test rect completely or partially. The test will
continue until the .

What would be the preferable behavior for our implementation?

Cheers,

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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

Hi, as a follow up on this and based on a quick chat with hyatt on
irc, the minimalistic approach seems to be the way to go.

 dhyatt, david, could you join the discussion about rect
based hit test on bug 40197
 just need me to make a decision on the right naming?
 dhyatt, not that simple. Basically we have to decide if we
are going to have nodeAtArea methods throughout the code, and make
only base classes have nodeAtPoint methods, failing back to
nodeAtArea. Or if we are going to keep passing x and y to HitTest
methods, and HitTestResult will have a padding rect, so each
nodeAtPoint method could work with it
 huge fan of grace's approach i have to say
 very minimal on how intrusive it is
 right, it is simpler and and works equally
 yeah i kind of like the idea of slop around the point as the
approach though
 rather than patching every method name
 both patches need to stop using a vector for the node list
and use a hashset heh

On Thu, Jun 10, 2010 at 11:21 AM, Antonio Gomes (:tonikitoo)
 wrote:
> Hi,
>
> As Grace pointed out in the spun-off thread,  bug 40197 was filed and
> a patch was put up for feedback there. I looked over the patch, and
> since it took a different path from what I had in mind to fix the
> problem, I also took a couple of days and implemented mine prototype.
>
> I explained details of my approach in
> https://bugs.webkit.org/show_bug.cgi?id=40197#c7 and also explained
> the difference between both approaches in
> https://bugs.webkit.org/show_bug.cgi?id=40197#c8 - see it pasted
> below.
>
> "Although I strongly believe that both approaches here end up in the
> same results (even as-are), I will try to summarize the basic
> difference between grace's (attachment 57980 [details]) and mine
> (attachment 58324 [details]).
>
> From my understanding, the former makes the HitTest system
> "rect-aware" in the sense that it keeps the core logic of nodeAtPoint
> methods as point-based, but adjusts them to take a rect (a point + a
> padding area) into consideration.
>
> On the other hand, the later makes the HitTest really rect-based in
> the sense that it changes all nodeAtPoint existent methods to be
> nodeAtArea ones, and of course their method bodies were changed where
> needed.
>
> The difference is silly, but exists. We have just to decide how to
> proceed from that point on. Whatever direction is decided, I am up to
> join efforts with Grace to fix it."
>
> In summary, first patch keeps passing a "point" plus a new "padding
> rect" to build up the HitTestResult instance. The later makes any
> point passed to fallback to a IntRect(point, IntSize(1,1)) and changes
> the rest of the HitTest system to be rect-based (see more details in
> #c7).
>
> Comments welcomed.
>
> Regards
>
> On Sun, Jun 6, 2010 at 3:40 PM, Antti Koivisto  wrote:
>> On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt  wrote:
>>
>>> I really don't think hit testing needs to be modified to get what you want. 
>>>  You can do a scattershot sampling using multiple candidate points within 
>>> the rect and apply whatever heuristics you want to choose a node.  I'm also 
>>> not convinced that we should be complicating core hit testing code in this 
>>> way, since I suspect this is one of those areas where mobile platforms will 
>>> each want to do their own slightly different thing anyway.
>>
>> The problem with hit testing by multisampling is that it is
>> ridiculously slow. You need to take at least a dozen samples for
>> decent results. With a complex document on a mobile platform doing
>> those can take several hundreds of milliseconds. That is pretty far
>> from what is needed for good responsiveness. I think area hit testing
>> would make a lot of sense.
>>
>> With WebKit2 it might actually be a good idea to track all event
>> sensitive areas in the document. This way at least partial (no
>> hit/maybe hit) testing could be done entirely in the UI process side.
>>
>>
>>  antti
>>
>>> dave
>>> (hy...@apple.com)
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>
>
>
>
> --
> --Antonio Gomes
>



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

[webkit-dev] feedback{?,+,-} flag in bugzilla

[Antonio Gomes (:tonikitoo)]

Hi,

Mozilla's bugzilla had added a imo very useful flag to their bugzilla:
feedback{?,+,-}.

As the name implies, it is generally used when a patch is not yet
ready for a final review, but idea is shaped enough that worth a
validation before moving on. It might be specially useful when an idea
is still getting mature, or when the final patch will be a large
change. Personally, I found myself a user of it (e.g. see bugs 40197
and 39854).

Ideally, patches in feedback? status should also be easier to
review/validate, and the author would be sure it is taking the right
path. EWS bots would not necessarily have to build it or even do style
checks, but it is optional.

What do you think?

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

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

Hi,

As Grace pointed out in the spun-off thread,  bug 40197 was filed and
a patch was put up for feedback there. I looked over the patch, and
since it took a different path from what I had in mind to fix the
problem, I also took a couple of days and implemented mine prototype.

I explained details of my approach in
https://bugs.webkit.org/show_bug.cgi?id=40197#c7 and also explained
the difference between both approaches in
https://bugs.webkit.org/show_bug.cgi?id=40197#c8 - see it pasted
below.

"Although I strongly believe that both approaches here end up in the
same results (even as-are), I will try to summarize the basic
difference between grace's (attachment 57980 [details]) and mine
(attachment 58324 [details]).

>From my understanding, the former makes the HitTest system
"rect-aware" in the sense that it keeps the core logic of nodeAtPoint
methods as point-based, but adjusts them to take a rect (a point + a
padding area) into consideration.

On the other hand, the later makes the HitTest really rect-based in
the sense that it changes all nodeAtPoint existent methods to be
nodeAtArea ones, and of course their method bodies were changed where
needed.

The difference is silly, but exists. We have just to decide how to
proceed from that point on. Whatever direction is decided, I am up to
join efforts with Grace to fix it."

In summary, first patch keeps passing a "point" plus a new "padding
rect" to build up the HitTestResult instance. The later makes any
point passed to fallback to a IntRect(point, IntSize(1,1)) and changes
the rest of the HitTest system to be rect-based (see more details in
#c7).

Comments welcomed.

Regards

On Sun, Jun 6, 2010 at 3:40 PM, Antti Koivisto  wrote:
> On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt  wrote:
>
>> I really don't think hit testing needs to be modified to get what you want.  
>> You can do a scattershot sampling using multiple candidate points within the 
>> rect and apply whatever heuristics you want to choose a node.  I'm also not 
>> convinced that we should be complicating core hit testing code in this way, 
>> since I suspect this is one of those areas where mobile platforms will each 
>> want to do their own slightly different thing anyway.
>
> The problem with hit testing by multisampling is that it is
> ridiculously slow. You need to take at least a dozen samples for
> decent results. With a complex document on a mobile platform doing
> those can take several hundreds of milliseconds. That is pretty far
> from what is needed for good responsiveness. I think area hit testing
> would make a lot of sense.
>
> With WebKit2 it might actually be a good idea to track all event
> sensitive areas in the document. This way at least partial (no
> hit/maybe hit) testing could be done entirely in the UI process side.
>
>
>  antti
>
>> dave
>> (hy...@apple.com)
>>
>> _______
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>



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

Re: [webkit-dev] problem with css :focus

[Antonio Gomes (:tonikitoo)]

Note you need to call both setActive and setFocused of FocusController
for it to work for you.

In gtk:

static void webkit_web_view_grab_focus(GtkWidget* widget)
{
  ...
  FocusController* focusController = core(webView)->focusController();
  focusController->setActive(true);
  if (focusController->focusedFrame())
focusController->setFocused(true);
  else
focusController->setFocusedFrame(core(webView)->mainFrame());
}

On Wed, Jun 9, 2010 at 8:24 AM, Alex Vazquez  wrote:
> Right, the problem is the frame not being focused. That's why changing the
> condition to just e->document()->frame()->selection()->isFocused didn't work
> either.
>
> In the webkit/GTK port, it is focused, so we are trying to find the
> difference regarding to that in both ports. Maybe some GTK platform check
> ...
>
> Any further idea is greatly appreciated and i'll post back for reference if
> we find the fix.
>
> Thanks and kind regards,
>
> 2010/6/8 David Hyatt 
>>
>> isFocusedAndActive is asking if your frame is the focused frame and if the
>> window that contains your frame is also active.  I would guess that you are
>> not setting the state of your frames/windows correctly.  If your window is
>> considered inactive or if your frame is not considered focused, then :focus
>> is not going to be honored.
>> dave
>> (hy...@apple.com)
>> On Jun 8, 2010, at 3:33 AM, Alex Vazquez wrote:
>>
>> Hello list,
>>
>> We're running a customized build of WebKit (actually a DirectFB port) and
>> we are experiencing problems with the css :focus pseudo-class. We use webkit
>> as GUI renderer and, when changing the focused element through JavaScript
>> (using the focus function), the style associated to the  :focus pseudo-class
>> is not applied. The attached page is our reduced testcase, it should show
>> two links, the first of them focused but it shows two unfocused links:
>>
>> 
>>
>>     
>>
>>     
>>
>>     body {
>>     color: #f00;
>>     background-color:#ddd;
>>     font-size:26px;
>>     }
>>
>>     div {
>>     float: left;
>>     padding: 50px;
>>     }
>>
>>     a, span {
>>     float:left;
>>     display:block;
>>     clear:both;
>>     }
>>
>>     a:focus {
>>     color:#f0f;
>>     }
>>
>>     
>>
>>     
>>
>>     function init() {
>>     document.getElementById("uno").focus();
>>     }
>>
>>     
>>
>>     
>>
>>     
>>     
>>
>>     http://www.webkit.org/";>WebKit
>>     http://nightly.webkit.org";>Nightly
>> Builds
>>
>>     
>>     
>>
>> 
>>
>>
>> The version with this problem is based on r58260 revision while a
>> previously one (with nearly the same adapted patches) based in r40084 worked
>> fine. We build webkit for an embedded MIPS processor and for x86 too. Both
>> versions show the undesired behaviour.
>>
>> Investigating through the WebKit code, we've found that applying the
>> following patch fixes the problem:
>>
>> --- a/WebCore/css/CSSStyleSelector.cpp    2010-06-04 13:35:19.0
>> +
>> +++ b/WebCore/css/CSSStyleSelector.cpp    2010-06-04 13:35:35.0
>> +
>> @@ -2428,7 +2428,7 @@
>>  break;
>>  }
>>  case CSSSelector::PseudoFocus:
>> -    if (e && e->focused() &&
>> e->document()->frame()->selection()->isFocusedAndActive())
>> +        if (e && e->focused())
>>  return true;
>>  break;
>>  case CSSSelector::PseudoHover: {
>>
>> That line was there since r40084 and it worked so we have some questions
>> about the patch:
>>
>> * Does it have any problem that we have overlooked?
>>
>> * Can someone with knowledge on the css component explain why the active
>> state of the selection is checked in that line? We also try to change that
>> check by e->document()->frame()->selection()->isFocused() but it didn't fix
>> it.
>>
>> Kind regards,
>>
>> --
>> Alejandro Vazquez Fente
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
>
> --
> Alejandro Vazquez Fente
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



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