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] 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 oli...@apple.com wrote:


 On May 7, 2014, at 2:41 PM, Rik Cabanier caban...@gmail.com 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 ander...@apple.com 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 wei...@apple.com wrote:
 Or better yet, enable it for all ports on ToT.

 -Sam


 On Oct 4, 2013, at 11:03 AM, Timothy Hatcher timo...@apple.com 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 mmaxfi...@apple.com 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 hugo.l...@openbossa.org wrote:
 On Fri, Sep 13, 2013 at 3:00 PM, Anders Carlsson ander...@apple.com wrote:

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

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

 Yes, in fact we got some API from them.

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

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

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

 Maybe we would need a similar build policy for WebCore?

 But it sounds like you're suggesting that Nix port's maintainers will be
 responsible for making any code changes necessary to support
 WebCore/WebKit/WebKit2 refactoring?

 Yes, this is the idea, is our concern to keep our code working.

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

 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 rn...@webkit.org 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

[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 div,
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 div boundary. By then, 'autoscroll' takes place
(see WebCore/page/AutoscrollController.cpp/h), and scrolls the outter
div. 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] 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 simon.fra...@apple.com wrote:
 On Aug 16, 2013, at 2:45 PM, Antonio Gomes toniki...@webkit.org 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 div,
 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 div boundary. By then, 'autoscroll' takes place
 (see WebCore/page/AutoscrollController.cpp/h), and scrolls the outter
 div. 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

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
mario.pr...@samsung.com 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 mario.pr...@samsung.com
  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
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev


 ___
 webkit-dev mailing 

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 mrobin...@webkit.org wrote:
 On Thu, Jul 25, 2013 at 7:01 AM, Antonio Gomes toniki...@webkit.org 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] 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 bjone...@adobe.com 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]

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 oli...@apple.com 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 toniki...@webkit.org 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 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

Re: [webkit-dev] Feature announcement: WebCL

[Antonio Gomes]

On Tue, Apr 30, 2013 at 8:14 PM, Benjamin Poulain benja...@webkit.orgwrote:

 On Tue, Apr 30, 2013 at 5:10 PM, Antonio Gomes toniki...@webkit.orgwrote:

 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]

On Tue, Apr 30, 2013 at 8:33 PM, Geoffrey Garen gga...@apple.com 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 Wed, May 1, 2013 at 8:41 PM, Oliver Hunt oli...@apple.com wrote:


 On May 1, 2013, at 5:29 PM, Antonio Gomes toniki...@webkit.org 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

[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 onealbl...@yahoo.com 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 timb...@adobe.com 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.

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


On Tue, Apr 9, 2013 at 8:01 AM, Jesus Sanchez-Palencia je...@webkit.orgwrote:

 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 onealbl...@yahoo.com:
  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] 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 onealbl...@yahoo.com 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] 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 joc...@chromium.org 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)
 sb...@microsoft.com 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 pe...@chromium.org 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 zol...@webkit.org wrote:


 Cool! Congratulations Caio!

 On Mon, Oct 8, 2012 at 2:20 PM, noam.rosent...@nokia.com 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 dpra...@chromium.org wrote:

 +1 :).

 On Thu, May 10, 2012 at 12:01 PM, Ojan Vafai o...@chromium.org wrote:
  That's a great milestone. Congratulations!
 
  On Thu, May 10, 2012 at 8:43 AM, Dominik Röttsches
  dominik.rottsc...@intel.com 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 dominik.rottsc...@intel.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
 
 ___
 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]

(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 jma...@rim.com 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 ashodnakash...@yahoo.com
 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

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 gga...@apple.com 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

[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 aba...@webkit.org wrote:

 On Mon, Jan 30, 2012 at 2:35 PM, Robert Kroeger rjkro...@chromium.org
 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 gyuyoung@samsung.comwrote:

 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 bfulg...@webkit.org 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] 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] 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 j...@chromium.org wrote:

 Hi Folks,

 You may know the css property -webkit-tap-highlight-color which is now
 only supported by Safari on iOS. (Please see 
 herehttp://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] A Media Element ie: Audio or video, 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 gga...@apple.com 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 kyounga...@gmail.com 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 dglaz...@chromium.org
  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]

