Re: [webkit-dev] Unmaintained feature list

[Julien Chaffraix]

> Sounds like a great idea:
> http://trac.webkit.org/wiki/UnmaintainedFeatureList

Thanks for starting this.

Added CSS Grid Layout to the list as I don't think I would be able to
do merges back. I would be more than happy to remove the code if
people feel the need.

If anyone wants to take over, I would be more than happy to provide
any needed assistance. The opened bugs on bugzilla should be an
accurate representation of the amount of work remaining **

Thanks,
Julien

** The specification is still in flux so consider this as an estimate
not an absolute measurement.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] [Coding Style] Clarification about multiple assignments on one line

[Julien Chaffraix]

Hi WebKit folks,

over several reviews, I have been saying that the following line is a
coding style violation:

firstVariable = secondVariable = 0;

For a concrete example, the computePreferredLogicalWidths uses the
following pattern:

minWidth = maxWidth = max(minWidth, tableLogicalWidth.value());

My justification is that those are 2 statements and thus should be on
2 lines per "Each statement should get its own line.". Some people
consider that the previous rule doesn't apply to multiple assignments
on one line and that such code is fine by the book.

What do people think?

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

Re: [webkit-dev] Exposing Mouse Simulation event API from webkit

[Julien Chaffraix]

webkit-dev is reserved for discussion about WebKit development. Your
question seems to be about some changes you want to do locally so it
belongs to webkit-help
(https://lists.webkit.org/mailman/listinfo/webkit-help).

> I have done changes to expose the mouse simulation API from webkit.
> Everything is working fine. But I have a issue I have done changes in
> webpage.message.in file .

There is no such file in WebKit:

find . -name "*.in"|grep webpage

If you are adding new files, it's difficult for anyone to know what
you did and you are more or less on your own. If you really want some
help, please send a lot more details to webkit-help about what you are
doing if you want to get some good quality answer.

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

Re: [webkit-dev] Need information regarding CSS3 extension

[Julien Chaffraix]

> I want to write CSS3 extension, I don’t have any idea about it. I saw
> the code related to css in webkit but I am getting difficulties to map
> it. I. want to develop own tag like webkit-animation. Please let
> me know if anyone having any idea about CSS extension.

This question is not for webkit-dev unless you intend to submit your
extension (in which case it would need a standard and some vendors'
buy-in but that's orthogonal). Please ask any follow up question to
webkit-help.

The best way to add new CSS _properties_ (not tags which are an HTML
concept) is to follow the example of other changes doing exactly that
e.g [1] and [2]. What is of interest to you are the changes in
WebCore/css/ and WebCore/rendering/style, the rest of the changes is
the logic required to render the new properties.

Hope it helps,
Julien

[1] http://trac.webkit.org/changeset/126105
[2] http://trac.webkit.org/changeset/118853
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding CSS3 background-position offsets.

[Julien Chaffraix]

>> On Mon, Dec 3, 2012 at 12:59 PM, Dirk Schulze  wrote:
>> Depends on the future. But for such a small patch, a new flag seems to be 
>> overdone. I looked into the patch, and adding the flag caused more code, 
>> then the actual feature (even if the computed style is missing). I believe 
>> we should remove the flag ASAP. Flags are for bigger new features of 
>> features that likely will change IMO. Both seems not to be the case for 
>> background-position.
>>
>> See http://trac.webkit.org/wiki/AddingFeatures
>>
>
> "The policy for adding new (major) features to WebKit is:"
>
> major says everything IMO. background-position is not a major feature.

As the one who asked for this flag, the main reason is to avoid
breaking feature detection until all the bits have been landed: most
features land the CSS side first and then implement the rendering side
so that they can be properly tested and reviewed. Also as Benjamin
pointed out, this gives port maintainers the option to ignore the
feature until it is ready for prime time. Here the flag was also
thought as covering the full spec, not just one property.

> However, to stay at the topic: Is there anything blocking 
> 'background-position' with the new syntax? Any objections to remove the 
> flags? If yes, I would like to know more about the problems.

You have just mentioned that we need to transition some other
properties to the new syntax. For coherency, I would rather avoid
removing or enabling the flag until this is done.

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

Re: [webkit-dev] r- your own patches [was: Re: RenderArena: Teaching an old dog new tricks]

[Julien Chaffraix]

> Seconded. I also think only the one who submitted the patch can clear
> the r? flag. Others should NOT do that, please, even you are a
> reviewer. You can r- the patch if you believe it is bad.

I disagree with that. You seem to think that patches falls into either
good or bad. However the reality is more complex and there are levels
of goodness and badness. I use r- for patches that I really think are
not in the right direction or shouldn't be landed: it is a statement
in this direction. Clearing the flag is for patches that are close
enough but still not up to our standards and that I want to kick off
the review queue.

This is my reasoning on that and other people likely have different
views. However I don't think it's unreasonable to clear the flag
instead of r-'ing in some contexts.

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

Re: [webkit-dev] New runtime setting: css3TextDecoration

[Julien Chaffraix]

On Tue, Aug 14, 2012 at 12:06 PM, Ryosuke Niwa  wrote:
> On Tue, Aug 14, 2012 at 11:56 AM, Julien Chaffraix
>  wrote:
>>
>> > I don't think it's appropriate to add settings for CSS features that are
>> > under development,
>> > for a number of reasons:
>> >
>> > * If we did this for every feature, we'd end up with hundreds of
>> > Settings.
>> > * Traditionally, Settings don't tend to get removed, resulting in an
>> > ever-accumulating number of Settings.
>>
>> ENABLE has a slightly better track of record but I don't think we
>> should push back on runtime flags just because of that.
>
>
> Having a runtime flag incurs runtime cost.

Performance is one of our core goal and any WebKit hacker will agree
that it's important. Here you forgot to mention that we care about is
if it has a *notable* runtime cost in which case there is no proof
that the current flags incur such a cost. We know of patches from
feature under a flag that have been rolled out because of measurable
performance regression [1] so we would know if that was the case. It's
also better to catch such slow-down earlier rather than later.

The most significant performance impact is probably the increase in
the binary size which I won't deny and don't have insights into.

>> Having tons of #ifdef's is a lot more worrying from my perspective,
>
>
> Having a runtime flag is significantly worse in that it affects end users.
> Having a compile flag is a painful for developers but has absolutely zero
> cost for end users.

You will need to define "end users" here. WebKit is meant to be
embedded and as such you can think of different end users. People
embedding WebKit are expected to know about our flags. Browsers' end
users are only impacted insofar as browsers vendors implement the
right UI and this claim is making strong assumption about how this is
done.

Now, both options with respect to the flag have their trade-offs but
there seems to be majority in favor of ENABLE flags. Brushing aside
one option based on FUD is not really something I am supportive of
though.

Thanks,
Julien

[1] for example, see https://bugs.webkit.org/show_bug.cgi?id=76064
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New runtime setting: css3TextDecoration

[Julien Chaffraix]

> I don't think it's appropriate to add settings for CSS features that are 
> under development,
> for a number of reasons:
>
> * If we did this for every feature, we'd end up with hundreds of Settings.
> * Traditionally, Settings don't tend to get removed, resulting in an 
> ever-accumulating number of Settings.

ENABLE has a slightly better track of record but I don't think we
should push back on runtime flags just because of that. Having tons of
#ifdef's is a lot more worrying from my perspective, on top of not
being able to build / test the feature before you toggle the flag on
one platform (with all the surprises coming from platform differences
when a port maintainer decide to do so).

> * If your feature is protected by an ENABLE flag, vendors that want to ship 
> release software can turn it off.

That's true, except that the original thread didn't mention any form
of feature flag [1]. Nobody objected at the time and thus patches that
implemented part of the spec arrived on bugzilla: prefixed but not
protected by any flag.

Due to the bar to landing such a change and exposing directly, I
requested that a feature flag be introduced so that patches could be
split into atomic pieces that can be reviewed one at a time (and also
checking that the testing is appropriate).

This update isn't about bringing a discussion about ENABLE vs runtime,
more about mentioning that there will be a new flag contrary to what
was said previously. There is definitely a trend to use runtime flags
on core features lately (region, grid, custom filters...) sometimes
along with ENABLE flags. This should be discussed separately.

Thanks,
Julien

[1] http://lists.webkit.org/pipermail/webkit-dev/2012-July/021715.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using ref tests for repaint bugs

[Julien Chaffraix]

>> I think this will be too fragile. It relies on the fact that a subsequent
>> paint won't obscure the repaint bug that you're trying to detect.
>>
>> I'm much rather we work towards detecting repaint bugs via dumping the
>> list of repaint rectangles. I don't think every test has to be a ref test.
>
>
> Don't the pixel tests face the same kind of risk, of a subsequent paint
> masking the repaint bug? Preserving this risk, but reducing the maintenance
> cost for the test is still an important improvement.

I second Simon's fragility argument. His solution is more viable,
platform agnostic and may even remove the need for dumping the pixel
in some cases.

Even if the existing harness has the subsequent paint issue, having
the pixels for the repaint test is one of the few cases where they are
useful IMHO (sometimes the exact area to repaint is a judgement call,
see e.g. the differences between the platforms). Also there are
several of techniques to make the pixel dump platform-agnostic which
could minimize the number of baselines.

On top of that, if both your test case and reference hit the same bug,
it nullifies the value of your test - this may be a theoretical issue
though as pointed out in the pixel vs ref-test thread. I didn't
understand from your proposal how you would avoid this risk.

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

Re: [webkit-dev] Deprecating features guideline wiki

[Julien Chaffraix]

>>> BTW, the page at  seems
>>> to be using "deprecate" in the sense of "remove entirely". Is that what is
>>> meant? If so, I think it would be helpful to change the wording to "removing
>>> features". In non-Web contexts, deprecate often means a step short of
>>> removal.
>>>
>>> I agree that "Removing features" is clearer and more to the point :).
>>> When to deprecate features in the sense of "we recommend you use this
>>> other feature instead" is an entirely different conversation.

I will make the change as people seem to prefer talking about removal
than deprecation.

>>> Now that I look closer, I see that it says:
>>>
>>> "Deprecating a feature means we will remove it in the future. Deprecation
>>> is not meant as a usage metric collection or to assess web-developers'
>>> reactions."
>>>
>>> This seems to imply that there actually is a step of deprecation that
>>> comes prior to removal. What exactly is this step? How are features supposed
>>> to be marked deprecated? What is the effect of being deprecated, if any,
>>> other than future removal? Does anyone who was at the session know the
>>> answer?

This is unfortunately something that we didn't discuss much. Our
current way is to display something on the console as Ryosuke pointed
out, which is easy but likely not optimal.

>> I'd assume this is something like outputting a warning in the
>> console. (Disclaimer: I didn't attend this session.)
>>
>> That sounds plausible, but I'm hoping to hear from someone who attended
>> the session to say for sure. If "deprecate" means console warning, followed
>> by removal later, then I'd suggest we go straight to removal.

I have one issue with that. First this proposal assumes that the
feature is not exposed in someone's API. For such features, we will
need to have a deprecation step as it needs to be removed from every
vendors API.
More to the point, deprecating gives us a safety net in case we missed
something during our data gathering (an example I can think of are
intranets or internal apps that may be using the feature).

> Outputting console warnings prior to a feature removal appears to be a
> common practice (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=749920).
> I'm also afraid that not giving any advance notice for features that have
> some users like mutation events might be perceived badly by developers.
>
> On the other hand, I'm certain we don't need to output console warnings if
> we're removing features nobody uses (e.g. support for khtml prefixes for
> recently added CSS properties).
>
> So we probably can't (and shouldn't) make a unilateral policy here.

