Re: [webkit-dev] Drop x86 (32bit) JIT backend

2019-09-16 Thread Xan
Hi all,

We at Igalia use the x86 32bit port for testing, prototyping, etc, in our
32bit work. We recently added a JSC EWS x86 instance. That being said only
the LLInt tier is working properly at the moment, and if the maintenance of
the JIT code is a big burden we think it makes sense to remove it.

This already happened during the weekend, so I guess this can count as an
after the fact tacit agreement. In the future we'd appreciate if we could
have at least a full week day (including Europe) to discuss these kinds of
changes though.

Cheers,
Xan (on behalf of Igalia's compilers team)

On Sat, Sep 14, 2019 at 9:32 PM Yusuke Suzuki  wrote:

> Thanks!
>
> I think we are not testing x86 JIT configuration, and nobody is seriously
> using it (Default build option for c86 is no JIT). Removed :D
>
> [1]: https://trac.webkit.org/changeset/249830/webkit
>
> Best regards,
> Yusuke Suzuki
>
> On Sep 13, 2019, at 15:08, Geoffrey Garen  wrote:
>
> No objection.
>
> Geoff
>
> On Sep 13, 2019, at 1:39 PM, Yusuke Suzuki  wrote:
>
>
> Hello all,
>
>
> Now, Xcode no longer has ability to build 32bit binary.
>
> Fedora starts dropping x86 32bit kernel shipping.
>
> Our x86/x86_64 JIT requires SSE2, so such CPUs can use JIT if they want by
> switching x86 to x86_64.
>
> And these CPUs are modern enough to run CLoop at high speed.
>
>
> x86 32bit JIT backend is very complicated and is being a major maintenance
> burden.
>
> This is due to very few # of registers. Which scatters a lot of isX86 /
> CPU(X86) in Baseline, DFG, and Yarr.
>
> I’m now planning to optimize some part of Yarr, but x86 YarrJIT is being a
> major barrier of such cleanups / optimizations.
>
>
> So, I would like to propose dropping X86 32bit JIT support.
>
>
> -Yusuke
>
> ___
>
> webkit-dev mailing list
>
> webkit-dev@lists.webkit.org
>
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [CMake] Bump cmake_minimum_required version to 3.10

2019-06-27 Thread Xan
Hi,

Sorry about that. We'll take care of it ASAP.

Cheers,
Xan

On Thu, Jun 27, 2019, 06:23 Fujii Hironori  wrote:

> jsc-i368 EWS is still failing.
> Who is igalia-jsc-i386-ews bot maintainer?
>
> On Mon, Jun 24, 2019 at 8:21 PM Fujii Hironori 
> wrote:
>
>> Hi,
>>
>> I'm going to bump cmake_minimum_required version to 3.10 for
>> shining new features.
>>
>> Bug 199181 – [CMake] Bump cmake_minimum_required version to 3.10
>> https://bugs.webkit.org/show_bug.cgi?id=199181
>>
>>
>> GTK and WPE's EWS and BuildBot bots maintainers, could you please
>> update your CMake on your bots?
>>
>> If you are using CMake Visual Studio generator, you need CMake
>> 3.12 or newer to avoid an unnecessary recompilation issue.
>>
>> AppleWin port seems still using old Visual Studio 2017. If it
>> will switch to Visual Studio 2019 for better C++17 support,
>> Visual Studio 2019 needs CMake 3.14 or newer.
>> https://cmake.org/cmake/help/v3.14/release/3.14.html#generators
>>
>> Happy WebKit 18th
>> <https://webkit.org/blog/6888/celebrating-15-years-of-webkit/>birthday
>> <https://donmelton.com/2017/06/25/sweet-sixteen-for-safari-and-webkit/>
>>
>> -- Fujii
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Exciting JS features (class fields) in need of review :)

2019-05-07 Thread Xan Lopez
Hi all,
last February we got a thorough review of the class fields patch, and have
been updating it pretty frequently since. We think it's ready to be
reviewed again. Hopefully we'll manage to either land this first stage of
the feature, or receive enough new feedback to keep working on it. The bug
is: https://bugs.webkit.org/show_bug.cgi?id=174212

Cheers,
Xan

On Fri, Feb 15, 2019 at 12:21 PM Mark Lam  wrote:

> Hi Xan,
>
> FYI, if you’re writing JSC stress tests, you can add test specific options
> by putting the following at the top of the test file:
>
> //@ requireOptions(“--myOption=true”, “--myOtherOption=1234”)
>
> For LayoutTests, you can add the following to the top line of the test
> html file:
>
> 
>
> This way, the feature can be disabled by default but still receive testing.
>
> Mark
>
> On Feb 14, 2019, at 9:27 AM, Maciej Stachowiak  wrote:
>
>
>
> On Feb 14, 2019, at 1:37 AM, Xan Lopez  wrote:
>
> Hi Maciej,
>
> the first patches had the flag indeed, so it should be easy to add it back
> to the patch. Not sure what's the usual procedure, but I guess it makes
> sense to enable it by default in the bug so that the bots keep testing the
> code? Then we'll disable it before landing if that's our decision.
>
>
> If it’s a runtime flag then it’s possible to have the tests run without
> having it enabled by default. This is one reason runtime flags are the
> preferred choice, the feature can be running tests all along while still
> getting further polish and refinement.
>
> For a compile-time flag, your approach sounds reasonable to me (patch that
> includes a default-on flag, ideally with a note in the ChangeLog that it
> will be flipped before landing).
>
> We almost never turn on features by default right in the patch where they
> first land, unless it is really small and simple, to reduce risk of anyone
> accidentally shipping it if they happen to cut a release branch soon after
> it lands (and before it has had enough bake time).
>
> BTW I appreciate the contribution of such a substantial feature, I regret
> that you haven’t gotten more active review, and I am glad that Saam is now
> giving you another review pass.
>
> Cheers,
> Maciej
>
>
> Cheers,
> Xan
>
> On Thu, Feb 14, 2019 at 8:47 AM Maciej Stachowiak  wrote:
>
>>
>> I left the boring review feedback that this work should be behind a
>> feature flag. Mentioning it here because this may apply to other feature
>> patches you have in progress. (I am not qualified to review the substance
>> of what the patch is doing.)
>>
>> > On Feb 13, 2019, at 1:51 PM, ca...@igalia.com wrote:
>> >
>> > Hi WebKitters,
>> >
>> > My colleagues at Igalia have been working on a number of JS language
>> features! We want WebKit to have implementations in order to provide
>> feedback for TC39, and to help meet the requirements to have them merged
>> into the specification proper.
>> >
>> > Unfortunately, JSC suggested reviewers have been occupied for the past
>> 6 months, unable to provide feedback and help us upstream the patches. I'm
>> reaching out to see if there are other folks reading webkit-dev who might
>> be able to check on the work, see how it looks, and help us get this stuff
>> upstream. We've been doing internal reviews, but unfortunately don't yet
>> have any JSC reviewers on our team.
>> >
>> > You can find the patch for instance class fields at
>> https://bugs.webkit.org/show_bug.cgi?id=174212. Any kind of constructive
>> feedback (from anyone) would be much appreciated :)
>> >
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Concurrent JS and 32bit platforms

2019-04-11 Thread Xan
Hi all,

as part of our work on improving 32bit support in JSC we at Igalia are
planning to have a look at enabling concurrent js for these platforms.
Before we dive in, though, we thought it would be better to ask some
preliminary questions:

- Was this feature only implemented for 64bit because that was the focus of
the implementors moving forward? Or is there any fundamental difficulty in
the current architecture? In particular we have seen some comments about
atomic updates of JSValues that suggest it could be hard (or impossible) to
get this done on 32bit with the current approach.

- Assuming this is doable right now, we'll get on with it. Assuming it's
not: would you be open to making the necessary changes to JSC to make
concurrent js an option on 32bits?

Thanks,

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


Re: [webkit-dev] RFC: dropping support for x87

2019-03-21 Thread Xan
Since there were no negative comments in the list, just another extra
positive comment in the bug itself, we have landed this:
https://trac.webkit.org/changeset/243293/webkit