Hi Darin. Few comments inlined.

On Sun, Jun 19, 2011 at 2:31 PM, Darin Adler da...@apple.com 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] 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 e...@webkit.org wrote:

 On Sun, Jun 19, 2011 at 11:31 AM, Darin Adler da...@apple.com 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] 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 aba...@webkit.org wrote:

 On Fri, Jun 17, 2011 at 11:13 PM, Peter Kasting pkast...@chromium.org
 wrote:
  On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth aba...@webkit.org 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]

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
mustaf.h...@gmail.comwrote:

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

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

On Tuesday, June 14, 2011, Mustafizur Rahaman mustaf.h...@gmail.com 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 toniki...@gmail.com 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] 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]

 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]

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 e...@chromium.org wrote:

 On Thu, May 26, 2011 at 3:54 PM, Eric Seidel e...@webkit.org 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
mustaf.h...@gmail.comwrote:

 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
 style type=text/css
 body.rahaman{
 font:30px courier;
 }
 /style
 body class=rahaman Rahaman /body

 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 aba...@webkit.org 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 rjkro...@chromium.org
 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 pfeld...@chromium.orgwrote:

 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 e...@webkit.org 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 mrobin...@webkit.orgwrote:

 On Fri, Apr 1, 2011 at 7:06 AM, Adam Roben aro...@apple.com 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 da...@apple.com 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 o...@chromium.org 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 o...@chromium.org 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 toniki...@gmail.comwrote:

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

[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 xujian...@gmail.com:
 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]

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 e...@webkit.org 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 rn...@webkit.org wrote:

 On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt hy...@apple.com 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 e...@webkit.org 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] 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 e...@webkit.org 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 toniki...@gmail.com 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 e...@webkit.org 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 rn...@webkit.org wrote:
 
  On Fri, Dec 3, 2010 at 1:37 PM, David Hyatt hy...@apple.com 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 e...@webkit.org 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] 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 wsiegr...@apple.com 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] 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 x...@gnome.org wrote:
 On Wed, Nov 3, 2010 at 1:20 PM, Fedor Kryukov y...@mail.ru 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 y...@mail.ru 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]

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 bweinst...@apple.com 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

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 esei...@google.com 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

[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

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 ryosuke.n...@gmail.com wrote:
 On Wed, Oct 27, 2010 at 2:17 PM, Antonio Gomes toniki...@gmail.com 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] 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 abe...@inf.u-szeged.hu 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 a...@webkit.org 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  luiz.agost...@openbossa.org

 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  luiz.agost...@openbossa.org
 +
 +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  mrobin...@igalia.com

  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 RefPtrNodeList 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] 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 aba...@webkit.org 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 e...@webkit.org 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 to...@chromium.org 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 a...@milowski.org wrote:
 On Tue, Jul 20, 2010 at 4:11 PM, Darin Adler da...@apple.com 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] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

 In the later sample output, note that it did not reach body , whose
 boundary obvious intersects any possible given Z rect. That would
 happen if the div 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 body.

 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 dhyatttonikitoo: i need to talk to some people here
at apple too
Jun 16 18:04:12 dhyatttonikitoo: we've gotten a request for e.g.,
all the nodes that intersect the visible rect
Jun 16 18:04:16 dhyattthat's a common desire
Jun 16 18:04:20 dhyattthis api kind of does that
Jun 16 18:04:29 dhyatti 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] 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 a...@milowski.org 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)]

Hi Simon. Thank you join the discussion!

On Tue, Jul 6, 2010 at 1:46 AM, Simon Fraser simon.fra...@apple.com 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 [p , div, body]. For another hypothetical rect
 Z and the same html Y, nodesFromRect might return [span,div]

 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 body , whose
 boundary obvious intersects any possible given Z rect. That would
 happen if the div 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 body.

 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 [p , div, body]. For another hypothetical rect
Z and the same html Y, nodesFromRect might return [span,div].