Seems like a good balance to give some leeway on whether we should
have a deprecation step or not.

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

[webkit-dev] Deprecating features guideline wiki

[Julien Chaffraix]

Hi WebKittens,

following the talk about "Deprecating (web-facing) features and vendor
prefixing" [1], we decided to create a guideline covering new
deprecations or un-prefixing [2]. The rationale is that this will
avoid a lot of the mistakes that we have made in the previous
deprecations and that wisdom could help newcomers understand the pain
points.

The current page is a draft compiled from the meeting notes so any
discussions or editions are welcome!

Thanks,
Julien

[1] http://trac.webkit.org/wiki/Deprecating%20features%20and%20vendor%20prefixes
[2] https://trac.webkit.org/wiki/DeprecatingFeatures
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] handling failing tests (test_expectations, Skipped files, etc.)

[Julien Chaffraix]

>>> If there's consensus in the mean time that it is better on balance to
>>> check in suppressions, perhaps we can figure out a better way to do
>>> that. Maybe (shudder) a second test_expectations file? Or maybe it
>>> would be better to actually check in suppressions marked as REBASELINE
>>> (or something like that)?
>>
>> That sounds quirky as it involves maintaining 2 sets of files.
>>
>> From my perspective, saying that we should discard the EWS result and
>> allow changes to get in WebKit trunk, knowing they will turn the bots
>> red, is a bad proposal regardless of how you justify it. In the small
>> delta where the bots are red, you can bet people will miss something
>> else that breaks.
>>
>
> As Ryosuke points out, practically we're already in that situation -
> from what I can tell, the tree is red virtually all of the time, at
> least during US/Pacific working hours. It's not clear to me if the EWS
> has made this better or worse, but perhaps others have noticed a
> difference. That said, I doubt I like red trees any more than you do
> :)

I wasn't talking about the tree's status quo here as it shouldn't
impact the discussion. Just because the tree is red, doesn't mean it's
the right thing (tm) to just drop the towel and make it more red (even
if we seem to agree on the badness of that :)).

To add some thoughts here, saying that the tree is red covers several
states (failing tests, not building...) and IMHO the EWS has at least
helped on the building side. As far as the tests goes, a lot of
platform differences are unfortunately uncovered on the bots.

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

Re: [webkit-dev] handling failing tests (test_expectations, Skipped files, etc.)

[Julien Chaffraix]

> In my ideal world, you would be able to get updated baselines *prior*
> to trying to land a patch. This is of course not really possible today
> for any test that fails on multiple ports with different results, as
> it's practically impossible to run more than a couple of ports by
> hand, and we don't have a bot infrastructure to help you here.

That would be the best outcome indeed, however that would more or less
require all the EWS to be able to run the tests (including pixel tests
for the platforms that enable them).

> 3) the current tool-of-the-day for managing rebaselining,
> garden-o-matic, is much better suited to handling the "unexpected"
> failures on the bots rather than the "expected" failures you've
> introduced.

You could see it the other way. How could we make garden-o-matic
handle newly added suppression better? Maybe some new sub-tool listing
the newly added suppressions would help? Ignore the suppressions added
XX hours ago?

Your issue seems to be suppressions sticking into the tree not
strictly suppressing in itself. Our current tool (garden-o-matic)
handles failures a lot better than it handles suppressions.

> If there's consensus in the mean time that it is better on balance to
> check in suppressions, perhaps we can figure out a better way to do
> that. Maybe (shudder) a second test_expectations file? Or maybe it
> would be better to actually check in suppressions marked as REBASELINE
> (or something like that)?

That sounds quirky as it involves maintaining 2 sets of files.

>From my perspective, saying that we should discard the EWS result and
allow changes to get in WebKit trunk, knowing they will turn the bots
red, is a bad proposal regardless of how you justify it. In the small
delta where the bots are red, you can bet people will miss something
else that breaks.

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

Re: [webkit-dev] Head-ups: massive TEXT rebaselining

[Julien Chaffraix]

Hi everyone,

> I will land https://bugs.webkit.org/show_bug.cgi?id=75568 tomorrow to
> give enough time for people to react. This makes us lazily allocate
> layers when we get layout overflow. The upside is a good speed-up in
> painting / hit-testing and (likely) some memory improvement but it
> also means that 100+ tests will need a new baseline. I have tried to
> skip those I know about in the different platforms but I may have
> forgotten severals.

The patch did land yesterday but I reverted it due to one hidden bug.
This may confuse certain tools (I had an issue with garden-o-matic
picking up the TEXT failures due to the patch one day after) so beware
if you intent to rebaseline.

An updated patch was just attached on the bug and will be landed upon
review (hopefully next week). To avoid spamming webkit-dev further, I
will post the updates on the bug.

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

[webkit-dev] Head-ups: massive TEXT rebaselining

[Julien Chaffraix]

Hi everyone,

TL;DR: If you don't maintain a bot or look at render tree dumps, I
guess this is not interesting to you.

I will land https://bugs.webkit.org/show_bug.cgi?id=75568 tomorrow to
give enough time for people to react. This makes us lazily allocate
layers when we get layout overflow. The upside is a good speed-up in
painting / hit-testing and (likely) some memory improvement but it
also means that 100+ tests will need a new baseline. I have tried to
skip those I know about in the different platforms but I may have
forgotten severals.

Here is the typical diff you should see:

--- 
/home/jchaffraix/Sources/WebKit/Source/WebKit/chromium/webkit/Debug/layout-test-results/fast/block/margin-collapse/103-expected.txt
+++ 
/home/jchaffraix/Sources/WebKit/Source/WebKit/chromium/webkit/Debug/layout-test-results/fast/block/margin-collapse/103-actual.txt
@@ -30,10 +30,12 @@
   RenderText {#text} at (0,1) size 68x18
 text run at (0,1) width 68: "Your Name*"
 RenderTextControl {INPUT} at (325,27) size 184x22
[bgcolor=#FF] [border: (2px inset #00)]
+  RenderBlock {DIV} at (2,3) size 180x16
 RenderBlock (floating) {SPAN} at (0,51) size 325x20 [color=#33]
   RenderText {#text} at (0,1) size 121x18
 text run at (0,1) width 121: "Your e-mail address*"
 RenderTextControl {INPUT} at (325,51) size 184x22
[bgcolor=#FF] [border: (2px inset #00)]
+  RenderBlock {DIV} at (2,3) size 180x16
 RenderBlock (floating) {SPAN} at (0,75) size 325x20 [color=#33]
   RenderText {#text} at (0,1) size 128x18
 text run at (0,1) width 128: "Your degree program*"
@@ -161,10 +163,6 @@
   RenderBlock {SPAN} at (0,16) size 600x20 [color=#33]
 RenderText {#text} at (245,1) size 110x18
   text run at (245,1) width 110: "\x{A9}2003 Kevin Davis"
-layer at (439,302) size 180x16
-  RenderBlock {DIV} at (2,3) size 180x16
-layer at (439,326) size 180x16
-  RenderBlock {DIV} at (2,3) size 180x16
 layer at (112,789) size 506x106 clip at (113,790) size 504x104
   RenderTextControl {TEXTAREA} at (0,517) size 506x106
[bgcolor=#FF] [border: (1px solid #00)]
 RenderBlock {DIV} at (3,3) size 500x16


The difference is only about layers being removed and RenderObject
being put back where they belong in the tree. There should be *no
change in the size of position of your RenderObject's* as they move.
Any change is a regression.

Feel free to pull me in on anything related to this rebaseline, I
would happily review or comment on any bug related.

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

Re: [webkit-dev] Making overflow clipping cheaper

[Julien Chaffraix]

> I'd be careful in how I approach this. Some platforms are going to want 
> compositing of overflow sections eventually for fast scrolling of those 
> sections. RenderLayer has become the natural tie-in point for GraphicsLayer 
> connections.

This is something I don't want to prevent.

That said it looks like my proposal (and current view on RenderLayer)
is going against the current situation where RenderLayer is the only
tie-in for GraphicsLayer. I don't know if splitting part of
RenderLayer is totally against the goal of having that part
composited. This just means that we need to change our paradigm and
enable more classes to be composited. Note that the proposal is rough
as there are different functionalities handled by RenderLayer
(repainting, hit testing, ...) that would need to be properly patched
for the new code path.

> In the future I envision overflow sections being more justified in having 
> layers by virtue of the fact that they would always be composited.

Hardware acceleration will definitely make us faster on some
operations. I am concerned by the fact that this does not solve our
core issue - namely RenderLayer is too generic for most cases and ends
up hurting performance. As pages become more complex, those pain
points will show up more and more (hit testing AFAICT is still done in
software thus will not gain from accelerated composition).

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

Re: [webkit-dev] Making overflow clipping cheaper

[Julien Chaffraix]

> Wouldn't it be better to implement better searching and paint-segmentation in
> RenderLayers then? It could also provide the same speed up for many other big
> cases.

That would be worth investigating more for sure (do you mind filing a
bug about it?). The paint search and segmentation algorithm is very
close between RenderLayer and most RenderObjects - tables being an
exception here as their structure enables better searching algorithms
- which means that it would benefit everyone. I haven't spend enough
time looking at generic scalability issues to say if there won't be
others more important bottlenecks.

I still see some upsides in attacking the reduced use case of overflow
clips independently of what you are proposing:
* RenderLayer has become a class handling far too many tasks so moving
some functionality out of it is good by itself.
* RenderObject has a better knowledge of its own structure, something
as generic as RenderLayer would not need to be aware of.

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

Re: [webkit-dev] Making overflow clipping cheaper

[Julien Chaffraix]

Hi Kenneth,

> As you probably are aware, some mobile ports paint their own overlay
> scroll indicators and do scrolling on the UI side (div overflow using
> a separate layer)
>
> Would it be possible to refactor this code in a way that it would
> simplify the code paths for these ports? maybe avoiding it altogether.
> Currently there is a lot of scrolling code in FrameView/ScrollView etc
> as well which we avoid call when delegatesScrolling() is true.

It looks like a neat goal but not something I had in mind to be frank.
I can see how we could use such a refactoring to simplify the
situation but I am not sure it would be wise to do it as part of the
same change: there are likely issues inside WebCore to this migration
without involving the WebKit/ layer.

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

[webkit-dev] Making overflow clipping cheaper

[Julien Chaffraix]

Hi fellow hackers,

while investigating some slowness related to painting big HTML tables
[1], RenderLayer's painting code path was pointed out as the source of
slowness. The problem stems from RenderLayer not being aware of the
peculiarities of the underlying RenderObject (RenderTableSection
implements painting using a binary search to find out which cells to
paint instead of trying all cells like RenderLayer).

Looking closely, it seems that the current code path is sub-optimal.
Adding an overflow clip on an element should be a cheap operation but
it ends up not being the case. This is because RenderLayer needs to
handle a lot of different use cases (transforms, opacity, z-index...)
[2]. I have spend some time thinking about how to make clipping a
cheaper operation and it looks like we could factor out most of the
scrolling logic (scroll offset, scrollbars, ScrollableArea) into a
light-weight object. This object would be orthogonal to RenderLayer.
The painting would go through "normal" (ie without layer) code path
that can already handle the clipping.

As a first step, I took over [3] (splitting ScrollableArea out of
RenderLayer) but would like to get some feedbacks whether this
proposal sounds like something we would like to do or there are some
core issues I missed.

Any comments welcome!

Thanks,
Julien

[1] https://bugs.webkit.org/show_bug.cgi?id=75001
[2] I would argue that RenderLayer itself is a big memory overhead but
that's another debate.
[3] https://bugs.webkit.org/show_bug.cgi?id=60305
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] [New feature] CSS Grid Layout

[Julien Chaffraix]

Hello WebKittens,

just a heads-up to say that Ojan, Tony and myself will start
implementing CSS Grid Layout [1] starting next week. Don't expect too
many updates at the beginning as we migrate from our current tasks to
this new feature.

CSS Grid Layout is a fairly new standard already implemented by
Microsoft in IE. The standard defines a grid on which to place
elements, not unlike tables but without the existing content structure
found in tables. If you are interested, the specification is pretty
small and explains in details the concepts.

Our plan is to add the new feature under the CSS_GRID_LAYOUT flag
during the implementation. The master bug for the feature is available
here [2] if you want to follow the implementation.

Comments and suggestions are welcome!

Thanks,
Julien

[1] http://dev.w3.org/csswg/css3-grid-align/
[2] https://bugs.webkit.org/show_bug.cgi?id=72220
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Is JSRetainPtr part of public WebKit API on some platforms?

[Julien Chaffraix]

> Julien Chaffraix asked me about API breakage in 
> <https://bugs.webkit.org/show_bug.cgi?id=71423> Remove all releaseRef 
> implementations except for RetainPtr.
>
> I realize now that JSRetainPtr.h is in the API directory. Is it part of the 
> public API on some platforms? I know it’s not on Mac.

As added in the bug in the meantime, I thought JSRetainPtr was part of
the public JSC API (which it is not...).

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

Re: [webkit-dev] Regarding OPENVG for GTK Build....

[Julien Chaffraix]

> I am trying to build OPENVG for GTK port.
> Can anyone provide me the details  for building OPENVG(which flag to enable 
> etc)

Please direct your questions to webkit-help (or webkit-gtk in this
case) as webkit-dev is related to the development of WebKit itself.

You should know that the OpenVG back-end is not fully upstreamed in
WebKit and has lacked some maintenance lately so don't expect an easy
build. More here [1] (which is still accurate AFAICT).

Thanks,
Julien

[1] https://lists.webkit.org/pipermail/webkit-dev/2011-July/017629.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] JavaScriptCore on Android

[Julien Chaffraix]

Hi,

This mailing list is for WebKit development not WebKit general
questions, use webkit-help for your next enquiries.

> I am trying to use JavaScriptCore in my Android application.

First, understand that the Android bindings in WebKit have been
removed (that includes JSC), thus I would advise asking the question
on an Android specific mailing list as people here obviously don't do
Android development (apart from some people).

> I build JavaScriptCore as a static library and I developed a JNI layer to
> access JSC methods.
> All my classes compile fine, but at the end of the build process (i guess in
> the linker action) i got some errors like "undefined reference
> to JSStringCreateWithUTF8CString".
> I was not able to correctly link my code with the JavaScriptCore static
> library.

I would double check that the symbols are present in your static
library before looking any further as it could be the root cause. If
that does not work, look for some help on the Android.mk side.

Hope it helps,
Julien
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposal: Commit messages should start with a one-line summary of the change

[Julien Chaffraix]

> I wasn't trying to add any complexity. My hope is that people are already 
> adding descriptions of their changes to their ChangeLog entries, like you do. 
> I was just trying to suggest a better way to organize that description.
>
> In my original email I noted two benefits of making this change:
>
> 1) It would make it much easier to understand at a glance what the change 
> actually does.
>
> 2) It would make many of our tools work better

Thanks for clarifying here. I would have equated 1) to the very
existence of ChangeLog which is supposed to give this background.

> I see (1) as the primary benefit, and (2) as a nice side-benefit.
>
>> Also you are implicitly constraining people to explain their change
>> with one-liners which IMHO is not a good constraint. I would rather
>> see good explanations than explanations that need to match a format.
>
> I'm not trying to constrain descriptions to one line. I think that would be 
> horrible in a lot of cases! I'm just suggesting that there be a one-line 
> summary at the top followed by a more detailed description below.

I said that it _implicitly_ added a constraint. Let me take an example
to make this point clear: if you have a 1.5 line long description, it
doesn't seem to make sense to split it in 2. I, maybe other people
too, would side with removing maybe important information for
shortness's sake. This sounds like the kind of case where the strict
format is harmful. It may be theoretical but it looks like a slippery
slope.

> (Note that our current ChangeLog template doesn't say that you should include 
> *any* description of the change.)

Indeed and I agree with you that this is wrong. However my feeling is
that reviewers usually asks for that information to be included as
part of the ChangeLog if it is not present.

My argument is against the format I would say, not about making this
information available / mandatory.

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

Re: [webkit-dev] Proposal: Commit messages should start with a one-line summary of the change

[Julien Chaffraix]

>> I don’t think it’s a good idea to add yet another thing to every change log 
>> entry.
>
> I wouldn't consider this something being added. Most ChangeLog entries (the 
> good ones, anyway) already contain a description of the fix in addition to 
> the bug title, URL and reviewer.

While I sympathize with the idea of the one line explanations, I think
this adds unneeded complexity to our workflow and the added value you
mentioned does not seem to overcome it (namely making a couple of
tools work better).

Also you are implicitly constraining people to explain their change
with one-liners which IMHO is not a good constraint. I would rather
see good explanations than explanations that need to match a format.

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

Re: [webkit-dev] CSS optional property names

[Julien Chaffraix]

> It looks like only the .idl files get pre-processed. The .in files have
> comments that start with "#", meaning that they cannot be pre-processed by
> a C++ preprocessor. We need to change the comment styles for .in files to
> "//".

That's partly right. Some .in files are preprocessed (tag and
attribute names (see Sources/WebCore/html/HTMLTagNames.in for
example)) but the CSS ones are not.

If you are up to fixing that, all the .in files should have the same processing.

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

Re: [webkit-dev] Tiger

[Julien Chaffraix]

> I was referring mostly to build-webkit ifs, assuming that the #ifdefs
> in the cpp code were still around as well.  But it's possible those
> already got removed. :)

I think Eric's question is broader than just #ifdefs. Bugzilla has
some Tiger bugs that we should close if we consider Tiger's support to
be dropped.

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

Re: [webkit-dev] Contributors meeting notes

[Julien Chaffraix]

> On Wed, Apr 27, 2011 at 1:12 PM, Eric Seidel  wrote:
>> There are some on the webkit-meeting list.  We need to make a more
>> concerted effort to move them to the wiki and link from the meeting
>> page though.
>>
>> I will make an effort to track down notes from my talk and add them to
>> the wiki this afternoon.

I dumped what I had on unifying the build, multi-threading and WebKit2
(everything is linked from the meeting's page).

Hope it helps,
Julien
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] What is XBL?

[Julien Chaffraix]

> http://en.wikipedia.org/wiki/XBL , I guess?

FYI XBL has been superseded by XBL 2.0 that is not backward compatible
with the first version [1]. Thus our code is just obsolete.

Regards,
Julien

[1] http://www.w3.org/TR/xbl/#relationship
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] help with webkit installation for kde-4.4.2 (amd64 linux)

[Julien Chaffraix]

Hi,

> I am having a go at compiling kde4.4.2.  I am now  trying to build webkit for
> KDE4.4.2 (pure-64bit -non-multilib -amd64 linux  setup).  (it is needed by
> google-gadgets)  I downloaded qtwebkit from
> http://gitorious.org/+qtwebkit-developers/webkit/qtwebkit
>
> and it compiles OK with the following instruction:-
> WebKit/WebKitTools/Scripts/build-webkit --qt   --qmake=$QTDIR/bin/qmake
>
> but I have no idea   from where or how  to do a "make install"  and where   it
> should be installed ($KDEDIR or $QT4DIR)

This is not the appropriate mailing list for such question. This
mailing list is for WebKit development (see
http://webkit.org/contact.html). There is a webkit-qt mailing list
(http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt) where people
should be able to better answer your question. It looks to be more a
qmake question than a WebKit question though.

[snipped]
> ===
>  WebKit is now built (42m:47s).
>  To run QtLauncher with this newly-built code, use the
>  "webkit-qtwebkit/WebKitTools/Scripts/run-launcher" script.
> ===

FYI, this message indicates that your build successfully finished (it
seems you were unsure if everything worked fine).

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

[webkit-dev] [Seeking comments] WebKit site modification

[Julien Chaffraix]

Hi everyone,

Following the huge number of people posting on webkit-dev instead of
more appropriate mailing lists - even though we made the switch
several months ago - or asking incomplete questions, I have undergo a
change to the website to prevent that [1].
Considering that it has scared reviewers for several weeks now, I am
now seeking comments from the broader community as it should reflect
what the WebKit community thinks.

The idea is to rephrase the "Keeping in touch" page [2] to underline
that webkit-help should be the likely choice for a question. It also
adds a page about how to efficiently ask questions which is just
Ariya's mail [3] rephrased to match the wording and style of the
website.

Feel free to suggest improvements or ideas on the bug!

Regards,
Julien

[1] https://bugs.webkit.org/show_bug.cgi?id=35223
[2] http://webkit.org/contact.html
[3] http://bit.ly/webkit-gethelp
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] how to debug webcore, or disable some webcore loader?

[Julien Chaffraix]

Hi,

On Tue, Feb 23, 2010 at 5:26 PM, RyanYee/叶晔  wrote:
> we worked on webcore application base on embbed system(mips),
> used qt-webkit package (qt-embedded-linux-opensource-src-4.5.1).
> sometime our browser will crash when access few website.
>
> 1.is there any tools can analytics(which part of webcore cause crash)?
>
> 2.how can we disable some function by api not configure options ,like
> gif display, flash plugin,or something else?
>
> 3.till now ,we can not use gdb to trace into webcore,even use core
> dump , can not get symbol infomations?

This is not the right place to ask such questions. This mailing is for
the WebKit project development. You should direct such questions to
webkit-help or webkit-qt where they will receive likely better answers
(see them at http://lists.webkit.org/mailman/listinfo/).

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

Re: [webkit-dev] eventlistener

[Julien Chaffraix]

Hi,

> I have implemented my own eventlistener .
> but the event listener is being deleted .
> can anyone help me out pls

This mailing list is used for Webkit development discussions only.
Your question should be addressed to
http://lists.webkit.org/mailman/listinfo/webkit-help.

Also make sure you give us more context. Saying that it is deleted is
really broad: do you have more information on how / when it is (any
triggering event for example would be helpful)? What platform / JS
engine do you use? How have you implemented your binding?
The more you tell us, the more likely you will have a satisfying answer.

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

Re: [webkit-dev] Data transfer from the network backend

[Julien Chaffraix]

Hi,

[resend - forgot to CC the list]

> Where is the data fetched by the network backend being used to first
> instantiate the data structures that are need for rendering?
>
> Can you tell me with respect to Qt or GTK+curl?

There is quite a long way from the network backend to the rendering.

The short version is: when the network backend receives data, it calls
ResourceHandleClient::didReceiveData (you can grep for this method in
the ports to see where data is received), which will call back the
loader. The loader mechanics will call the appropriate class to parse
the data. While parsing, the data go through the attachment process
which will build the render tree using the CSS information (if you are
interested in this phase, have a look at
http://webkit.org/blog/114/webcore-rendering-i-the-basics/ which
details a bit more the attachment and the rendering part).

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

Re: [webkit-dev] how to implement the flash block for webkit on linux?

[Julien Chaffraix]

Hi,

>   At present, we want to implement the flash block for webkit on linux
> like flash block extension for firefox.
>
>   We find the implemention of firefox, it's based on xbl, it's very easy
> to understand.Through checking after sometime we find the branches/xbl2  of
> webkit svn includes the xbl2 implemention, but don't know the degree of xbl
> support and its current status, and the layouttest related to xbl is so
> simple. some people know using xbl in webkit can implement the flash block?

XBL2 lives on a branch as it is not suited for inclusion inside WebKit as-is.
The current XBL2 implementation is very limited, it includes adding /
removing a binding through JavaScript or CSS but does not include the
rendering part (shadow tree generation). It lays out some of the XBL2
internals but it is more a stub than anything.

I think you could filter the flash plugin when it is registered for a
page inside WebKit (the code is inside WebCore/plugins). I cannot help
you more as I have a very limited knowledge of the NPAPI.

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

Re: [webkit-dev] How to handle error response on the browser when the HTTP request fails

[Julien Chaffraix]

Hi,

> Thanks for your suggestion. I added delegate method in
> FrameloaderClient::dispatchDidFailLoading for GTK, however,
> noticed that the control flow never reached there - either in case of
> successful response or for http error like server not found etc.
> Then I added some debug code in FrameloaderClient::dispatchDidFailLoading
> for GTK; and found that the control flow does not reach there.

This is normal. The http connection did not fail : you send your
request and received your response correctly. If you had a DNS error,
some network hazard or anything that made your connection to the
server truly fail then it would be called.

If you want to catch an http error code, you should have a look at
FrameLoaderClient::dispatchDidReceiveResponse. You can then query the
Response about its details (httpStatusCode is likely your friend
here).

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

Re: [webkit-dev] Curl Cookie Handling

[Julien Chaffraix]

Hi Kevin,

> Is this patch still valid, i.e. not made obsolete by another approach?

As far as I know, there is no work towards storing the cookies inside
the database as it is done in Firefox. Furthermore I know no work in
cURL toward exposing the cookies so that we could add / remove /
update them simply in our database.

This patch may be a bit special because it is not really cURL
specific. The only dependency to cURL is a method to parse a date (the
'max-age' field), which I found later is already in JavaScriptCore and
would need to be exported to WebCore and maybe need to be adapted.
Thus it could be a base toward a cross-platform cookie implementation.
I do not know if it would be ok for all ports to replicate their
network library's cookie engine.

> Also,
> was it a complete patch (sans any bugs, of course) for cookie support using
> SQLite? I could only test it using wx right now but I would definitely be
> interested in using the SQLite approach.

It is a complete patch in the sense that it stores and fetch the
cookies from the database. About the bug-free part, we have an answer
in this thread I guess :-)
Basically I could not find a test suite for cookies to validate the
approach when I started so I tested it with real world websites
(mostly google app suite, yahoo, mapquest and a few other sites) but
it did not get the testing it deserves and I will not hide it.
To get it moving, I think a rewrite is necessary because I made tons
of small mistakes (I started as a contributor at that time and did not
know the code and coding conventions as I do now) that could be more
easily tackled by a rewrite. It will also need a test suite to fully
valide the changes.
All in all, it means a lot of work that I am willing to do it *if* I
see enough interest in a cross-platform cookie engine for WebKit.

> I know someone a while back proposed a strategy for dealing with port
> enhancements that end up bit rotting in the review tree, whatever happened
> to that? Sometimes new feature patches cannot be broken down into smaller
> pieces, and I realize large patches tend to be intimidating especially to
> people who can't test them themselves, but there has to be some strategy for
> dealing with that so that important new stuff doesn't just sit in a patch
> tracker for months or years...

I think you refer to the Gtk port here? IIRC the main issue for Gtk
was validating the API which is not relevant here.

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

Re: [webkit-dev] Curl Cookie Handling

[Julien Chaffraix]

Hi,

> I have Integrated the patch given in
> https://bugs.webkit.org/show_bug.cgi?id=14730  on webkit r36766 with
> additions on SQLITE db calls

As you have seen this patch is not integrated and is a year old. As a
result, it may have rotten (the code has changed and some assertions I
made are not true anymore) and it was not tested much outside myself
and a few people like you. So it is likely that there are some bugs
(one was already mentioned on the bugzilla).

> The patch does not work on www.facebook.com and results an inconsistent
> crashes / memory corruptions. Here is the snapshot of what valgrind has:
[removed the backtrace]

After a quick look at the code, it is likely that you are manipulating
a deleted pointer. The cookie is taken directly from a cookieMap,
which means that the cookieMap is not updated at some point when we
release one of its pointer. However without further information, I
cannot say more and you will have to debug yourself. Have you tried a
DEBUG build as there are some assertions that could catch it earlier
and help you tie the crash to one area of code? Also look at the
different LOG information as they can help you.

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

Re: [webkit-dev] write function in FrameLoaderClient.cpp

[Julien Chaffraix]

Hi,

> Can I implement the function:
>
> bool WebFrameLoaderClient::hasWebView() const
> {
>return [m_webFrame.get() webView] != nil;
> }
> written in "WebKit/WebKit/mac/WebCoreSupport/WebFrameLoaderClient.mm"
>
> and write it in
> WebKit / WebCore / loader / FrameLoaderClient.cpp?

This method lies in the WebKit/ directory and is thus platform
dependent: WebView & WebFrame are platform-specific classes that wrap
WebCore's. WebCore holds the cross-platform code of WebKit so it does
not make sense to taint it with platform-specific code.
You should implement this method in your platform FrameLoaderClient
implementation.

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

Re: [webkit-dev] Get all text

[Julien Chaffraix]

Hi,

>   I need a help from u all guys.. I am in need of get all the text which
> is displayed..
> Can anybody pls help me for this.

What you are asking is close to what is done by DumpRenderTree when
you specify the option dumpAsText so it should be a good start: the
idea is to get the innerText of the Document element.

After the method to get it is different for each platform (and you did
not say which platform you are using) so you can either have a look at
your WebKit port documentation or see how dumpRenderTree does this by
looking at the method DumpRenderTree::dumpFramesAsText for your port
implementation (you can find the platform implementations in the
subdirectories of WebKitTools/DumpRenderTree/).

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

Re: [webkit-dev] Handling Malformed URL

[Julien Chaffraix]

Hi,

>> I dont think one needs to authenticate such things. If resource is not
>> found an http code is returned. This is how most of browsers work.

Actually this is not always true: you are supposing that the request
is always send and we always receive the response (a network error can
happen or there can be an error prior to sending the request).
Here I think that we should either fail to send the request because
the URL is malformed or to find the hostname associated with the URL
at the curl level (DNS error).

> Agreed, WebKit uses Curl to return those error codes, Curl is sending 503
> http error code for the said URL but WebKit does not respond with didFail()

As I explained, I do not know how you manage to send a request to the
malformed URL as it should fail for the reasons stated above. Are you
sure you are using the very same URL ? Are you using a proxy ?

Concerning the didFail call, it seems you are getting the response so
the connection did not fail : the server simply returned an HTTP error
code.

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

Re: [webkit-dev] about the "Dashed border"

[Julien Chaffraix]

Hi,

> I open a webpage with webkit  (e.g. www.google.com), and the "text box"
> obtains the focus,
>
> if I press the "Tab" key, and the "button" obtains the focus, and there is a
> "Dashed border"

The "dashed border" is called a "focus ring".

>
> Now I want to have a "Actual wireframe",I want to change the "Dashed border"
> ,
>
> But I don't know how to do it. So I hope you tell me ?

The focus ring drawing is done per platform by the method
GraphicsContext::drawFocusRing() (which can be found in
WebCore/platform/graphics and its subdirectories). As its name
implies, modifying this method will change how the focus ring is
drawn.
Most of the focus ring operations are handled by the GraphicsContext
so you can look around for other focusRing related code that might
help you tune it a bit more.

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

Re: [webkit-dev] FontCache refactoring proposal

[Julien Chaffraix]

Hi Dan,

On Thu, Dec 11, 2008 at 6:40 PM, Dan Bernstein  wrote:
> Hi Julien,
> On Dec 11, 2008, at 2:14 AM, Julien Chaffraix wrote:
>
> Hi everyone,
>
> while working on memory leaks inside WebCore, the Pleyo team has found
> that the FontCache was responsible for a few of them.
>
> It would be good to have a bug filed about each leak.
>

Sure. I was not the one to look for leaks but I will get the
information and file the bugs.

> In order to
> solve those leaks and prevent future ones, we have done a refactoring
> of the FontCache and its internal working (mainly making the
> SimpleFontData Refcounted and change several sites inside WebCore to
> hold RefPtr). The modification are done and they are too big for
> integration right now so we would like to split them and contribute
> them back to WebKit. You will find below the different parts that we
> have worked on (this will follow more or less the order in which they
> will be contributed back):
>
> - initial clean-up
>* share some methods that are the same in all implementations
>* add a 'platform' suffix for those that should be implemented per
> platform
>* avoid using FontPlatformData ouside the few font files inside platform
>* make FontCache a singleton and remove all the current static methods
>
> - Add leaks probe using RefCountedLeakCounter to track our progress as
> well as see where the leaks occurs.
>
> - Make the FontCache mechanism use smart pointers
>* have SimpleFontData derive from RefCounted
>* use internally RefPtr
>* use RefPtr for external reference to SimpleFontData all over WebCore
>
> - FontCache HashMap refactoring: currently some HashMaps return
> FontPlatformData internally and there is a mapping between those and
> SimpleFontData so it should be better to use the SimpleFontData
> instead.
>
> How do you plan to maintain the constructor
> Font::Font(const FontPlatformData& fontData, bool isPrinterFont)
> without a mapping from FontPlatformData to FontData?

I may have not explained well. A mapping between FontPlatformData and
FontData is required (as you were pointing out at least this
constructor requires this). However once you have made most of the
methods in FontCache return FontData, it seems relevant to also switch
to using FontData internally (and wrap the FontPlatformData in a
FontData if necessary). This switch is for FontPlatformDataCache which
currently maps a custom key to a FontPlatformData (but changing it
means to change all the methods that rely on the current mapping).

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

[webkit-dev] FontCache refactoring proposal

[Julien Chaffraix]

Hi everyone,

while working on memory leaks inside WebCore, the Pleyo team has found
that the FontCache was responsible for a few of them. In order to
solve those leaks and prevent future ones, we have done a refactoring
of the FontCache and its internal working (mainly making the
SimpleFontData Refcounted and change several sites inside WebCore to
hold RefPtr). The modification are done and they are too big for
integration right now so we would like to split them and contribute
them back to WebKit. You will find below the different parts that we
have worked on (this will follow more or less the order in which they
will be contributed back):

- initial clean-up
* share some methods that are the same in all implementations
* add a 'platform' suffix for those that should be implemented per platform
* avoid using FontPlatformData ouside the few font files inside platform
* make FontCache a singleton and remove all the current static methods

- Add leaks probe using RefCountedLeakCounter to track our progress as
well as see where the leaks occurs.

- Make the FontCache mechanism use smart pointers
* have SimpleFontData derive from RefCounted
* use internally RefPtr
* use RefPtr for external reference to SimpleFontData all over WebCore

- FontCache HashMap refactoring: currently some HashMaps return
FontPlatformData internally and there is a mapping between those and
SimpleFontData so it should be better to use the SimpleFontData
instead.

Those items are open to discussion and we will try to address the
comments before starting and as the work moves forward.

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

Re: [webkit-dev] Build errors

[Julien Chaffraix]

Hi,

On Fri, Nov 14, 2008 at 6:19 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm trying to successfully build WebKit using Visual Studio 2005 but I keep 
> getting compile errors.
>
> SVGElement.h includes SVGNames.h but I don't see SVGNames.h in any directory.
> No such file for HTMLNames.cpp
>
> My SVN checkout succeeded so I'm not sure why I'm running into this.

Those 2 files are automatically generated by make_names.pl (in
WebCore/dom/) during the build process.

Check whether they are present in your build directory. If not, your
build logs should point out what is failing (you can try posting it
here in case someone knows what the problem is).

Hope it helps,

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

Re: [webkit-dev] Identifying a div element

[Julien Chaffraix]

Hi,

> How can I check if a Node is a HTMLDivElement. I want to traverse from a
> child node upto the parent node, until I reach a div node.

You need first to check that it is an Element with the method
isElement(), then cast it as an Element and check its tag name with
Element::hasTagName() (in your case against HTMLNames::divTag). The
code will look like for your use case:

Node* curNode = ... ;

if (curNode->isElement() &&
static_cast(curNode)->hasTagName(HTMLNames::divTag)) {
// This is an html  element.
}

This method works for pretty much any type of element using the right tag.

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

Re: [webkit-dev] Unable to compile the webkit on the Redhat enterprise linux 9

[Julien Chaffraix]

Hi,

On Tue, Oct 14, 2008 at 8:02 PM, Gustavo Noronha Silva <[EMAIL PROTECTED]> 
wrote:
> Hello,
>
> Disclaimer: I'm more of a GTK+/Debian guy =).
>
> On Tue, 2008-10-14 at 10:31 -0400, Ramesh Satyavaram wrote:
>>  I am new to webkit. Yester day I downloaded the sources on to my Red
>> hat enterprise linux 9. I tried to compile with the following command.
>
> There is no such thing as Red Hat Enterprise 9. Either you are using Red
> Hat 9, or Fedora 9. If you're using the former it is already way old,
> and you probably have a too old version of qmake. Do check if qmake's
> version is current.

Just chiming in. This is line:

***Unknown option –r"

indicates that you are using a too old version of qmake (as Gustavo
pointed out). You need at least qmake 4.3. I would advice you to have
a look at http://trac.webkit.org/wiki/BuildingQtOnLinux and check you
meet all the requirements.

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

Re: [webkit-dev] adjust timeout for non-responsive url's

[Julien Chaffraix]

On Wed, Oct 8, 2008 at 6:23 PM, Pitaga <[EMAIL PROTECTED]> wrote:
> I'd appreciate a pointer to the code that determines the wait time when
> attempting to load a page from a non-responsive server.

The ResourceRequest class
(WebCore/platform/network/ResourceRequestBase.h) has a timeout value
that could be used for that. By default, there no timeout value so the
timeout depends on the network library used. You could try to set a
default timeout in ResourceRequest constructors.
Loading a page involves different loaders that you can find in
WebCore/loader so you may want to see which one is involved and sets
its timeout accordingly. In your case, I would start with the
FrameLoader (maybe try adding a custom timeout in
FrameLoader::addExtraFieldsToRequest).

Hope it helps,
Julien
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] File upload feature

[Julien Chaffraix]

Hi,

On Mon, Oct 6, 2008 at 3:44 PM, Amit Nargund <[EMAIL PROTECTED]> wrote:
> Hi,
> No it does not crash. If I open rapidshare.com, and then select a file and
> click on upload... nothing happens!
> I observed the http traffic through wireshark, and I could not see any POST
> packet in it. That means nothing is POSTED to the server!

The network code for file upload is implemented and should be working
(it is not tested by any regression test so we cannot guarantee it is
actually working). There is a bug about upload not working with curl
that could be related to what you see (have a look at
https://bugs.webkit.org/show_bug.cgi?id=21211). Could you try whether
the attached patch help with your issue? If not could you file a bug
at bugs.webkit.org with the steps to reproduce it?
Thanks,

Julien

>
> On Mon, Oct 6, 2008 at 7:11 PM, Cedric Vivier <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> What do you mean "does not work" ?
>>
>> If it crashes it might be related to the recent regression I filed a
>> bug about yesterday :
>> #21385 ( https://bugs.webkit.org/show_bug.cgi?id=21385 )
>>
>> Regards,
>>
>>
>> On Mon, Oct 6, 2008 at 7:57 PM, Amit Nargund <[EMAIL PROTECTED]>
>> wrote:
>> >
>> > Hi all,
>> >
>> > I am currently working on Gtk platform. I checked the latest code, in
>> > that
>> > code File uploading does not work.
>> > Does anybody knows whether webkit currently supports/implements File
>> > uploading or not? Or is it not working because of the platform on which
>> > I am
>> > working? The network library which I am using is curl.
>> >
>> > Thanks
>> > Regards,
>> > Amit
>> >
>> > ___
>> > 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

Re: [webkit-dev] Proposal and ideas for a new .in format

[Julien Chaffraix]

[Forgot to CC the list]

On Thu, Jun 19, 2008 at 4:30 PM, Julien Chaffraix
<[EMAIL PROTECTED]> wrote:
> On Thu, Jun 19, 2008 at 9:32 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>>
>> On Jun 19, 2008, at 12:56 AM, Eric Seidel wrote:
>>
>>> Not a big fan of using the negative:
>>>
>>> noWrapperFactory=1
>>>
>>> Should be something like:
>>> includeInWrapperFactory=0
>>
>> Why would anything be excluded from the wrapper factory in the first place?
>> Are those just elements where the wrapper is JSHTMLElement and not some more
>> specific class? In which case, I think it is ok to just specify that as the
>> interface name.
>
> Those elements do not have a specific wrapper and returns a new
> JSHTMLElement (the wrapper are just a way of choosing which class to
> use).
> Using the interface name would not work IMHO: take for example the
> animateMotion tag in svgtags.in, it has an entry in
> SVGElementFactory.cpp as it has his own class but uses the default
> JSSVGElement in SVGElementWrapperFactory.
>
> I am not sure what is the rationale behind this difference. A
> work-around would be to have another attribute that we could set to
> HTMLElement and only to use for the JS*ElementWrapperFactory (this is
> what is achieved with the current hasCustomMapping method and the idea
> behind customWrapper and noWrapperFactory).
>
>>
>>>>
>>>>> I'm not sure what the audio hack is.
>>>>
>>>> Audio tags need a special wrapper so the attribute triggers generating
>>>> it. Maybe "isAudioTag" would be more explicit?
>>
>> OK, so the audio special case seems to be if (!MediaPlayer::isAvailable()),
>> make a generic HTMLElement instead. The first thing I wonder is whether this
>> should apply to video as well as audio. If so, maybe the parameter should be
>> something like wrapperOnlyIfMediaIsAvailable=1.
>>
>> Another thought: is there any case where we want the C++ namespace to be
>> anything but WebCore? I think not, in which case we should probably hardcode
>> this in the script instead of making it a parameter.
>
> When dealing with the different files, I have not seen anything but
> WebCore. I will not change that with XBL2 so it could be removed if no
> one has an objection.
>
>>
>>
>>>>
>>>>
>>>>> Instead of "upperCase", might it make sense to call that "interfaceName"
>>>>> for
>>>>> cases where the interface is not the obvious thing derived from the tag
>>>>> name? "Anchor" isn't really an uppercase version of "a", and for h1-h6
>>>>> all
>>>>> of them would have Header in the interface name, but it's not really an
>>>>> uppercase version. Might it make sense to even say
>>>>> interface=HTMLAnchorElement?
>>>>
>>>> upperCase usually really represents the upper case (Camel-case) name
>>>> but there is some exceptions.
>>>> I am fine with "interface" or "interfaceName" but you could not write
>>>> interface=HTMLAnchorElement as the "interface" value has other use
>>>> that just the class name (wrapper function name, QualifiedName, ...).
>>>> Maybe "useCustomInterface" would be an even better name as there is a
>>>> default value?
>>
>> The wrapper function name could use the full interface name IMO, or else the
>> tag name like the defined QName does. The QualifiedName is based on the
>> actual tag name, isn't it?
>
> I checked and you are right.
>
>> It's HTMLNames::aTag, not anchorTag. What else
>> uses the uppercase version of the name?
>
> The #include lines also uses the uppercase version but it would not
> bother to use the full interface name there too.
>
> All in all, I think your suggestion could work (requiring a small
> cleanup of make_names.pl). Remains the JS*ElementWrapperFactory issue
> I raised above.
>
> Regards,
>
> Julien
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposal and ideas for a new .in format

[Julien Chaffraix]

On Wed, Jun 18, 2008 at 11:42 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Jun 18, 2008, at 3:30 PM, Julien Chaffraix wrote:
>
>> Hi all,
>>
>> following several issues raised about the XML format, I have tried a
>> variation of the format Maciej proposed.
>>
>> Here is an exemple:
>>
>> # the first part contains the common parameters (may be empty)
>> namespace=html
>> cppNamespace=WebCore
>> namespaceURI=http://www.w3.org/1999/xhtml
>>
>> # an empty line separate the 2nd part from the tags
>> # the first one is the tag, followed by a comma separated list of
>> attributes / values.
>> a   upperCase=Anchor, noWrapperFactory=1
>> audioapplyAudioHack=1
>
> Could you show a few more examples?

Sure, here is what HTMLTagNames.in would look like (HTMLTagNames.in is
the file that has the most exceptions right now):

namespace=HTML
namespacePrefix=xhtml
cppNamespace=WebCore
namespaceURI=http://www.w3.org/1999/xhtml

a upperCase=Anchor, noWrapperFactory=1
abbr
acronym
address
applet
area
#if ENABLE_VIDEO
audio applyAudioHack=1
#endif
b noWrapperFactory=1
base
basefont upperCase=BaseFont
bdo
big
blockquote
body
br upperCase=BR
button
canvas
caption upperCase=TableCaption
center noWrapperFactory=1
cite noWrapperFactory=1
code noWrapperFactory=1
col upperCase=TableCol
colgroup
dd
del upperCase=Mod
dfn noWrapperFactory=1
dir upperCase=Directory
div
dl upperCase=DList
dt
em noWrapperFactory=1
embed
fieldset upperCase=FieldSet
font
form
frame
frameset upperCase=FrameSet
head
h1 upperCase=Heading
h2 customWrapper=h1
h3 customWrapper=h1
h4 customWrapper=h1
h5 customWrapper=h1
h6 customWrapper=h1
hr upperCase=HR
html
i noWrapperFactory=1
iframe upperCase=IFrame
image customWrapper=img
img upperCase=Image
input
ins customWrapper=del
isindex upperCase=IsIndex
kbd noWrapperFactory=1
keygen customWrapper=select
label
layer
legend
li upperCase=LI
link
listing customWrapper=pre
map
marquee
menu
meta
nobr noWrapperFactory=1
noembed noWrapperFactory=1
noframes noWrapperFactory=1
nolayer noWrapperFactory=1
noscript noWrapperFactory=1
object
ol upperCase=OList
optgroup upperCase=OptGroup
option
p upperCase=Paragraph
param
plaintext noWrapperFactory=1
pre
q upperCase=Quote
s noWrapperFactory=1
samp noWrapperFactory=1
script
select
small noWrapperFactory=1
#if ENABLE_VIDEO
source applyAudioHack=1
#endif
span noWrapperFactory=1
strike noWrapperFactory=1
strong noWrapperFactory=1
style
sub noWrapperFactory=1
sup noWrapperFactory=1
table
tbody upperCase=TableSection
td upperCase=TableCell
textarea upperCase=TextArea
tfoot customWrapper=tbody
th customWrapper=td
thead customWrapper=tbody
title
tr upperCase=TableRow
tt noWrapperFactory=1
u noWrapperFactory=1
ul upperCase=UList
var
#if ENABLE_VIDEO
video applyAudioHack=1
#endif
wbr noWrapperFactory=1
xmp

==

> Also, what would the per-tag attributes
> be and what are the meaning?

It is the parameters whose values vary with the tags. In
make_names.pl, they are used to tweak code generation.

> I'm not sure what the audio hack is.

Audio tags need a special wrapper so the attribute triggers generating
it. Maybe "isAudioTag" would be more explicit?

> Instead of "upperCase", might it make sense to call that "interfaceName" for
> cases where the interface is not the obvious thing derived from the tag
> name? "Anchor" isn't really an uppercase version of "a", and for h1-h6 all
> of them would have Header in the interface name, but it's not really an
> uppercase version. Might it make sense to even say
> interface=HTMLAnchorElement?

upperCase usually really represents the upper case (Camel-case) name
but there is some exceptions.
I am fine with "interface" or "interfaceName" but you could not write
interface=HTMLAnchorElement as the "interface" value has other use
that just the class name (wrapper function name, QualifiedName, ...).
Maybe "useCustomInterface" would be an even better name as there is a
default value?

Regards,

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

[webkit-dev] Proposal and ideas for a new .in format

[Julien Chaffraix]

Hi all,

following several issues raised about the XML format, I have tried a
variation of the format Maciej proposed.

Here is an exemple:

# the first part contains the common parameters (may be empty)
namespace=html
cppNamespace=WebCore
namespaceURI=http://www.w3.org/1999/xhtml

# an empty line separate the 2nd part from the tags
# the first one is the tag, followed by a comma separated list of
attributes / values.
a   upperCase=Anchor, noWrapperFactory=1
audioapplyAudioHack=1

=

The common parameters would hold anything that is not related to
generation so that the script is aware of what it is generating.

These parameters for make_names.pl are (I included where I would put them):

- namespace
- namespacePrefix
- namespaceURI
- cppNamespace
- tagsNullNamespace
- attrsNullNamespace
- noWrapper (holding this change until the format settled)
- customWrapper (holding this change until the format settled)

=> would leave them in the .in files.

- guardFactoryWith

=> not sure if it belongs to the .in files or as a command line parameter.

- generateFactory
- generateWrapperFactory

=> would revert them as a command line parameters.


A last thought, do we want to switch all the .in files to this format
for coherency?

Any comments are welcome.

Regards,

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

Re: [webkit-dev] New XML format for .in files

[Julien Chaffraix]

On Wed, Jun 11, 2008 at 9:54 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Jun 11, 2008, at 1:41 PM, Eric Seidel wrote:
>
>> Julien and I discussed some of these during the patches.  I'm sure
>> he's open to further suggestions.
>>
>> 1.  The idea has been that "long term" xml is easier than a custom
>> parser (He's been slowly moving more of the custom-hacks in the perl
>> script into .in file data).  I agree, the current solution is
>> less-than-ideal to author, and I certainly agree things like
>
> In my experience, that's not really true, if your file format is very imple.

As Eric stated, the format is not fixed. As long as the new format can
hold more that just the names, it is fine.

I am not for a custom format as I do not think we want to write yet
another parser.

I chose xml for 3 reasons:
1) I did not find a good parser in the perl core modules (most our
scripts are in perl so I did not want to switch to another language).
2) we cannot introduce new dependencies so we need a pure perl parser.
3) the choice of pure perl parsers is limited and I found that this
module seemed the best alternative (only one file, quite limited but
we did not need a lot of functionality, fair documentation ...).