Xan

On Mon, Mar 11, 2019 at 7:00 PM Xan  wrote:

> Hi,
> as part of Igalia's work on 32bit support we spent some time trying to
> iron out some bugs in JSC/intel 32bit builds. A bunch of them were related
> to rounding errors (or more precisely, differences) caused by the extended
> precision FP registers used by default in x87; which, in turn, is the
> default in GCC when compiling with -m32.
>
> We discussed a number of solutions, but then we noticed that major
> browsers have in recent times already dropped support for x87:
>
> Firefox:
> https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported
> Chrome: https://support.google.com/chrome/a/answer/7100626?hl=en
>
> This removes a small maintenance burden and prevents future bugs like the
> ones we investigated. Also, in practice, intel hardware older than Pentium
> 4-era machines is very rare. All this considered, we decided it made sense
> to do the same in WebKit.
>
> In short, this email is a RFC to see if anyone in the WebKit community
> objects to this change, or has any comment about it. The bug where we have
> attached the patch for this change is:
> https://bugs.webkit.org/show_bug.cgi?id=194853
>
> Regards,
> Xan
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] -Wpessimizing-move and -Wredundant-move

2019-03-18 Thread Xan
I recently had to test GCC 9 and fixed one of the worst offenders in terms
of number of warnings when compiling JSC. See:
https://bugs.webkit.org/show_bug.cgi?id=195798

On Mon, Mar 18, 2019, 22:36 Michael Catanzaro  wrote:

> Hi,
>
> GCC 9 has new -Wpessimizing-move ("warning: moving a local object in a
> return statement prevents copy elision") and -Wredundant-move
> ("warning: redundant move in return statement") warnings. These are
> enabled by -Wextra (which we use) and will be triggered by code like:
>
> return WTFMove(foo);
>
> when foo is a copyable type. This idiom is only appropriate if foo is a
> noncopyable (move-only) type. We have many, many instances of such
> code. I'm trying to fix them. Please don't add more! (It's easy enough
> to disable the warnings, but they're there for a reason.)
>
> Thanks,
>
> Michael
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] RFC: dropping support for x87

2019-03-11 Thread Xan
Hi,
as part of Igalia's work on 32bit support we spent some time trying to iron
out some bugs in JSC/intel 32bit builds. A bunch of them were related to
rounding errors (or more precisely, differences) caused by the extended
precision FP registers used by default in x87; which, in turn, is the
default in GCC when compiling with -m32.

We discussed a number of solutions, but then we noticed that major browsers
have in recent times already dropped support for x87:

Firefox:
https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported
Chrome: https://support.google.com/chrome/a/answer/7100626?hl=en

This removes a small maintenance burden and prevents future bugs like the
ones we investigated. Also, in practice, intel hardware older than Pentium
4-era machines is very rare. All this considered, we decided it made sense
to do the same in WebKit.

In short, this email is a RFC to see if anyone in the WebKit community
objects to this change, or has any comment about it. The bug where we have
attached the patch for this change is:
https://bugs.webkit.org/show_bug.cgi?id=194853

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


Re: [webkit-dev] Exciting JS features (class fields) in need of review :)

2019-02-14 Thread Xan Lopez
Hi Maciej,

the first patches had the flag indeed, so it should be easy to add it back
to the patch. Not sure what's the usual procedure, but I guess it makes
sense to enable it by default in the bug so that the bots keep testing the
code? Then we'll disable it before landing if that's our decision.

Cheers,
Xan

On Thu, Feb 14, 2019 at 8:47 AM Maciej Stachowiak  wrote:

>
> I left the boring review feedback that this work should be behind a
> feature flag. Mentioning it here because this may apply to other feature
> patches you have in progress. (I am not qualified to review the substance
> of what the patch is doing.)
>
> > On Feb 13, 2019, at 1:51 PM, ca...@igalia.com wrote:
> >
> > Hi WebKitters,
> >
> > My colleagues at Igalia have been working on a number of JS language
> features! We want WebKit to have implementations in order to provide
> feedback for TC39, and to help meet the requirements to have them merged
> into the specification proper.
> >
> > Unfortunately, JSC suggested reviewers have been occupied for the past 6
> months, unable to provide feedback and help us upstream the patches. I'm
> reaching out to see if there are other folks reading webkit-dev who might
> be able to check on the work, see how it looks, and help us get this stuff
> upstream. We've been doing internal reviews, but unfortunately don't yet
> have any JSC reviewers on our team.
> >
> > You can find the patch for instance class fields at
> https://bugs.webkit.org/show_bug.cgi?id=174212. Any kind of constructive
> feedback (from anyone) would be much appreciated :)
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


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

2013-04-30 Thread Xan Lopez
On Tue, Apr 30, 2013 at 9:11 AM, Allan Sandfeld Jensen k...@carewolf.comwrote:

 He probably refers to 1.6.3 of WebKitGTK+, the confusion comes from the
 fact
 that WebKitGTK+ calls themselves and their library 'WebKit' on Linux with
 no
 attempt of disambiguation.


I doubt it. The confusion comes from the fact that most people using WebKit
are not really aware of there being different ports, and most of those
trying to solve some issue will start with Hi I'm using WebKit version...
regardless of what they are actually using.

In any case, we append gtk to all our library names these days, 1.6.3 is
just an old version. I also suggest to at least try again with 2.0.1.

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


Re: [webkit-dev] Status of Windows Port?

2013-04-05 Thread Xan Lopez
Hi,

On Fri, Apr 5, 2013 at 12:19 AM, Benjamin Poulain benja...@webkit.orgwrote:

 I don't know exactly what is the problem with integrating Qt...but I think
 fixing that will be far less work than making a new WebKit2 port from
 scratch.
 WebKitGTK+ also run on Windows. But I don't know if it supports WebKit2.


No, WebKit2GTK+ is not supported on Windows. If someone is willing to do
the work we might consider adding it, but it's not in our plans at the
moment.

Of course as you mention WebKitGTK+ (WebKit1) is supported on Windows.

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


Re: [webkit-dev] WebKit Wishes

2013-01-30 Thread Xan Lopez
Hi Eric,