In the later sample output, note that it did not reach body , whose
boundary obvious intersects any possible given Z rect. That would
happen if the div 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 body.

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 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 koivi...@iki.fi wrote:
 On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt hy...@apple.com 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

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

tonikitoo dhyatt, david, could you join the discussion about rect
based hit test on bug 40197
dhyatt just need me to make a decision on the right naming?
tonikitoo 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
dhyatt huge fan of grace's approach i have to say
dhyatt very minimal on how intrusive it is
tonikitoo right, it is simpler and and works equally
dhyatt yeah i kind of like the idea of slop around the point as the
approach though
dhyatt rather than patching every method name
dhyatt 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)
toniki...@gmail.com 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 koivi...@iki.fi wrote:
 On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt hy...@apple.com 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] Proposal: Rect based HitTest for a better touch experience

[Antonio Gomes (:tonikitoo)]

Hi,

As most of you have experienced, the precision of a mouse click on
Desktop applications, including Web browsers, is much higher than the
precision of a touch tap on a mobile device. It is not a new problem,
and many solutions have been proposed to improve that situation. One
of the common solutions is to make a small target’s tap-sensitive area
larger, invisibly, than the visible target itself. Of course, it would
not work on a mobile Web browser, since it'd end up breaking the
desired layout of any non-simple Web site.

Mozilla has addressed this problem by implementing the SmartTap
feature [1]. The solution is simple: a nodesFromRect method is
available for applications {fennec, firefox, etc}. As the name
implies, given a rect (corresponding to tapped area), it returns a
list of candidate mouse clickable target nodes for the tap. This
list is sorted by z-order, larger intersection area, most visited (in
case of links), etc. Call sites can then pick the first element on the
list, or use any different heuristic to choose the target.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=489127

After some initial research, mostly understanding the HitTest system
of WebCore, I am sure we can provide something similar as a cross
platform solution for the problem.

For the moment, my plan is to use better hit testing to make it easier
for users to click  focus hyperlinks and input fields. For that, the
HitTest system would have to be modified to receive a Rect as input,
instead of a Point. It would also have to hold a list of possible
target candidate nodes, instead of only a single target node as it
does currently. In deep, the many ::nodeAtPoint implementations would
have to be adjusted to work with a Rect, not a Point, and probably
renamed to something similar to nodesAtRect. Much of the current
HitTest logic in RenderLayer would not need changes, though.

To keep the current mouse behavior (which is clearly point-based), we
could just pass rects with width and height equal to 1, so a Rect(x,
y, 1, 1) would behavior equally or very similarly to Point(x, y).

Before going this way, I would like to know of any known problem or
show stoppers.

Cheers,

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

Re: [webkit-dev] HitTest'ing scrollbars

[tonikitoo (Antonio Gomes)]

Hi,

just sharing a few words from hyatt on IRC:

May 17 00:07:00 dhyattyeah your analysis is right
May 17 00:08:34 dhyattthat RenderLayer comment is about dragging
the map in google maps
May 17 00:08:41 dhyattso that would be the thing to test to make
sure it doesn't break
May 17 00:09:47 dhyatttonikitoo: but yeah it's weird
May 17 00:10:25 tonikitoo dhyatt, I am think is more inconsistent is
the fact that we fired mousedown, but do not fire click or mouseup
May 17 00:10:41 tonikitoo while firefox, for example, fires the
first and the later
May 17 00:10:41 dhyattyeah,  i don't really have strong opinions
other than don't break the web please :)

On Sun, May 9, 2010 at 11:07 PM, Darin Adler da...@apple.com wrote:
 I think your analysis is right, but I’m not sure. Hyatt did a lot of the 
 scrollbar work for Windows that was later imitated on the other platforms. 
 Maybe he can comment on this?


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

[webkit-dev] Help with reviewing Spatial Navigation patches

[tonikitoo (Antonio Gomes)]

Hi,