I may have missed some opportunities and would happily switch to
something else. The core of the issue is to move some perl hacks that
were in make_names.pl to the files where they should be. The idea was
also to make the automatic generation more extensible (which would be
nice for XBL2 but also for other extension we may have to do).

>> (2.)
>> href are even worse.
>> 3.  Julien and I discussed this as well.  I decided it was less than
>> ideal, but not worth worrying about.  Dealing with maintaining the
>> right command line flags in each of the 8 build systems people use
>> seemed more of a pain than this data/logic violation.
>
> The only place that should need to know about the flags is
> DerivedSources.make.

You have forgotten GNUmakefile.am and WebCore.pro. I guess other
unofficial ports also have their custom files.

> And it has to know what files are getting generated
> anyway, to get the dependencies right. Furthermore, the different build
> systems do have to be changed to add the right files, which is probably
> going to be more confusing if what files are generated is implicit in the
> contents of the .in file.

Yes, all the build systems do use the same generated files and would
need to be modified anyway. Some of what was moved were common to all
the platforms (namespace, ...) and did not state which kind of files
were generated. Such attributes could easily be removed from the
command line. Especially since providing one of these parameters
incorrectly would only break one build and would be difficult to find
out.
We could keep the parameters that state what is generated in the
command line (like --wrapperFactory and --factory).