On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel e...@webkit.org wrote:
 I wish we didn’t have to worry about platforms we couldn’t test.

 It can’t be the job of the core maintainers to care about all the peripheral
 ports which contribute very little core code. Our code needs to be
 structured in such a manner that its easy for the core to march forward,
 while letting the ports catch up as they need to asynchronously.  Platform
 support code shouldn’t even need to be in webkit.org!  Porting webkit.org’s
 platform abstractions should be trivial, but core developers (which probably
 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to
 worry about keeping all ports working.

I agree this is a hard problem. Also a stressful situation to get
oneself into. Coming up with ways to allow port code to survive core
changes would be excellent for everyone, even for the small ports
people who hack on the core and also cannot easily test Mac WK2,
Chromium Linux or any other port.


 I write less out of pain, and more out of hope for the future.  I believe
 all of these are solvable problems, but I believe we need the will to solve
 them.  Apple’s recent announcement of WebKit2 lockdown is clearly one
 attempt at some of these.  But for the other 50% of WebKit developers who
 don’t work on WebKit2, locking down WebCore is not a good solution.

I agree the WebKit2 lockdown is one attempt at solving this, but
hopefully we can agree it's not a particularly innovative one.
Breaking builds and allowing bugs to pile up while they are fixed is a
nasty situation, one that historically we have tried really hard to
avoid for very well known reasons. I understand in the final analysis
allowing the core to move fast could be more important than having an
healthy ecosystem of minor ports without huge teams behind them, but I
really hope that this is only a temporary solution and that in the
future we'll be able to find better solutions like those that you
suggest in your email.

Also, on a personal note, I've been around for enough years to
remember the time when people trying to get ports started were eagerly
welcomed by Apple employees, who would go out of their way to help us
get started, review our patches when we had no reviewers in our team,
patiently explain this or that part of the code, etc. I made sure to
tell everyone I knew that WebKit was one of the most well managed open
source projects in existence, one of those rare combinations of
success and fidelity to some of the best values that open source
supposedly represents. It is with a bit of sadness that years later I
find that the same project (even the same people) now has a very
different attitude, and that long term contributors who I believe have
modestly helped to make this project more robust and popular are
mostly seen as part of a problem instead of as part of its thriving
community. I suppose wild success has some unfortunate costs.

In any case, I don't want to end on a pessimistic note. I'm sure
there's enough brilliance in this community to come up with better
solutions for everyone, including future ports that do not exist yet
but that might be very relevant in this world that moves at breakneck
pace.

Cheers,

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


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

2013-01-21 Thread Xan Lopez
On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada
mario.pr...@samsung.com wrote:
 Hi,


(...)


 If anyone could drop some light on this issue or provide some pointers to
 better understand the motivation of this change, I’d really appreciate that.
 I understand rolling r140285 might be not the best option at this point, yet
 I’d personally rather not keep the WebKit2GTK+ broken for too long.

As has been discussed in the list (see
http://lists.webkit.org/pipermail/webkit-dev/2013-January/023255.html)
the new development model for WebKit2 basically means this can happen
at any time, and the broken pieces are for each port to keep and put
back together. So I doubt reverting the patch is an option (in fact
this is essentially the intended result of the new policy), we just
need to figure out how to deal with this as fast as we can (which I
think will be too long by any reasonably standard, but such is
life).

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


Re: [webkit-dev] Enable the [Supplemental] IDL on all build systems

2011-12-31 Thread Xan Lopez
On Sat, Dec 31, 2011 at 9:21 AM, Kentaro Hara hara...@chromium.org wrote:

  What is the problem? 

 Please note that we need to make a change on _all_ build systems (no
 matter if the build system wishes to support the [Supplemental] IDL),
 because if any of the build systems does not support the
 [Supplemental] IDL, we still need to modify DOMWindow.{h,cpp,idl} for
 that build system. Thus, we need to enable it also on AppleWin,
 GTK/GObject and BlackBerry. Specifically, we need to make changes on
 the following build scripts:

 - WebCore/WebCore.vcproj/MigrateScripts (for AppleWin)
 - WebCore/WebCore.vcproj/WebCore.vcproj (for AppleWin)
 - WebCore/bindings/gobject/GNUmakefile.am (for GTK/GObject)
 - WebCore/PlatformBlackBerry.cmake (for BlackBerry)

 It is, however, difficult for me to change those bulid flows, since it
 appears that neither do they have build bots nor I have the build
 environment locally. Would anyone help this


I suppose that by GTK/GObject you are talking about the GObject DOM
bindings of the GTK port? This is built and tested by all the GTK bots, so
the problem you mention is not exactly accurate, at least in GTK's case.

That being said I can try to help you with this next week.

Xan



 Best Regards


 --
 Kentaro Hara, Tokyo, Japan (http://haraken.info)
 ___
 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] It's time to remove the Haiku port

2011-09-25 Thread Xan Lopez
On Sun, Sep 25, 2011 at 9:34 AM, Adam Barth aba...@webkit.org wrote:
 As part of our effort to reduce complexity in WebKit, I believe it is
 now time to remove the Haiku port.

Perhaps it would make sense to have a small set of simple rules
written down somewhere that would justify the WebKit developers in
removing any given port from upstream. That way it would be a bit more
impersonal and natural (like a tornado destroying your house) and less
likely to be perceived as a personal attack.

A number of months of inactivity sounds like the main thing to
consider here, as you point out, so we could just make it official.

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


Re: [webkit-dev] Git mirror out of sync?

2011-08-24 Thread Xan Lopez
On Tue, Aug 23, 2011 at 7:44 PM, William Siegrist wsiegr...@apple.com wrote:
 We just used git svn reset -r X and git svn fetch where X is the rev 
 before the bad one.

This does not seem to help with my particular problem.

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


Re: [webkit-dev] Git mirror out of sync?

2011-08-23 Thread Xan Lopez
On Thu, Aug 18, 2011 at 6:21 PM, William Siegrist wsiegr...@apple.com wrote:
 Yes, I'm working on it. Git-svn refuses to get past r93167, I've tried a few 
 things, nothing has worked so far. Unfortunately I have no ETA to give you.


Did you ever figure how go to past that in git-svn? Pretty sure I'm
getting the same error as of today:

(...)
W: +empty_dir: 
LayoutTests/platform/chromium-cg-mac/tables/mozilla/collapsing_borders
W: +empty_dir: LayoutTests/platform/chromium-cg-mac/tables/mozilla/dom
W: +empty_dir: 
LayoutTests/platform/chromium-cg-mac/tables/mozilla_expected_failures/collapsing_borders
W: +empty_dir: LayoutTests/platform/chromium-cg-mac/traversal
W: +empty_dir: LayoutTests/platform/chromium-cg-mac/userscripts
W: -empty_dir: LayoutTests/platform/chromium-mac
Byte order is not compatible at ../../lib/Storable.pm (autosplit into
../../lib/auto/Storable/_retrieve.al) line 380, at
/usr/share/perl5/Memoize/Storable.pm line 21

Could not unmemoize function `lookup_svn_merge', because it was not
memoized to begin with at /home/xan/libexec/git-core/git-svn line 3230
END failed--call queue aborted at /home/xan/libexec/git-core/git-svn line 40.
--

A bit of googling suggests it might be a git-svn bug, but it still
happens with git from git master.

Xan

 -Bill



 On Aug 18, 2011, at 9:05 AM, Andras Becsi wrote:

 Hi,

 Seems that the git mirror is still stuck at r93166, that's almost 150 
 revisions now. Does anyone have a clue what happened?

 BR,
 Andras

 On Wed, 17 Aug 2011 23:42:21 +0200, Evan Martin e...@chromium.org wrote:

 (Which is to say I just tried it, and it took under a minute to sync
 past the bad revision.)

 On Wed, Aug 17, 2011 at 2:41 PM, Evan Martin e...@chromium.org wrote:
 I'd try git svn reset r93166 followed by git svn fetch.  You can
 do that from your own git checkout, no need to wait for
 git.webkit.org.  (In theory once git.webkit.org unsticks, it will have
 the same commits anyway so it'll be as if you had pulled it from there
 anyway.)

 On Wed, Aug 17, 2011 at 2:25 PM, Nico Weber tha...@chromium.org wrote:
 The first non-syned revision is http://trac.webkit.org/changeset/93167
 , which is a huge directory move. This might just be slow to handle in
 git?

 On Wed, Aug 17, 2011 at 1:28 PM, David Levin le...@chromium.org wrote:
 From an irc conversation, it sounds like this is being worked on but
 git-svn just hangs, hard to tell why its broken
 dave

 On Wed, Aug 17, 2011 at 7:56 AM, Nico Weber tha...@chromium.org wrote:

 Hi,

 git fetch origin  git log origin/master

 suggests that the git mirror stopped syncing at r93166. Can someone kick
 it?

 Thanks,
 Nico
 ___
 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
 ___
 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] Switching to new-run-webkit-tests

2011-07-06 Thread Xan Lopez
[Sending with the right address...]

On Wed, Jul 6, 2011 at 11:10 AM, Eric Seidel e...@webkit.org wrote:
 Update:

 Leopard Release, Gtk and Qt have been successfully transitioned.

What do we exactly consider successfully transitioned? The GTK+ bots
were still failing, so I reverted to the old script. At the very least
we know that we need to update our Skipped/expected results file when
we switch, because NWRT is more sensitive to slow tests/timeouts and
we need to flag a bunch of tests as such. I didn't know you were
planning to transition already for us, that's why we didn't push those
changes yet. Sorry for the misunderstanding!

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


Re: [webkit-dev] Switching to new-run-webkit-tests

2011-07-06 Thread Xan Lopez
On Wed, Jul 6, 2011 at 5:58 PM, Adam Roben aro...@apple.com wrote:
 On Jul 6, 2011, at 11:53 AM, Adam Roben wrote:

 Now that more and more ports are switching to NRWT, it would be great for 
 someone to explain what the best practices are for dealing with failing and 
 flaky tests.

 Two specific questions I have:

 1) Are the ports that have switched to NRWT no longer using Skipped files?
 2) Are the ports that have switched to NRWT now using test_expectations.txt 
 files?

GTK+ still uses Skipped. NWRT understands both (although you cannot
have both at the same time), but of course test_expectations.txt
allows much more flexibility.


 But I'm interested in a more general overview, too.

Same here. FWIW, the Chrome test_expectations.txt file has a lengthy
introductory comment with some guidelines.

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


Re: [webkit-dev] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)

2011-07-06 Thread Xan Lopez
On Wed, Jul 6, 2011 at 6:29 PM, Eric Seidel e...@webkit.org wrote:
 NRWT uses both!  It will read in all the port's Skipped files, covert
 them to SKIP text_expectations, and add them to your test_expectations
 file.
 http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/webkit.py#L309

 For better or worse, NRWT will error out, if you have duplicates in
 your test_expectations file, including duplicates between your
 test_expectations file and your Skipped lists.

Right, this is what I meant in another email when I said you are not
supposed to use both. Cannot really see a sane use case for this to be
honest. When I transitioned I basically converted Skipped locally to
the new format, got tons of duplicated errors, figured out what was
going on and deleted then deleted Skipped. Maybe this is done so that
you can leave Skipped as it is and start gradually adding stuff to the
new file?

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


[webkit-dev] No getters for iconURL/title/body in Notification.idl

2011-07-01 Thread Xan Lopez
Hi,

we are adding all the Notification related objects to the GTK+ DOM
bindings, and also adding the necessary APIs to WebKitGTK+ to interact
with the UA. One thing we have noticed is that although the
constructors for the Notification objects have the three data
parameters mentioned in the subject, the spec we follow
(http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification,
as I understand it) does not provide attributes for those in the
Notification interface. Since those are needed by the UA to actually
show the notification in a meaningful way, we wonder if that's an
oversight or a design decision. It seems the way Chromium solves this
is by doing a custom class with those getters, but since we already
have pretty complete DOM bindings we'd like our low-level signals and
APIs to use those instead of reimplementing them (or, at best,
subclassing to add the needed functionality).

Any comments?

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


Re: [webkit-dev] No getters for iconURL/title/body in Notification.idl

2011-07-01 Thread Xan Lopez
On Fri, Jul 1, 2011 at 8:17 PM, John Gregg john...@google.com wrote:
 The data parameters are certainly needed by the UA to show the notification,
 but it seems like you're suggesting they need to be exposed as part of the
 Notification API (i.e., to web pages).  I don't see why that would be
 necessary.
 WebCore has a Notification object in C++ which does provide access to the
 fields, and which is passed up through the NotificationPresenter interface
 implemented in the ChromeClient.  That's how Chromium does it -- would it
 not work for GTK?

There's several things there.

- Indeed we'd use this WebCore Notification object, same than
Chromium. The problem is that this object doubles as the
representation of whatever is in the spec we follow (usually the DOM
spec, not in this case but close enough) and it also has extra things
useful for the UA, as we are discussing.

- In the normal case we just let our bindings generate automatically a
GObject wrapper for the core object, but since this is generated from
the IDL it would lack the needed accessors.

- You say that you don't see any need to let binding users access that
information, in that case our version of the DOM object probably
shouldn't allow that either.

- In that case we can either subclass it and add what we need, or just
not use the DOM objects in this case. The problem with the latter is
that we'd need to reimplement portions of the expected DOM interfaces
in the new class we'd do, so it seems a bit pointless to do so, and
that we'd expose two different versions of the object in different
scenarios (for instance, createNotification would create something
different than what you'd receive from the WebKit API in some cases).

In any case, I guess the obvious answer is: why is it not interesting
for the web page to access the parameters passed to the object when
it's constructed? Since it will generally be constructed from within
the page itself (unless I'm totally wrong), it seems reasonable.

Cheers,

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


Re: [webkit-dev] Switching to new-run-webkit-tests

2011-06-27 Thread Xan Lopez
On Tue, Jun 28, 2011 at 1:17 AM, Eric Seidel e...@webkit.org wrote:
 There appear to be 6 remaining blocking issues:
 https://bugs.webkit.org/showdependencytree.cgi?id=34984hide_resolved=1

 We would like to hear from others who have tried new-run-webkit-tests,
 if they have issues which they believe should block migrating to NRWT.
  (If so, please file and block the master bug!)

I can see the GTK+ port thing with Xvfb is there already, so not a lot
to add. NWRT is more sensitive to slow tests than the old
infrastructure, so we had to add a bunch of them to the expectations
file; I don't think this is particularly bad. In any case with the
Xvfb patch and my local expectations file things run beautifully and
way faster than before, so looking great from our side!

Xan


 Thanks.

 -eric
 ___
 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] Cairo Painting Problem?

2011-06-25 Thread Xan Lopez
On Sun, Jun 26, 2011 at 4:43 AM, Brent Fulgham bfulg...@gmail.com wrote:
 Hi Everyone,

 I've recently noticed the following strange drawing behavior under the 
 WinCairo port of WebKit.  I was hoping someone could confirm whether this is 
 also happening under any other Cairo-based WebKit port.

Works fine in GTK+, but it can always be a bug in the cairo version
you are using. I'm using git master.

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


Re: [webkit-dev] Criteria for becoming a core builder

2011-03-02 Thread Xan Lopez
On Wed, Mar 2, 2011 at 7:38 PM, Eric Seidel e...@webkit.org wrote:
 IMO the core list should be *descriptive* rather than *prescriptive*.
 If a bot is regularly green, it should be core. If its not, it should
 be non-core.  We should not remove bots we don't like, or add bots
 we hope to stay green.

While this is pretty reasonably I must note that keeping bots green is
substantially more difficult if they are not core, introducing a
chicken-egg factor in your theory: green bots should (or are) core,
but it's complex to be green most of the time without being core.
That's why I think that adding bots to the core set because you hope
they'll stay green is not as unreasonable as it might sound.

Not that I have any perfect solution for this, but perhaps the only
criteria for being in the list should be whether people are actively
trying to keep a bot green. At least we could accept their intentions
at face value at first, and only remove them from core if they fail to
keep up (which we already do).

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


Re: [webkit-dev] WebKit bindings status

2011-03-01 Thread Xan Lopez
On Tue, Mar 1, 2011 at 5:35 PM, Artem Kozlov akz...@yahoo.com wrote:
 Hello All,

  I've got a question regarding language bindings provided by WebKit. I'm 
 particularly interested in bindings for C++ and GObject: having checked out 
 the latest WebKit trunk, I found that the code generators both for C++ and 
 GObject are present. I wonder if the bindings produced by those generators 
 are operable? What is their current status?

They are operable, used by quite a few applications already, and will
be declared stable for the next WebKitGTK+ release (1.4.0, which will
be released in a month or so). You can see a few examples of their
usage in the tests directory, Source/WebKit/gtk/tests.

Cheers,

Xan


 Thank you in advance.

 Best regards,
 Artem




 ___
 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] WebKitGtk app memory leaks , please help

2010-11-03 Thread Xan Lopez
On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote:

 After calling webkit_web_view_get_dom_document() and similar functions (
 webkit_dom... * ) memory is not freed, what am I doing wrong?

 I wrote simple application which handle events (
 load-started/load-finished/etc ) and make some changes in loaded page DOM
 content, so after loading several pages I have a lot of lost memory, no idea
 how to release it.

 I tried to use g_object_unref, but it destroys something..
 --
 View this message in context: 
 http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html
 Sent from the Webkit mailing list archive at Nabble.com.

The memory management of the GObject DOM bindings is still a work in
progress (unfortunately!). We are trying to figure the best to
automatically collect them, but for now you are correct in saying that
they are essentially leaked until the process is over.

See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion
on the topic. Our plan is to have this issue resolved before the next
stable release in April.

Xan


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

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


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

2010-11-03 Thread Xan Lopez
On Wed, Nov 3, 2010 at 1:20 PM, Fedor Kryukov y...@mail.ru wrote:

 Thanks,

 As I understand this is a WebkitGtk bug only?
 So I can temporarily switch to QT WebKit to avoid leaks?


Possibly, but I don't know, you should ask them.

Also, both bindings are not equally feature-complete (I believe in
general the GTK+ ones have more features), so you'll have to be
careful with that too.

Xan


 Xan Lopez-3 wrote:

 On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov y...@mail.ru wrote:

 After calling webkit_web_view_get_dom_document() and similar functions (
 webkit_dom... * ) memory is not freed, what am I doing wrong?

 I wrote simple application which handle events (
 load-started/load-finished/etc ) and make some changes in loaded page DOM
 content, so after loading several pages I have a lot of lost memory, no
 idea
 how to release it.

 I tried to use g_object_unref, but it destroys something..
 --
 View this message in context:
 http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html
 Sent from the Webkit mailing list archive at Nabble.com.

 The memory management of the GObject DOM bindings is still a work in
 progress (unfortunately!). We are trying to figure the best to
 automatically collect them, but for now you are correct in saying that
 they are essentially leaked until the process is over.

 See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion
 on the topic. Our plan is to have this issue resolved before the next
 stable release in April.

 Xan


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

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



 --
 View this message in context: 
 http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30126515.html
 Sent from the Webkit mailing list archive at Nabble.com.

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

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


Re: [webkit-dev] when is expose_event fired

2010-10-21 Thread Xan Lopez
On Fri, Oct 22, 2010 at 2:10 PM, Aneesh Bhasin contact.ane...@gmail.com wrote:
 However, I wanted to know where and how is the
 webkit_web_view_expose_event function triggered internally - as I
 understand it could either be triggered from the windowing system if
 there is some movement /scrolling dragging of window or internally if
 something has changed and the page needs to be repainted - this second
 invocation path I am unable to find. Could someone point me to the
 right direction here ?

The internal invalidation happens in
WebKit/gtk/WebCoreSupport/ChromeClientGtk.cpp, in the various
'invalidate' methods. Those in turn are called from all over WebCore
in various situations.

Xan


 Thanks for all your help..

 Regards,
 Aneesh
 ___
 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] GTK Skiplist

2010-09-03 Thread Xan Lopez
On Fri, Sep 3, 2010 at 9:50 PM, Jeremy Orlow jor...@chromium.org wrote:
 Recently in a code review for IndexedDB, I was told that I should be adding
 every test individually to GTK's skip list.  The reason cited was this
 comment at the top # Also, no grouping should occur. Every test for
 itself.  For features like IndexedDB which are not turned on by a port, is
 it still expected that I should be adding each and every test to the GTK
 skip list?  If so, why?  /storage/indexeddb has been in the skip list for
 some time and seems to work fine, at least from a technical standpoint.

I didn't write that, but IMHO it's perfectly OK to skip whole
directories when the reason for skipping all the tests inside is the
same or essentially the same. We already do this for storage/, for
instance.

Xan

 Thanks,
 Jeremy
 ___
 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] On IDL files, events and writing DOM bindings

2010-08-11 Thread Xan Lopez
On Wed, Aug 11, 2010 at 7:51 AM, Darin Adler da...@apple.com wrote:
 The bindings do not expose events directly, thus the IDL files don’t show the 
 events. The IDL files only show functions and attributes on the various 
 objects. Events are neither functions nor attributes. For the bindings I am 
 familiar with, there is no list of events and so nothing to be generated from 
 the IDL. The event names, as with tag names, are string constants.

Interesting. For the GObject bindings I'm actually exposing the events
directly. Eg, you are able to do:

g_signal_connect(image, click-event, callback, NULL);

and callback will be called when the image is clicked, with an Event
object as a parameter. The wrapping for the Events comes from the IDL
file that exists for each type of event (Event.idl and its
subclasses).


 You mentioned the ended attribute in HTMLMediaElement. This is a boolean 
 attribute, and not an event. It happens to have the same name as an event, 
 but there is no direct connection between the event and the attribute.

Right, I was aware of the distinction. Maybe I failed to express
myself properly here, my only doubt was really why there was no
reference to the event in any IDL file, which has already been
answered.


 You asked:

 is it possible to know which Events are defined for each class just from the 
 IDL files

 Events are not defined for classes. The engine can send events to any 
 EventTarget, and the IDL files and the bindings have nothing to say about 
 which events the engine will send to which objects.

Right.

I think the only solution that makes sense for the bindings (at least
the GObject ones, where you *do* have to tell a class which kind of
events/signals it can receive or emit), is to define every possible
type of event in the most basic class that is an EventTarget (say,
Node). In this way you'll be able to connect to the event delivery
signals or manually dispatch and event to any node or any of its
subclasses, both perfectly valid things to do.

Cheers,

Xan


    -- Darin


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


Re: [webkit-dev] On IDL files, events and writing DOM bindings

2010-08-11 Thread Xan Lopez
On Wed, Aug 11, 2010 at 5:56 PM, Darin Adler da...@apple.com wrote:
 On Aug 10, 2010, at 11:39 PM, Xan Lopez wrote:

 For the GObject bindings I'm actually exposing the events directly.

 This is a new feature, no other binding has this, and you will have to build 
 everything yourself. There’s nothing in IDL files, or in fact anywhere in the 
 project, that lists all the events that might be sent to each class.

As both you and Adam have commented in the thread I don't think this
information is actually needed to build the bindings. Since any event
can be delivered to any EventTarget you have to be quite generic in
how to setup things, at least for GObject. Part of my willingness to
infer that data from the IDL files was to try to avoid being so
generic in the implementation (since it has some drawbacks), but I
think that just ends in an incorrect implementation so I have no
choice but give it up.

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


Re: [webkit-dev] On IDL files, events and writing DOM bindings

2010-08-11 Thread Xan Lopez
On Wed, Aug 11, 2010 at 8:39 AM, Xan Lopez x...@gnome.org wrote:
 On Wed, Aug 11, 2010 at 7:51 AM, Darin Adler da...@apple.com wrote:
 The bindings do not expose events directly, thus the IDL files don’t show 
 the events. The IDL files only show functions and attributes on the various 
 objects. Events are neither functions nor attributes. For the bindings I am 
 familiar with, there is no list of events and so nothing to be generated 
 from the IDL. The event names, as with tag names, are string constants.

 Interesting. For the GObject bindings I'm actually exposing the events
 directly. Eg, you are able to do:

 g_signal_connect(image, click-event, callback, NULL);

 and callback will be called when the image is clicked, with an Event
 object as a parameter. The wrapping for the Events comes from the IDL
 file that exists for each type of event (Event.idl and its
 subclasses).

FWIW: after this I wanted to check how can the objc bindings do events
without actually exposing any event object/structure directly, since
it seemed at best tricky to achieve this (eg, you really need access
to some data members of say MouseEvents to make sense of what
happened; if it's not exposed as a class in the API it must be exposed
in some other way).

So checking the code I see some headers in the objc bindings dir where
there are references to headers referring to particular event types:

WebCore/bindings/objc/DOMEvents.h:

(...)
#import WebCore/DOMEvent.h
#import WebCore/DOMEventException.h
#import WebCore/DOMEventListener.h
#import WebCore/DOMEventTarget.h
#import WebCore/DOMKeyboardEvent.h
#import WebCore/DOMMouseEvent.h
#import WebCore/DOMMutationEvent.h
#import WebCore/DOMOverflowEvent.h
#import WebCore/DOMUIEvent.h
#import WebCore/DOMWheelEvent.h
(...)

and googling a bit with those names you can see the usual definitions
for things like DOMMouseEvent:
http://google.com/codesearch/p?hl=en#mc67TWYcYcg/WebKit/DOMMouseEvent.hq=DOMUIEvent.hd=1

So if all this stuff is exposed in the API I think what I have done in
the GObject bindings is essentially the same, and I'm not really
exploring any new ground. I guess at some point we started talking
about different things, and you meant something else in your answer?

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


[webkit-dev] On IDL files, events and writing DOM bindings

2010-08-10 Thread Xan Lopez
Hi,

as we all know, when writing DOM bindings on top of WebKit we are
supposed to use the IDL files it ships as the source of the structure
and behavior of the DOM. At first I had assumed that to figure out
which events apply to each type/class it was OK to see which
EventListeners were defined, and go on from there (ie, if there's a
onabort defined in Element.idl, Element has an 'abort' Event defined).
This, though, seems to be not completely accurate in many cases, and
in others it's downright absent:

Media elements are defined to have, for example, an 'ended' event,
emitted when the playback has finished. The matching attribute is
defined in HTMLMediaElement.idl, but the event listener for it is in
DOMWindow.idl. This was done here
https://bugs.webkit.org/show_bug.cgi?id=26100 completely on purpose,
so I assume this is how it's meant to work.

So the question is: is it possible to know which Events are defined
for each class just from the IDL files, or are we expected to inject
part of this knowledge ourselves when writing the bindings?

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


Re: [webkit-dev] On IDL files, events and writing DOM bindings

2010-08-10 Thread Xan Lopez
On Tue, Aug 10, 2010 at 8:32 PM, Adam Barth aba...@webkit.org wrote:
 I'm not sure I understand your question.  Every event can happen on
 every EventTarget.

I mean that an HTMLMediaElement will naturally emit an 'ended' Event
in some situations, but an HTMLImageElement won't. I see no obvious
way of knowing that (or other similar facts) from the IDL files.

Xan


 Adam

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


Re: [webkit-dev] On IDL files, events and writing DOM bindings

2010-08-10 Thread Xan Lopez
On Tue, Aug 10, 2010 at 8:59 PM, Xan Lopez x...@gnome.org wrote:
 On Tue, Aug 10, 2010 at 8:32 PM, Adam Barth aba...@webkit.org wrote:
 I'm not sure I understand your question.  Every event can happen on
 every EventTarget.

 I mean that an HTMLMediaElement will naturally emit an 'ended' Event
 in some situations, but an HTMLImageElement won't. I see no obvious
 way of knowing that (or other similar facts) from the IDL files.

Answering myself after the trip home, I take it that the answer is
basically that the information I want is not useful when writing the
bindings (since as you say any event can in theory happen in any
target, be it naturally or synthetically), and that I should simply
collect all event classes defined and add them as this class might
possible receive this event where appropriate in the class hierarchy?
Another question would be whether we maintain the canonical list
somewhere (perhaps in DOMWindow.idl ) or if we are supposed to
construct it ourselves manually.


 Xan


 Adam


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


Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Xan Lopez
On Thu, Jul 8, 2010 at 7:54 PM, Adam Barth aba...@webkit.org wrote:

 2) Currently the commit-queue only lands if it gets a 100% passing run
 of all the tests.  We could instead change it to land if there are no
 new test failures as a result of applying the patch.  This check is to
 avoid introducing new failures that are masked by existing failures.

commit-queue has been pushing stuff all day and many core bots have
been red since yesterday. How is this possible? Oh, and might this
serve as a ping for whoever set the trees on fire... at least some of
it seems related to the refPtr work that's been going on (see
https://bugs.webkit.org/show_bug.cgi?id=41823)


 3) Currently the commit-queue lands each patch individually.  We could
 instead stack up a bunch of commits in a git branch and build/test
 them all at once.  (Potentially this could be a massive increase in
 throughput.)  We do this to space out the commits so that they
 generally get separate buildbot runs, which makes failures easier to
 localize.

 Adam
 ___
 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] Frustrated at inconsiderate behavior

2010-07-08 Thread Xan Lopez
On Thu, Jul 8, 2010 at 8:09 PM, Adam Barth aba...@webkit.org wrote:
 Originally, we had the commit-queue to land only if all the core
 builders were green.  One recent change we made to make the
 commit-queue more agressive is to land when the commit-queue itself
 sees 100% passing tests on itself.  When we were waiting for all the
 core builders to be green, the commit-queue usually had to wait for me
 or Eric or another contributor to clean up the entire tree and ping
 the folks who maintain bots that had gotten sick.

 My view is, generally, that the commit-queue should act like a
 contentious committer, which means it should act the way most
 committers act.  Given that folks generally don't wait for all the
 bots to be green before committing, I felt this change was worth
 experimenting with.  (Note that sheriff-bot still monitors all the
 core builders and alerts folks of bustage.)

I see, I interpreted you meant it saw 100% passing tests in the core
bots (as it used to be). The new behavior seems to make it easier to
go back to how things were before, when as soon as one port (say GTK+)
breaks, people will keep piling things on top and if nobody is around
at that moment then it's much harder to figure out what happened, who
was responsible, etc, because you only get clear data of the first
breakage.

So, not a fan.

Of course I see the point that you make about most people committing
manually doing the same thing, but maybe we should create a rule of
not committing code touching all ports if any of the trees is red.
That would improve things, I feel this switch won't do that.

Xan


 Adam

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


Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Xan Lopez
On Thu, Jul 8, 2010 at 11:38 PM, Jeremy Orlow jor...@chromium.org wrote:
 I think the point that's been made in this thread is that whatever policy
 the commit queue uses should be in line with whatever policies all
 committers should be using.  Otherwise you run into the problems Maciej
 noted.

I don't see this particular point being made by anyone in the thread.
Who are you referring to? In any case I'm not quite sure I follow the
logic of downgrading machines to a lesser standard of quality just
because this is what humans tend to do.

 If you think we should all follow such a policy, well that's an entirely
 different topic.  And one that seems to keep coming up.  If you want to
 raise it again, you should probably start by looking at the archives.

Fair enough. My point was mostly about undoing the change to cq, not
creating new rules for committers in general.

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


Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Xan Lopez
On Fri, Jul 9, 2010 at 12:30 AM, Daniel Cheng dch...@chromium.org wrote:
 As someone who doesn't have committer access, I like the change to the CQ.
 Before, I might have to wait 3 days for a patch to land since the CQ would
 wait for all the core builders to be green. Meanwhile, committers see that
 the CQ is behind and commit directly instead, so the tree stays on fire and
 the CQ gets even further behind. I don't care if the commit queue behavior
 is reverted, but if it is, it'd be really nice if committers tried to follow
 the same commit policy as the bot.

Aren't you essentially saying that you like the change because it
allows you to join the fun of adding code to already broken trees?
Again, I don't see how this helps us to move towards
as-greener-as-possible trees.

If core-builders are repeatedly red for days on end this is something
we should address instead of adding workarounds so that people can
keep working without paying attention to it. It has been noted that
this is an often visited topic and off-topic to the thread, though.

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


Re: [webkit-dev] GTK bots are now core builders

2010-04-19 Thread Xan Lopez
On Sun, Apr 18, 2010 at 9:17 PM, Eric Seidel e...@webkit.org wrote:
 http://trac.webkit.org/changeset/57795

 Sheriff Bot will nag you when you break GTK.
 Commit Queue will block while any GTK builder is broken.
 build.webkit.org will show GTK in the core set. [1]

 The GKT bots have been green every time I've looked the last 5 days.
 It would appear the WebKit community is keeping the GTK bots green, so
 I've updated the core builder list [2] to reflect reality.

 Thanks!  If you've got questions, let me know.


Thank you! We'll do our best to keep them green.

Xan

 -eric

 1. Thanks to _wms for this feature!  Requires a buildbot server
 restart, should appear soon.
 2. 
 http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L310

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


Re: [webkit-dev] Announcing WebKit2

2010-04-09 Thread Xan Lopez
On Fri, Apr 9, 2010 at 2:47 AM, Xan Lopez x...@gnome.org wrote:
 I suppose I could wait until you land the patches and see by myself, but:

 - In the wiki you mention that one goal of the new framework is to
 provide a stable C-based API. Is this meant as a public API for
 WebKit, the same in all platforms (like JSC), or a stable internal API
 for embedders to use in order to implement their native APIs on top?
 From some lines in the wiki (like WKView wrapping native objects) it
 seems like you want to do the former, but that seems like quite a
 massive effort and the loss of an important selling port of the
 various WebKit ports.

 - Does your new framework require any significant changes in WebCore?
 Could you briefly summarize them?

 - Do you see valid usecases in the long term for the traditional
 ports or are your plans to quickly transition all code to the new
 system as soon as it's ready?


Another issue seems to be that parts of the public C API expose
CoreFoundation, which definitely would be an issue for the other
ports. I'm told on the side that this was just done as a quick
solution to have something running and that if there's interest by
other ports in using this we'd solve it with the good-old let's add
another abstraction layer method, right?

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


Re: [webkit-dev] Announcing WebKit2

2010-04-08 Thread Xan Lopez
On Fri, Apr 9, 2010 at 1:01 AM, Anders Carlsson ander...@apple.com wrote:
 Hello everyone,

 This is a heads-up that we will shortly start landing patches for a new
 WebKit framework that we at Apple have been working on for a while. We
 currently call this new framework WebKit2.

 WebKit2 is designed from the ground up to support a split process model,
 where the web content (JavaScript, HTML, layout, etc) lives in a separate
 process. This model is similar to what Google Chrome offers, with the major
 difference being that we have built the process split model directly into
 the framework, allowing other clients to use it.

 Some high-level documentation is available
 at http://trac.webkit.org/wiki/WebKit2

 Currently WebKit2 is available for Mac and Windows, and we would gladly
 accept patches to add more ports.

 We're more than happy to answer any questions you might have, and we hope
 that this will be a topic of discussion at the WebKit Contributors Meeting.

I suppose I could wait until you land the patches and see by myself, but:

- In the wiki you mention that one goal of the new framework is to
provide a stable C-based API. Is this meant as a public API for
WebKit, the same in all platforms (like JSC), or a stable internal API
for embedders to use in order to implement their native APIs on top?
From some lines in the wiki (like WKView wrapping native objects) it
seems like you want to do the former, but that seems like quite a
massive effort and the loss of an important selling port of the
various WebKit ports.

- Does your new framework require any significant changes in WebCore?
Could you briefly summarize them?

- Do you see valid usecases in the long term for the traditional
ports or are your plans to quickly transition all code to the new
system as soon as it's ready?

Cheers,

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


Re: [webkit-dev] Announcing WebKit2

2010-04-08 Thread Xan Lopez
On Fri, Apr 9, 2010 at 2:52 AM, Darin Adler da...@apple.com wrote:
 As I understand it, the goal is to have a C API that is suitable and works 
 well cross platform for all the many platform independent operations; it is 
 indeed analogous the one for JavaScriptCore in that respect.

 When you refer to a “selling point” of WebKit ports, I assume you are 
 referring to how those ports integrate with the surrounding OS and 
 frameworks. For example, the Mac OS X port provides an Objective-C API that 
 fits in well with the rest of Cocoa. The goal would be that such API can be 
 cleanly built on top of the C-based API and should offer a simple way to 
 “drop down” to the platform independent C one and vice versa.

I see, so the answer is both, kinda. Interesting. Having a stable
API for embedders to use to build their native APIs on top would
certainly ease the lives of port maintainers, and using those stable
APIs in the situations where it makes sense to use them can certainly
be a good idea. Interesting choices for all of us ahead :)

Xan


    -- Darin


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


Re: [webkit-dev] Gtk and Qt bots need love

2010-03-19 Thread Xan Lopez
On Fri, Mar 19, 2010 at 9:59 PM, Eric Seidel e...@webkit.org wrote:
 Gtk and Qt bots need love.

 Looks like Gtk needs 5 new results, and Qt needs 42.

 Various other tests are failing there too.

 Do any Qt/Gtk folks have a minute to try and green up the bots so we
 can start tracking regressions on those platforms again?

Looking at the GTK bots.

Xan


 -eric
 ___
 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] Yet another email about a broken tree

2010-03-17 Thread Xan Lopez
On Wed, Mar 17, 2010 at 9:02 AM, Adam Barth aba...@webkit.org wrote:
 Manual investigation confirms http://trac.webkit.org/changeset/56079
 broke GTK Linux 32-bit Release, GTK Linux 64-bit Release, and Qt Linux
 Release.  Is there some reason we didn't roll out the offending patch?

FWIW this patch seems to only add code in the Mac port and a new test
(which fails in GTK+ and Qt), so rather than rolling out the right
thing to do here would have been to add it to the Skipped list of
those ports I'd say.

Xan


 Adam
 ___
 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] The tree is on fire: a tragedy of the commons

2010-02-26 Thread Xan Lopez
On Fri, Feb 26, 2010 at 11:36 AM, Adam Barth aba...@webkit.org wrote:
 Not to point fingers, but we've been having trouble keeping
 build.webkit.org green these past few weeks.  As I write this message,
 every platform is broken, again.  As the project scales, polluting the
 build with brokenness impacts more developers and drains more
 productivity.

 Here are some approaches we could use to turn this tragedy of the
 commons around:

 1) Adopt a rollout first, ask questions later ethic.  The vast
 majority of changes are not important enough to break the build for
 everyone else.  If we adopt a rollout first, ask questions later
 ethic, committers would feel free to rollout brokenness to unbreak the
 build and contributors shouldn't be offended if their patch is rolled
 out without their knowledge.  We can always re-land the broken patch
 later once it actually works.

In my experience this is more or less the current policy, especially
for build breakage (as opposed to test breakage). Maybe a bit less
hardliner in that we usually try contact the culprit and give some
time to fix issues, but I think there's no remorse in rolling out
patches if there's brokenness and nobody working on fixing it.


 2) Require pre-commit vetting of patches.  We have the resources to
 build and test every patch on at least one platform before landing the
 patch in the main tree.  Vetting patches before landing will help us
 avoid breaking every platform at once.  Once the patch has been
 vetted, it can either be landed mechanically (i.e., by commit-queue)
 or manually.

 Here's how I would design the life and times of a patch:

 1) Contributor uploads patch and nominates it for review.
 2) Patch vetted by the EWS on numerous platforms.
 3) If the EWS finds a problem, return to step 1.
 4) Reviewer marks patch review+.
 5) Committer decides the patch is ready to land.
 6) Patch built and tested against top-of-tree on at least one platform.
 7) If the patch fail to build or pass tests, return to step 1.
 8) Patch landed.
 9) If the patch turns any of the core builders red, patch is rolled
 out, return to step 1.

EWS has been a huge boon in productivity at least for us GTK+ folks,
so I fully support any step to increase its awesomeness! Of course
what we need to do is to work on increasing the number of core
builders, but that's an orthogonal issue and our own responsibility.

Cheers,

Xan


 I suspect most of our brokenness coming from committers skipping steps 6 and 
 7.

 Adam
 ___
 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] webkit gtk stable library dependency versions?

2010-01-29 Thread Xan Lopez
On Fri, Jan 29, 2010 at 7:53 PM, Joseph Zuromski jos...@zuromski.com wrote:
 for the webkit gtk port on linux,  is there a site that lists the newest
 stable version #'s of the dependencies of webkit... specifically:
 gtk+, cairo, pango, icu, soup, gcrypt, gnutls, xslt, glib, atk

 or is it a matter of going to each individual site to monitor their release
 schedules?

Yes, you'll need to do that, we don't track or list the stable
versions of our dependencies. The only thing we do is say which is the
oldest version we support, as usual.



 Thanks.

 Joseph
 ___
 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] +R mode on #webkit IRC channel

2010-01-19 Thread Xan Lopez
Hi,

I woke up this morning to find #webkit set up with mode +R
(http://docs.dal.net/docs/modes.html#2.17), so basically you can't
speak unless you have your nick registered on freenode. Is this a new
policy or just some error or temporary measure that someone forgot to
disable? If it's the latter it would be good to go back to normality.

Cheers,

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


Re: [webkit-dev] Patch to use V8 engine with Gtk port

2009-12-12 Thread Xan Lopez
On Sun, Dec 13, 2009 at 4:19 AM, Holger Freyther ze...@selfish.org wrote:
 On Saturday 12 December 2009 22:42:34 Maciej Stachowiak wrote:
 I think questioning someone's priorities in an open source project is
 generally not polite, unless there is some direct relationship between
 different tasks. For example, if someone introduce a new feature
 (let's say support for parts of the FooML language) and it had lots of
 bugs, it might be reasonable to ask them to fix some of the bugs
 before implementing more FooML features. But that doesn't seem to be
 the case here.

 Ultimately, I think it's up to the Gtk port maintainers and the folks
 maintaining v8 bindings to decide whether they want to support and
 maintain this functionality, and to review the patch as they see fit.

 Hello Mike, All,

 I'm not questioning your priorities. I'm solely looking at this from a
 maintaining WebKit/GTK+ point of view. The problem with WebKit (or any big
 software project) is that we are not done when landing a fundamental new
 feature/configure option but it is really only the beginning.

 The questions are around, who is running a buildbot with this configuration
 option, who will look at this buildbot, who will keep it building. In general
 it is better to have less options (as these could be actually checked prior to
 a release). So it is really not about me telling Mike what to do, but thinking
 about what is maintainable for WebKit/GTK+.

Hi all,

as one of the WebKitGTK+ maintainers I mostly agree with Holger here.
As long as you are willing to provide support for this feature of the
port, some sort of on-going testing, the patch itself is not overly
intrusive (in the bug you hint that there might be no other way to do
this than some big refactoring) and we manage to get it done without
pushing the build system beyond unmaintainability I have nothing in
principle with having this optional feature in.

I'll CC to the bug and follow its progress.

Xan


 E.g. we have an experimental GLib Unicode implementation, and saving the
 storage size for ICU (12 mb when not statically linked) is a pretty good
 reason for some.

 At the end of the day I feel responsible for the Gtk+ port and I would just
 like to know why it makes sense for us to maintain it.

 regards
        holger.
 ___
 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] On the greeness of the GTK+ bot

2009-11-16 Thread Xan Lopez
On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva g...@gnome.org wrote:
 On Mon, 2009-11-16 at 05:24 -0800, Adam Barth wrote:
 Eric and I are working on a bot that might help this situation.
 Essentially, the bot will try out patches on Qt and GTK and add a
 comment to the bug if the patch regresses the build.  Our plan is to
 start with compiling, but we'd eventually like to run the tests as
 well.

 That sounds like an awesome idea. Thanks for working on it. Build
 breakages themselves have become less of an issue for us in recent times
 - people are definitely more aware of our bots, and are acting on fixing
 them when they break.

 I think such an automated approach to running the build, and tests for
 upcoming patches will surely help with giving this a second step
 forward.

This is nice to see, but as Gustavo says build breakage is not too
much an issue at the moment for us: the build does not break very
often, and when it does people usually take the time to figure out
what happened and either do fix it themselves or poke us about it.
That being said, this could be improved in any number of ways and I'm
happy to see it getting ever better.

What is effectively a black hole with respect to our time is the tests
breakage, though. We get new tests failing very regularly (either
through new tests or through new code making old tests fail), and once
the bots are red people tend to pay even less attention to them, so
they spiral out of control in a positive feedback loop until we have
tests failing in the double digits in a matter of days (or hours!). Of
course in an ideal world we'd have a team big enough to always have at
least one person looking at this and fixing the problems the moment
they arise, but unfortunately this is not the case.

I realize this is a very complicated problem to fix unless we throw
more people at it from our side, but maybe we could all agree in some
basic guidelines to make things a bit better:

- If you are adding new functionality + tests that you *know* will
fail in some bots, open a bug describing what we should implement to
get it working, and skip all new tests with a reference to the bug
number. This should be relatively easy to do for the person who
implemented the functionality in the first place, and would save
everyone lots of time in the long run.

- If your new code makes a previously passing test(s) fail in a port
other than your own, you have two choices:
  * If you know what's going on and think this is a bug in the port,
you can propose a patch yourself, or open a bug with your ideas and
skip the tests with a reference to the bug number. Get the port
maintainers on the loop ASAP.
  * If you have no idea of what's going on, maybe Eric's proposed
hard-line policy kicks in: you either figure it out quick and propose
something, or the patch is rolled out until things are clear;
regressions in tests in any port are as bad as build breakages, so
early roll out is preferred to having the bots red for a long time.

As I said, this is a complex problem, but I think at the very least
having a clear picture of what is expected of everyone with respect to
failing tests in the bots would be a good start to make things easier.

Xan


 See you,

 --
 Gustavo Noronha Silva g...@gnome.org
 GNOME Project

 ___
 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] How to cancel a resource request

2009-10-23 Thread Xan Lopez
On Fri, Oct 23, 2009 at 5:37 PM, Jaroslav Gresula
jgresula.leave-this-...@gmail.com wrote:
 Xan Lopez wrote:
 On Fri, Oct 23, 2009 at 5:05 PM, Jaroslav Gresula
 jgresula.leave-this-...@gmail.com wrote:
 Xan Lopez wrote:
 On Thu, Oct 22, 2009 at 11:18 AM, Jaroslav Gresula
 jgresula.leave-this-...@gmail.com wrote:
 Hi,

 In my WebKit port (based on the GTK port) I would like to cancel a
 resource request depending on the resource length or its MIME type.

 I thought, dispatchDidReceiveResponse(DocumentLoader*, ...) in my
 WebCore::FrameLoaderClient implementation could be a good place for such
 action as I can retrieve the length and the MIME type from the
 ResourceResponse argument there. However I did not find the way how to
 cancel the request.

 Any help would be appreciated.

 in dispatchWillSendRequest you can modify the URI of the resource
 that's about to be requested. If you set it to, say, about:blank,
 nothing will be requested. This is what the GTK+ port does, through a
 signal emission, to let clients implement things like adblock.


 That's a nice trick but is the resource MIME type and its length known
 at this point? My understanding is that this information is not
 available until dispatchDidReceiveResponse().

 Well, no, but since you were asking how to cancel the request I
 assumed you wanted to do it before it was done, not after... If you
 want to do things based on the MIME type of the resource see
 dispatchDecidePolicyForMIMEType, which also carries the
 ResourceRequest.

 Ok, let me rephrase my question: what I need is to cancel an ongoing
 (sub)resource request once its length and MIME type are known. This way
 I could avoid retrieving of resources whose length exceeds certain limit
 or whose MIME type can't be handled by my port.

 I've already looked at dispatchDecidePolicyForMIMEType() and it seemed
 to me that it is invoked only for the main resource but not for
 sub-resources (i.e. images) - I will look into it closer.

Ah, you are right, I think it's only emitted for the main resource and
any frame in the page maybe.

So yeah, other than suggesting the method you already mentioned and
the other resource-specific functions in FrameLoaderClient nothing to
add :)

Xan


 Thanks,
 --
 Jarda
 http://jagpdf.org

 ___
 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] Security advice for linux browsers based on WebKit

2009-08-24 Thread Xan Lopez
On Mon, Aug 24, 2009 at 8:23 PM, Serge Noiraudserge.noir...@laposte.net wrote:
 Hi,

 I'm writing a webkit application which use only local files ( gramps-project
 )
 I use python-webkit and pywebkitgtk. This is not a browser for the user.

 If I understand correctly, in a near futur, my application will not work.
 Is there a way to avoid this kind of problem ?
 Can we authorize one application to use local files ?

 I use in python :

       self.window = webkit.WebView()
       settings = self.window.get_settings()
       settings.set_property(enable-developer-extras, True)

 Can we set this property too ? and how ?
 Does this mean python-webkit and pywebkitgtk should take care of this ?

Yes, starting from WebKitGTK+ 1.1.13 (and when the python bindings
catch up) you can do:

settings.set_property(enable-universal-access-from-file-uris, True)

assuming you know what you are doing :)

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