As part of my (spare-time) effort to keep developing the Spatial
Navigation [1], I've been getting great reviewing support from Simon
Fraser and Kenneth Christiansen, but lately the number of pending
review patches increased a bit. There are on my plate patches from
polishment work to real bug fixes and feature completeness. So there
some very easy patches to review, like:

-polishment work:
* bug 38584 - Spatial Navigation: use data url in layout
* bug 38488 - Spatial Navigation: create a getter for the fudgeFactor
* bug 37633 - Spatial Navigation: use a static var in maxDistance
method ( SpatialNavigation.h ) -- one liner!

- improvements on the feature test covarege:
* bug 38585 - Spatial Navigation: add a layout test which runs with
Frame Flattening ON

- preparation for feature implementation:
* bug 37803 - Spatial Navigation: adapt the logic of
{deep}findFocusableNodeInDirection to do traversal starting from Node*
not Document*
For this one I even added a comment in the bug with a detailed
explaination about the changes [2], so a reviewer does not need to
know the feature code in deep to review it.
* Spatial Navigation: refactor hasOffscreenRect to work with
scrollable content -- has a patch , but not set r? because it depends
on bug 36463, which depends on 37803.

... as well as not so trivial patches to be reviewed:

- feature implementation:
* bug 36463 -  Spatial Navigation: make it work with focusable
elements in overflow content -- depends on the former preparation bug
* bug 37153 -  Spatial Navigation: add support to input type=text
and textarea -- has a patch, but needs polishment to request
review.

Reviewers, could you please help with that?

Thank you in advance

[1] https://bugs.webkit.org/showdependencytree.cgi?id=18662hide_resolved=0
[2] https://bugs.webkit.org/show_bug.cgi?id=37803#c5


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

Re: [webkit-dev] Help with reviewing Spatial Navigation patches

[tonikitoo (Antonio Gomes)]

 - preparation for feature implementation:
 * bug 37803 - Spatial Navigation: adapt the logic of
 {deep}findFocusableNodeInDirection to do traversal starting from Node*
 not Document*
 For this one I even added a comment in the bug with a detailed
 explaination about the changes [2], so a reviewer does not need to
 know the feature code in deep to review it.

 * Spatial Navigation: refactor hasOffscreenRect to work with
 scrollable content -- has a patch , but not set r? because it depends
 on bug 36463, which depends on 37803.

... I forgot to write: that is bug 38590.

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

[webkit-dev] HitTest'ing scrollbars

[tonikitoo (Antonio Gomes)]

Hi.

While working on bug 16809 (Clicking a scrollbar blurs the currently
focused element), a couple of questions raised about the current
behavior of mouse clicks on scrollbars.

On ports that do *not* use platform/native widgets for rendering
scrollbars (including Qt, Windows, Chromium):

1) clicking on a frame scrollbar will hitTest WebCore at the position
of this main frame scrollbar but won't set HitTest::scrollbar, while
hitTest'ing an in-frame scrollbar (e.g. a scrollbar of a scrollbable
div) does set it. Is this behavior by design?

Due to that, snippets like the following are needed in certain cases:

EventHandler::handleMousePressEvent(PlatformMouseEvent)
{
(...)
  FrameView* view = m_frame-view();
Scrollbar* scrollbar = view ?
view-scrollbarAtPoint(mouseEvent.pos()) : 0;
if (!scrollbar)
scrollbar = mev.scrollbar();
(...)
}

It seems strange that we have to rely on scrollbarAtPoint of FrameView
and fallback to HitTest::scrollbar . Maybe the former should not be
necessary if HitTest::scrollbar got set properly.


2) Clicking on main frame scrollbars will set HTML as
HitTest::targetNode . This seems like an intentional behavior
according to the comment in the snippet below:

bool RenderLayer::hitTest(const HitTestRequest request, HitTestResult result)
{
(...)
  RenderLayer* insideLayer = hitTestLayer(this, 0, request, result, boundsRect,
result.point(), false);
  if (!insideLayer) {
// We didn't hit any layer. If we are the root
// layer and the mouse is -- or just was -- down,
// return ourselves. We do this so mouse events
// continue getting delivered after a drag has
// exited the WebView, and so hit testing over
// a scrollbar hits the content document.
if ((request.active() || request.mouseUp())  renderer()-isRenderView())
   {
  renderer()-updateHitTestResult(result, result.point());
  insideLayer = this;
   }
}
(...)

But due to that, some side effects like [1] shows up. I would like
to confirm if this is also an intentional behavior before marking bugs
as INVALID or WONTFIX.

3) HitTest'ing a frame scrollbar bar will dispatch, MouseDown event,
but not MousePress and MouseUp. It seems different from what other
vendors do currently (run this testcase in various browsers [2],
including not webkit based ones). Why this behaviour?

[1] https://bugs.webkit.org/show_bug.cgi?id=29484 ([Qt] Clicking on
the frame's scrollbar trigger a click event in the page.)
[2] https://bugs.webkit.org/attachment.cgi?id=20748


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

Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

[tonikitoo (Antonio Gomes)]

Hi,

 Eventually, I'd like to make --squash the default, but I want this to bake 
 and get some usage before flipping that switch.

 But I don't think this makes sense as a default to me. But maybe I use git 
 differently than everyone else… I don't do the whole branch-per-bug 
 business.

 I usually have one git commit per commit I plan to push to SVN (each with a 
 separate ChangeLog entry).

I am also on the same boat, so I do not thing --squash should be the
default. it would be against the current resulting action of git
push, git svn dcommit and svn commit.

Apart from that, great work!

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

Re: [webkit-dev] currentTime() and UTC time

[tonikitoo (Antonio Gomes)]

I agree with the fact that it should not rely on currentTime() as it
currently does. It is probably the root of bugs like
https://bugs.webkit.org/show_bug.cgi?id=31550 and many others.

On Fri, Apr 16, 2010 at 11:50 AM, Yong Li yong.li.web...@gmail.com wrote:
 Hi All

 The default implementation of JS Date is calling currentTime() (by
 jsCurrentTime()), so it assumes currentTime() returns current UTC time, and
 system UTC time can be changed. However, currentTime() is also used in most
 cases as a system tick count, which means it should always be monotonically
 increasing. I guess we should remove the dependency on currentTime() from JS
 Date to fix the confliction.

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

[webkit-dev] Gtk debug bots (32 / 64 bit) are out of space

[tonikitoo (Antonio Gomes)]

clean up needed!


http://build.webkit.org/builders/GTK%20Linux%2032-bit%20Debug/builds/4614/steps/compile-webkit/logs/stdio
(...)
DerivedSources/JSSVGZoomEvent.lo DerivedSources/JSWebSocket.lo
/bin/mkdir -p ./.deps/DerivedSources
ranlib: .libs/libWebCoreJS.a: No space left on device
make[1]: *** [libWebCoreJS.la] Error 1
make[1]: Leaving directory
`/home/slave/webkitgtk/gtk-linux-64-debug/build/WebKitBuild/Debug'


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

Re: [webkit-dev] Question about WML support

[tonikitoo (Antonio Gomes)]

::sharedTimerFiredInternal()  Line145 C++
 WebCore::ThreadTimers::sharedTimerFired()  Line125 C++
 WebCore::WebKitTimer::onnotify()  Line65 + 0x8 Bytes C++
 ___
 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] AbsoluteClippedOverflowRect return empty IntRect

[tonikitoo (Antonio Gomes)]

Hey all.

I am facing a strange issue while trying to the get repaintable rect
of a given Node* object. In my code I am doing something like:

(...)
ASSERT(node);
node-renderer()-absoluteClippedOverflowRect();
(...)

, where node is a valid reference to an a in the following simple
html sample in http://pastebin.ca/1850582 (see id=it).

In the sample, node is an offscreen anchor in a scrollable div,
and calling absoluteClippedOverflowRect returns an empty IntRect to
me. If I scroll until it (the node whose id is it) gets visible, and
then trigger my snippet code above it returns a valid value. Also, by
doing static_castElement*(node)-getRect() I get the same valid rect
returned.

I am wondering if it is an expected behavior or a bug?

Regards


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