>> I would encourage you to discuss this at greater length with Julien over
>> IRC.
>
> I sent email on purpose because I'd like us to start discussing more
> technical issues like this on the mailing list. Mailing list discussion
> makes it easier for people who aren't on IRC all the time or not in the
> right time zone to follow the technical discussions of the project. But I am
> happy to discuss on IRC as well.

I am fine with both too.


Best regards,

Julien


> Regards,
> Maciej
>
>>
>>
>> -eric
>>
>> On Wed, Jun 11, 2008 at 12:55 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 
>> wrote:
>>>
>>> Here's what the new format looks like (WebCore/xlinkattrs.in):
>>>
>>> >> namespaceURI="http://www.w3.org/1999/xlink
>>> ">
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>> I must admit I don't really like this. First, if we need to have this
>>> info in the file, I think it would be simpler to use a simple custom
>>> format with a few key-value entries to start and then the attributes:
>>>
>>> namespace=XLink
>>> cppNamespace=WebCore
>>> namespaceURI=http://www.w3.org/1999/xlink
>>> actuate
>>> arcrole
>>> href
>>> role
>>> show
>>> title
>>> type
>>>
>>> This would still be easier to parse than XML and certainly easier to
>>> author.
>>>
>>> Second, I think this is a poor use of XML - having a new XML tag name
>>> in this .in file for every attribute or element in a namespace means
>>> there's no real defined XML language here, the tag names are
>>> completely ad-hoc, which means this is effectively putting content in
>>> markup, which is not good. The more natural XML-style way would be to
>>> say actuate instead of , but of course that
>>> adds more syntactic noise. So again I think the plaintext format is
>>> better.
>>>
>>> And finally, I am not sure I like defining all the parameters to the
>>> generator script inside the file. For example:
>>>
>>> >> namespaceURI="http://www.w3.org/2000/svg
>>> " generateFactory="1" generate
>>> WrapperFactory="1" guardFactoryWith="ENABLE(SVG)" nullNamespace="1">
>>>
>>> This is defining what actual implementation file

Re: [webkit-dev] Qt DOM tree

[Julien Chaffraix]

Hi Habiba,

> I posted in this mailling list because it seemed to me necessary seen that I
> work with WebKit, because the important for me it is to have ideas of the
> others.

Just to clear that a bit as it can be quite confusing. What you are
really using is WebKit embedded in the Qt framework (aka the QtWebKit
module). It means that what you are using is what is explicitly
exported in Qt.
What you manipulate is quite different from what we deal with when
manipulating directly WebKit. Think that Qt objects have methods that
do not exist in WebKit and WebKit has methods that are not exported to
the Qt framework.

My tone was maybe a bit harsh but asking your questions at the right
place is the best way to have them answered (and receive insightful
answers). On webkit-dev, not everyone uses Qt (I would say that they
are even a minority).

If you have questions regarding about WebKit in itself, then this
mailing is the right place.

Regards,

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

Re: [webkit-dev] Qt DOM tree

[Julien Chaffraix]

Hi,

On Sun, Jun 1, 2008 at 4:42 PM, Habiba Boulefat <[EMAIL PROTECTED]> wrote:
> Hello,
> I am developping an application that construct the DOM tree of a web page.
> When the load of the page ends, I construct its DOM tree .
> There is portion of my code:
>


I have already told you that this mailing is for WebKit development
and *not for Qt questions*.

Your application may embed WebKit by using the components exported in
Qt and while we like to hear from people using WebKit, it is not the
place for Qt questions.

So please, *ask your next questions on a Qt mailing list*, most people
here do not use Qt or hack QtWebKit.

Thanks,

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

Re: [webkit-dev] PDF rendering for HTML

[Julien Chaffraix]

Hi,

On Mon, May 19, 2008 at 12:55 PM, Habiba Boulefat <[EMAIL PROTECTED]> wrote:
>
> I am using an application that converts html to pdf.
>
> http://code.google.com/p/wkhtmltopdf/
>
> And now i would like to add some modifications.

This is a question about a Qt application that uses WebKit: on
webkit-dev, we deal with WebKit internal development. You should ask
that type of question on a Qt mailing list
(http://lists.trolltech.com/).

> my goal is:
> if there is a proxy that my application must crosses to acces the web, how
> can i do to specify to my app the name of the proxy and it's port.
> I believed to hear that WebKit use the Linux Environment Variables to read
> and to use a proxy.

After a small research, I think it is not the case (we do not try to
read any of the variables you mentioned). It may be enforced at the Qt
network back-end level (a quick search did not provide any useful
answer however the likely answer is that it does not).
It would make sense for us to support them somehow (Firefox has an
extension to do that). Could you file a bug on WebKit bugzilla
(https://bugs.webkit.org (you will need to register a free account))?

> http://ubuntuforums.org/archive/index.php/t-1586.html
>
> It seems that There is some ones to configure in the Shell:
> ftp_proxy
> http_proxy
> all-proxy
> no_proxy
>
> But I do not know how to configure them and i don't knew If it is these
> variables which WebKit uses to manage the support of the proyx?

Some google searches will tell you how to set them. Your best move is
to check the variables yourself and set the proxy (to get the
variables' values, use getenv(3)).

Regards,

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

Re: [webkit-dev] dom, Qt and Qwebkit

[Julien Chaffraix]

Hi,

> I have developed an application that extract links from a javascript file
> with the manipulation of the dom tree, QDocument and Qwebkit .
> There is a portion of my code where i have the falawing error:
>   QDomNode n = docElem.firstChild();
>
> while(!n.isNull()) {
>   QDomElement e = n.toElement(); // try to convert the
> node to an element.
>   if(!e.isNull()) {
>  cout << e.tagName() << endl; //
> the node really is an element.
>  }
>   n = n.nextSibling();
>  }
> Can any one help me.

This is more a Qt question than a WebKit one. The QtWebkit module is
part of Qt so if your question covers the toolkit (which is the case
here), you should have a look at http://lists.trolltech.com/ for where
to ask it. You will likely have more answers.
FYI, this mailing is for WebKit development (that is the code behind QtWebKit).

Regards,

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

Re: [webkit-dev] help: extraction of links with WebKit

[Julien Chaffraix]

Hi,

> Please can any one tel me how can I do to to skim through the DOM tree and
> extract links from, by using WebKit API.

I have answered a similar question for the Qt port:
http://www.nabble.com/Fwd%3A-help-to16921985.html#a16921985

You need to have access to the WebCore::Document or the equivalent if
it is exported by your port. To do so, you should look at the port's
documentation and/or the code to determine the best way (the code is
in the port's directory in WebKit/). Then you can use one of the
methods I pointed to in the previous answer.

Regards,

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

Re: [webkit-dev] Fwd: help

[Julien Chaffraix]

Hi,

[I have assumed you are using the Qt code as your previous post was about Qt]

>  I want to develop an application  using webkit, my application in the fact
>  consists to extract the links from a html page.

It is not currently possible as WebKit DOM bits are not exported in Qt
but it is planned for Qt 4.5
(http://labs.trolltech.com/forums/topic/31).

If you *really* want to try, you will need to look at the code in
WebKit/qt/Api/*. Your goal is to get access to a WebCore::Document.
After a quick look at the code, I would say that
QWebFramePrivate::core(QWebFrame*) is a good candidate (you get a
Frame that has a pointer to its Document).

Once you get access to the Document, you have several methods:
- traverse the DOM and test if the nodes are links (inefficient at least)
- use Document::getElementByTagName (the simplest way I would say)
- use Node::querySelectorAll (maybe better if you want to query only a
portion of the DOM tree)

>  I am new to WebKit technology.
>  If you have any document for beggening send it for me, please.:,(

The Qt part has a good documentation on the trolltech website (which
is also present in the code). For the rest, the code is your friend
(it is made to be readable / hackable).

Hope it helps,

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

Re: [webkit-dev] Building the Qt version on Linux

[Julien Chaffraix]

[Adding the list again]

On 4/12/08, sea <[EMAIL PROTECTED]> wrote:
> Hi Julien,
>
> Thanks for your reply. I actually ran
> "WebKitTools/Scripts/run-launcher --qt". That was wrong
> copy-paste mistake ./WebKitTools/Scripts/run
> -webkit-tests --qt".

Sorry, I should have understood the copy/paste mistake (I was somehow
mislead by your first description).

> When I ran the launcher, it shows the loading 100% on
> the bottom right and "stop" button is enabled. Whichevert URL, I type, does
> nothing. Right click shows "Inspect" options. Inspecting shows the
> configuration info. So I could not browse with this QT build of WebKit.

I think you are hitting a known limitation in the Qt port: it only
accepts full URL (including the protocol part). For example, if you
want to go to google.com, you will need to enter http://google.com in
the URL bar (or directly on the command line after the run-launcher
options).
FYI, when you enter a URL that is rejected, it falls back to the
previous page so it seems to do nothing.

Julien

> --sea
>
> On Sat, Apr 12, 2008 at 5:13 PM, Julien Chaffraix
> <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >
> > > I got this building error of libQtWebKit shared library.
> > >
> > > tmp/chartables.o:(.rodata+0x0): multiple definition of
> > > `kjs_pcre_default_tables'
> > > tmp/pcre_tables.o:(.rodata+0xa0): first defined here
> > >
> > > The error is obvious because
> > > JavaScriptCore/pcre/pcre_tables.cpp has included the
> > > generated "C" file (#include "chartables.c")
> > >
> > > After commenting out that, build was successful. I just wonder, how that
> > > simple mistake is ignored.
> > >
> >
> > I think I have bumped into this problem a few times. However IIRC
> > removing WebKitBuild (the directory where the build files are) did
> > resolve it.
> > If it keeps happening to you, feel free to file a bug at
> > http://bugs.webkit.org (you will need to register an account).
> >
> >
> > > I tried to run Qt Webkit.
> > >
> > > ./WebKitTools/Scripts/run-webkit-tests --qt
> > >
> > > It opens up the main window but I could not browse or do anything with
> it.
> > > Is this expected?
> >
> > I think you have mistaken the command to run: run-webkit-tests is only
> > used to run tests (as its name states). It is used to validate new
> > patches and automatically detect some regressions.
> >
> > The command to launch the browser is
> './WebKitTools/Scripts/run-launcher --qt'.
> >
> >
> > > I am pretty interested to help developing WebKit using Qt.
> >
> > If you want to start working on WebKit, you should have a look at the
> > wiki (http://trac.webkit.org/projects/webkit/wiki/).
> There is a Qt
> > section which should help you getting started.
> >
> > Hope it helps,
> >
> > Julien
> >
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Building the Qt version on Linux

[Julien Chaffraix]

Hi,

> I got this building error of libQtWebKit shared library.
>
> tmp/chartables.o:(.rodata+0x0): multiple definition of
> `kjs_pcre_default_tables'
> tmp/pcre_tables.o:(.rodata+0xa0): first defined here
>
> The error is obvious because
> JavaScriptCore/pcre/pcre_tables.cpp has included the
> generated "C" file (#include "chartables.c")
>
> After commenting out that, build was successful. I just wonder, how that
> simple mistake is ignored.
>

I think I have bumped into this problem a few times. However IIRC
removing WebKitBuild (the directory where the build files are) did
resolve it.
If it keeps happening to you, feel free to file a bug at
http://bugs.webkit.org (you will need to register an account).

> I tried to run Qt Webkit.
>
> ./WebKitTools/Scripts/run-webkit-tests --qt
>
> It opens up the main window but I could not browse or do anything with it.
> Is this expected?

I think you have mistaken the command to run: run-webkit-tests is only
used to run tests (as its name states). It is used to validate new
patches and automatically detect some regressions.

The command to launch the browser is './WebKitTools/Scripts/run-launcher --qt'.

> I am pretty interested to help developing WebKit using Qt.

If you want to start working on WebKit, you should have a look at the
wiki (http://trac.webkit.org/projects/webkit/wiki/). There is a Qt
section which should help you getting started.

Hope it helps,

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

Re: [webkit-dev] Clarification regarding window.location.replace() in Webcore bindings.

[Julien Chaffraix]

Hi,

On 3/27/08, Maheswari Govindaraju <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  I am currently using the Webkit revision 26699.
>  In this version, the window.location.replace() is implemented in the
>  file Webcore/bindings/js/kjs_window.cpp.
>
>  This function currently doesn't seem to support parameter passing
>  along with the urls, in this revision.
>  (I found this to be supported in Firefox. )
>
>  I wanted to check in the latest revision, but couldn't locate the file.
> Could you please let me know in which file directory the window
>  functionalities are implemented?

The JS bindings are done in WebCore/bindings/js/JSDOMWindow* and the
functionnalities are in WebCore/page/DOMWindow.*.

Hope it helps,

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

Re: [webkit-dev] Mimetype for files loaded from disk?

[Julien Chaffraix]

Hi,

On 3/17/08, Mike Emmel <[EMAIL PROTECTED]> wrote:
>
> In the curl backed some code uses file extensions to set the mime type
> for local files.
> I'm not sure css files are handled.

They are not (see platform/gtk/MIMERegistryGtk.cpp which contains the
association between extension and mime type). I would suggest adding an
entry for css <-> "text/css" after a quick look. Iit seems safe as
MIMERegistry::getMIMETypeForExtension is called only for local file but I
may have missed some issues.
Julien

On Sun, Mar 16, 2008 at 9:22 PM, Kevin Ollivier <[EMAIL PROTECTED]>
> wrote:
> > Hi all,
> >
> >  I've hit an issue with the wx port where HTML files that use @import
> >  url("file.css") will not load when the HTML and CSS file are on disk
> >  rather than loaded via the web. After tracking it down, I found that I
> >  could resolve the issue by having CURL set the file type for
> >  m_response to "application/x-unknown-content-type", which enables the
> >  CachedCSSStyleSheet::canUseSheet test to pass, but I'm not sure this
> >  is the right approach.
> >
> >  Another wrinkle to this issue is that this problem doesn't appear on
> >  the Windows wx port, only Linux/Mac. I'm fairly certain this
> >  discrepancy is not due to wx code, and so I was wondering how other
> >  ports (Apple's and otherwise) handle this issue. Is there some
> >  alternative approach to setting the mimetype explicitly, or is there
> >  some extension <-> mimetype mapping being used in some cases?
> >
> >  Thanks,
> >
> >  Kevin
> >  ___
> >  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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Problem building/running Webkit with QT4 on Ubuntu

[Julien Chaffraix]

Hello,


> i had to change WebCore/dom/XMLTokenizer.cpp as it refer to
> QXmlStreamReader::NotWellFormedError instead of
> QXmlStreamReader::XmlNotWellFormedError, and it call
> QXmlStreamReader.hasError () which doesn't exist in libqt4-dev-kdecopy.


Lars has already answered that part : the changes you had to made come from
the changes between the ubuntu package and the current version of Qt. So the
answer is to download a version from trolltech.com, install it, revert the
changes you have made to the code and compile WebKit with the right library.
I would also advise you to remove all the libqt4 beta 1 packages (if you
can) to be sure you do not bump into the same problem I had (see below).


when i look at the error message:
>
> FIXME: UNIMPLEMENTED: ../../../WebCore/platform/qt/WidgetQt.cpp:120
> (virtual void WebCore::Widget::show())
>
> and at the file WidgetQt.cpp, the code is:
> void Widget::show()
> {
> if (data->m_widget)
>data->m_widget->show() ;
> else
>notImplemented() ;
> }
>
> that's why i think i missing a dynamic library.   what do you think ?


You cannot deduce that you are missing a library from looking at the code.
If you were missing a library you code would just not compile or execute.
The method notImplemented() is just a reminder to user and developer and
does not say that you are missing some library.

I my understanding libqt4-dev-kdecopy, should be for kde.   do you have
> it install on your system ?


I am normally using a version I had downloaded from trolltech.com. As you
were talking about that package, I just gave it a try it to see if it was
compilling on my machine by removing the references I had to my previous
library. I must have missed a reference to the previous library and got it
linked with WebKit as I had been able to run WebKit.
Sorry to have induced you into error,

Julien

Lionel
> Julien Chaffraix wrote:
> > Hi,
> >
> > 1. i fetched webkit from here
> > http://svn.webkit.org/repository/webkit/trunk
> > <
> http://www.qtforum.org/redir.php?url=http%3A%2F%2Fsvn.webkit.org%2Frepository%2Fwebkit%2Ftrunk>
> > 2. i installed libqt4-dev-kdecopy with: apt-get install
> > libqt4-dev-kdecopy, as qt4.3 was needed (libqt4-dev is qt4.2.3)
> > 3. then i build with: QTDIR=/usr/share/qt4/
> > WebKit/WebKitTools/Scripts/build-webkit
> > the build failed 2 or 3 times, like some class api were missing or
> > class reference missing. Anyway it was easy to fix, so i restart
> > the build and it complete successfully.
> >
> >
> > Did the changes you made were in your environment (installed libraries
> > ...) or Webkit source ?
> >
> > The trunk should compile on your platform without modification if you
> > have all the necessary tools and libraries.
> >
> > I am using Ubuntu too so I just tried that package you mentioned and I
> > could compile and run webkit without problem.
> >
> > Could you try to remove all Webkit files (source and builds) and
> > follow the explanation on the webkit page again and report if
> > something went wrong ?
> >
> > 4. then i run the browser with: QTDIR=/usr/share/qt4/
> > WebKit/WebKitTools/Scripts/run-launcher
> > the browser starts, but display the blank window, then whatever
> > address i try to browse the window remain blank, while the console
> > display such message:
> >
> > FIXME: UNIMPLEMENTED: ../../../WebCore/platform/qt/WidgetQt.cpp:120
> (virtual void WebCore::Widget::show())
> > FIXME: UNIMPLEMENTED:
> ../../../WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp:195 (virtual void
> WebCore::FrameLoaderClientQt::forceLayoutForNonHTML())
> >
> >
> >
> >
> > i had a look at WebCore/platform/qt/WidgetQt.cpp, and it seems the
> > data member m_widget is not initialized and so it display the
> > UNIMPLEMENTED error message.
> >
> > I have to say that i'm a newbie at Linux and Webkit, so my
> > questions below might be silly smile
> >
> > 1. i find it strange that i had to fix some compile problem as it
> > seem to me that WebKit was already ported to QT4. Am i using the
> > right svn trunk ?
> >
> >
> > There is only one trunk in svn and the url you gave is the right one.
> >
> > 2. am i missing some library ? i've installed libqt4-dev-kdecopy
> > only, do i need libqt4-core-kdecopy ? is there any other dependency
> ?
> >
> >
> > According to
> > http://packages.ubuntu.com/feisty/libdevel/libqt4-dev-kdecopy
> > <http://packages.ubuntu.com/feisty/

Re: [webkit-dev] Problem building/running Webkit with QT4 on Ubuntu

[Julien Chaffraix]

Hi,

1. i fetched webkit from here
http://svn.webkit.org/repository/webkit/trunk
> 2. i installed libqt4-dev-kdecopy with: apt-get install
> libqt4-dev-kdecopy, as qt4.3 was needed (libqt4-dev is qt4.2.3)
> 3. then i build with: QTDIR=/usr/share/qt4/
> WebKit/WebKitTools/Scripts/build-webkit
> the build failed 2 or 3 times, like some class api were missing or class
> reference missing. Anyway it was easy to fix, so i restart the build and it
> complete successfully.


Did the changes you made were in your environment (installed libraries ...)
or Webkit source ?

The trunk should compile on your platform without modification if you have
all the necessary tools and libraries.

I am using Ubuntu too so I just tried that package you mentioned and I could
compile and run webkit without problem.

Could you try to remove all Webkit files (source and builds) and follow the
explanation on the webkit page again and report if something went wrong ?

4. then i run the browser with: QTDIR=/usr/share/qt4/
> WebKit/WebKitTools/Scripts/run-launcher
> the browser starts, but display the blank window, then whatever address i
> try to browse the window remain blank, while the console display such
> message:
>
> FIXME: UNIMPLEMENTED: ../../../WebCore/platform/qt/WidgetQt.cpp:120 (virtual 
> void WebCore::Widget::show())
> FIXME: UNIMPLEMENTED: 
> ../../../WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp:195 (virtual void 
> WebCore::FrameLoaderClientQt::forceLayoutForNonHTML())
>
>
> i had a look at WebCore/platform/qt/WidgetQt.cpp, and it seems the data
> member m_widget is not initialized and so it display the UNIMPLEMENTED error
> message.
>
> I have to say that i'm a newbie at Linux and Webkit, so my questions below
> might be silly [image: smile]
>
> 1. i find it strange that i had to fix some compile problem as it seem to
> me that WebKit was already ported to QT4. Am i using the right svn trunk ?


There is only one trunk in svn and the url you gave is the right one.

2. am i missing some library ? i've installed libqt4-dev-kdecopy only, do i
> need libqt4-core-kdecopy ? is there any other dependency ?


According to http://packages.ubuntu.com/feisty/libdevel/libqt4-dev-kdecopy ,
liqt4-dev-kdecopy depends on liqt4-core-kdecopy so it is already installed.
Normally if you have managed to compile and run the application, that means
that you have the required libraries.

3. i also find strange that the folder WebKit\WebKitQt\QtLauncher is always
> empty, shouldn't it have some QtLauncher.pro and other files ?
> 4. can somebody also recommend me a good development tools/ide on Linux
> for C++ development.


You have a wide range of development tools under linux. It will widely
depend on what you want as a development environment.
You could use an editor like vim, emacs, gedit or Kate and do the
compilation in a terminal or an IDE like Anjuta (designed for C/C++),
Eclipse (mainly for Java but has a C/C++ extension) or KDevelop. That list
is far from exhaustive.
You should just try some and take the one that suits you most.

Hope it helps,

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

Re: [webkit-dev] Issue with calling javascript function from a external thread

[Julien Chaffraix]

Thanks for your answer but unfortunately the problem is deeper than I
though.

I think that it is related to the way I call back javascript.

You can find the related class attached with this email. Ivy calls back the
OnMessage method that just initialises the arguments to be given to the
javascript method (stored in m_scriptCb) and set the timer to be used by the
main thread as you suggested. The calling is done in the fired() methods.

Now e.g. if I have a page that contains :


When I am calling back and I try to modify it through
document.getElementById("test") I get an exception (msg: null value) but
modifying its properties could yet work.

I have found that defining a global variable in javascript to keep the
result of document.getElementById("test") solve the problem of the exception
but the layout may not be updated (depending on whether the image is in a
div or not ...).

I am really at a loss to find out the common denominator between the
different bugs. I don't think it is a race condition as I have done simple
testing with a unique call from Ivy.

If someone has an idea or a better way to do the calling, I am ready to test
and change the class.

Thanks,

Julien

On 8/11/07, Oliver Hunt < [EMAIL PROTECTED]> wrote:
>
> If you create a WebCore timer with an timeout of 0 that should allow
> you to perform a reasonably low latency action on the main thread.
>
> --Oliver
>
> On 10/08/2007, at 10:41 AM, Geoffrey Garen wrote:
>
> > WebKit is not thread-safe. If you want to perform external
> > processing on a secondary thread, that's OK, but any calls into the
> > DOM will have to happen on the main thread.
> >
> > Geoff
> >
> > On Aug 10, 2007, at 3:00 AM, Julien Chaffraix wrote:
> >
> >> Hi all,
> >>
> >> I am trying to make a wrapper in C++ for the Ivy protocol for OWB
> >> (I think it could work on Webkit even though I have not tested)
> >> that could world entirely in javascript. Ivy is a light-weigh
> >> publish/subscribe protocol. It is based on callback functions that
> >> you call  when a regExp is seen on the bus.
> >>
> >> My main problem is that the thread that calls back functions is
> >> the thread that handles incoming transmissions, that is not one of
> >> Webkit threads.
> >>
> >> As my problem seems close to what is done in XMLHttpRequest, I
> >> have tried mecanisms used by that class and particularly reusing
> >> the code from JSAbstractEventListener::handleEvent to call my
> >> object. The callback seems to work but developing  a javascript
> >> application on top of that lead me to discover that some part of
> >> javascript are not working : for example, accessing some (not all)
> >> element with document.getElementById("...") does return "null" in
> >> the callback (but works in the Webkit threads) even though I could
> >> access it directly in C++ through Document::getElementById.
> >>
> >> I do not know much about what I have done wrong but I am eager to
> >> do the necessary debugging and testing.
> >>
> >> Maybe also my method is not the best so if someone has a better
> >> idea, he is more than welcome.
> >>
> >> Thanks,
> >>
> >> Julien
> >> ___
> >> 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
>
>


IvyWrapMsgCb.cpp
Description: Binary data


IvyWrapMsgCb.h
Description: Binary data
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Issue with calling javascript function from a external thread

[Julien Chaffraix]

Hi all,

I am trying to make a wrapper in C++ for the Ivy protocol for OWB (I think
it could work on Webkit even though I have not tested) that could world
entirely in javascript. Ivy is a light-weigh publish/subscribe protocol. It
is based on callback functions that you call  when a regExp is seen on the
bus.

My main problem is that the thread that calls back functions is the thread
that handles incoming transmissions, that is not one of Webkit threads.

As my problem seems close to what is done in XMLHttpRequest, I have tried
mecanisms used by that class and particularly reusing the code from
JSAbstractEventListener::handleEvent to call my object. The callback seems
to work but developing  a javascript application on top of that lead me to
discover that some part of javascript are not working : for example,
accessing some (not all) element with document.getElementById("...") does
return "null" in the callback (but works in the Webkit threads) even though
I could access it directly in C++ through Document::getElementById.

I do not know much about what I have done wrong but I am eager to do the
necessary debugging and testing.

Maybe also my method is not the best so if someone has a better idea, he is
more than welcome.

Thanks,

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