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

[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

[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 :)

[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

[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

[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

[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

[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 :)

[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

[Xan Lopez]

On Tue, Apr 30, 2013 at 9:11 AM, Allan Sandfeld Jensen wrote:

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

[Xan Lopez]

Hi,

On Fri, Apr 5, 2013 at 12:19 AM, Benjamin Poulain wrote:
>
> 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

[Xan Lopez]

Hi Eric,

On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel  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

[Xan Lopez]

On Mon, Jan 21, 2013 at 2:53 PM, Mario Sanchez Prada
 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

[Xan Lopez]

On Sat, Dec 31, 2011 at 9:21 AM, Kentaro Hara  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

[Xan Lopez]

On Sun, Sep 25, 2011 at 9:34 AM, Adam Barth  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?

[Xan Lopez]

On Tue, Aug 23, 2011 at 7:44 PM, William Siegrist  wrote:
> We just used "git svn reset -r " and "git svn fetch" where  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?

[Xan Lopez]

On Thu, Aug 18, 2011 at 6:21 PM, William Siegrist  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  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  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  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  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  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] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)

[Xan Lopez]

On Wed, Jul 6, 2011 at 6:29 PM, Eric Seidel  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

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

[Xan Lopez]

On Wed, Jul 6, 2011 at 5:58 PM, Adam Roben  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] Switching to new-run-webkit-tests

[Xan Lopez]

[Sending with the right address...]

On Wed, Jul 6, 2011 at 11:10 AM, Eric Seidel  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] No getters for iconURL/title/body in Notification.idl

[Xan Lopez]

On Fri, Jul 1, 2011 at 8:17 PM, John Gregg  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

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

[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] Switching to new-run-webkit-tests

[Xan Lopez]

On Tue, Jun 28, 2011 at 1:17 AM, Eric Seidel  wrote:
> There appear to be 6 remaining blocking issues:
> https://bugs.webkit.org/showdependencytree.cgi?id=34984&hide_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?

[Xan Lopez]

On Sun, Jun 26, 2011 at 4:43 AM, Brent Fulgham  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

[Xan Lopez]

On Wed, Mar 2, 2011 at 7:38 PM, Eric Seidel  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

[Xan Lopez]

On Tue, Mar 1, 2011 at 5:35 PM, Artem Kozlov  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

[Xan Lopez]

On Wed, Nov 3, 2010 at 1:20 PM, Fedor Kryukov  wrote:
>
> Thanks,
>
> As I understand this is a WebkitGtk bug only?
> So I can temporarily switch to QT WebKit to avoid leaks?
>

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

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

Xan

>
> Xan Lopez-3 wrote:
>>
>> On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov  wrote:
>>>
>>> After calling webkit_web_view_get_dom_document() and similar functions (
>>> webkit_dom... * ) memory is not freed, what am I doing wrong?
>>>
>>> I wrote simple application which handle events (
>>> load-started/load-finished/etc ) and make some changes in loaded page DOM
>>> content, so after loading several pages I have a lot of lost memory, no
>>> idea
>>> how to release it.
>>>
>>> I tried to use g_object_unref, but it destroys something..
>>> --
>>> View this message in context:
>>> http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html
>>> Sent from the Webkit mailing list archive at Nabble.com.
>>
>> The memory management of the GObject DOM bindings is still a work in
>> progress (unfortunately!). We are trying to figure the best to
>> automatically collect them, but for now you are correct in saying that
>> they are essentially "leaked" until the process is over.
>>
>> See https://bugs.webkit.org/show_bug.cgi?id=40302 for some discussion
>> on the topic. Our plan is to have this issue resolved before the next
>> stable release in April.
>>
>> Xan
>>
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
> --
> View this message in context: 
> http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30126515.html
> Sent from the Webkit mailing list archive at Nabble.com.
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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

[Xan Lopez]

On Wed, Nov 3, 2010 at 7:52 AM, Fedor Kryukov  wrote:
>
> After calling webkit_web_view_get_dom_document() and similar functions (
> webkit_dom... * ) memory is not freed, what am I doing wrong?
>
> I wrote simple application which handle events (
> load-started/load-finished/etc ) and make some changes in loaded page DOM
> content, so after loading several pages I have a lot of lost memory, no idea
> how to release it.
>
> I tried to use g_object_unref, but it destroys something..
> --
> View this message in context: 
> http://old.nabble.com/WebKitGtk-app-memory-leaks-%2C-please-help-tp30121202p30121202.html
> Sent from the Webkit mailing list archive at Nabble.com.

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

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

Xan

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

Re: [webkit-dev] when is expose_event fired

[Xan Lopez]

On Fri, Oct 22, 2010 at 2:10 PM, Aneesh Bhasin  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

[Xan Lopez]

On Fri, Sep 3, 2010 at 9:50 PM, Jeremy Orlow  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

[Xan Lopez]

On Wed, Aug 11, 2010 at 8:39 AM, Xan Lopez  wrote:
> On Wed, Aug 11, 2010 at 7:51 AM, Darin Adler  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 
#import 
#import 
#import 
#import 
#import 
#import 
#import 
#import 
#import 
(...)

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.h&q=DOMUIEvent.h&d=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

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

[Xan Lopez]

On Wed, Aug 11, 2010 at 5:56 PM, Darin Adler  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

[Xan Lopez]

On Wed, Aug 11, 2010 at 7:51 AM, Darin Adler  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

[Xan Lopez]

On Tue, Aug 10, 2010 at 8:59 PM, Xan Lopez  wrote:
> On Tue, Aug 10, 2010 at 8:32 PM, Adam Barth  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] On IDL files, events and writing DOM bindings

[Xan Lopez]

On Tue, Aug 10, 2010 at 8:32 PM, Adam Barth  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

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

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

[Xan Lopez]

On Fri, Jul 9, 2010 at 12:30 AM, Daniel Cheng  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] Frustrated at inconsiderate behavior

[Xan Lopez]

On Thu, Jul 8, 2010 at 11:38 PM, Jeremy Orlow  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

[Xan Lopez]

On Thu, Jul 8, 2010 at 8:09 PM, Adam Barth  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

[Xan Lopez]

On Thu, Jul 8, 2010 at 7:54 PM, Adam Barth  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] Pyjamas-Desktop patch to webkit ??

[Xan Lopez]

On Wed, Jun 9, 2010 at 12:05 PM, Jeremy Orlow  wrote:
> The patch needs a champion who's willing to take the time to get it into
> landable shape.  This mainly means splitting it up into small bits for
> review, cleaning up the code, and fixing problems brought up in review.  It
> will probably require a lot of work.

I did this some time ago already... all of the original patch was
split, massively cleaned up and landed, and we have already support
for new features like DOM events. There's a tracker bug for some of
the work being done: https://bugs.webkit.org/show_bug.cgi?id=38576

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

Re: [webkit-dev] Help fixing crashes on GTK 64-bit?

[Xan Lopez]

On Fri, May 28, 2010 at 6:39 PM, Darin Adler  wrote:
> Hi folks.
>
> My recent patch, http://trac.webkit.org/changeset/60361, seems like it’s 
> making the GTK 64-bit bot crash on every test. I can’t find any evidence of 
> what the problem is. Is there someone who can help me diagnose and fix this? 
> I’d rather fix it than just roll out, if I can get any information about what 
> kind of failure this is.

I think it's a bot issue unrelated to the patch; I'm poking the people
responsible for the Release bots to confirm it.

Xan

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

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

[Xan Lopez]

On Sun, Apr 18, 2010 at 9:17 PM, Eric Seidel  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

[Xan Lopez]

On Fri, Apr 9, 2010 at 2:47 AM, Xan Lopez  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

[Xan Lopez]

On Fri, Apr 9, 2010 at 2:52 AM, Darin Adler  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] Announcing WebKit2

[Xan Lopez]

On Fri, Apr 9, 2010 at 1:01 AM, Anders Carlsson  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] Gtk and Qt bots need love

[Xan Lopez]

On Fri, Mar 19, 2010 at 9:59 PM, Eric Seidel  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

[Xan Lopez]

On Wed, Mar 17, 2010 at 9:02 AM, Adam Barth  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

[Xan Lopez]

On Fri, Feb 26, 2010 at 11:36 AM, Adam Barth  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?

[Xan Lopez]

On Fri, Jan 29, 2010 at 7:53 PM, Joseph Zuromski  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

[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

[Xan Lopez]

On Sun, Dec 13, 2009 at 4:19 AM, Holger Freyther  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

[Xan Lopez]

On Mon, Nov 16, 2009 at 3:33 PM, Gustavo Noronha Silva  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 
> 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

[Xan Lopez]

On Fri, Oct 23, 2009 at 5:37 PM, Jaroslav Gresula
 wrote:
> Xan Lopez wrote:
>> On Fri, Oct 23, 2009 at 5:05 PM, Jaroslav Gresula
>>  wrote:
>>> Xan Lopez wrote:
>>>> On Thu, Oct 22, 2009 at 11:18 AM, Jaroslav Gresula
>>>>  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] How to cancel a resource request

[Xan Lopez]

On Fri, Oct 23, 2009 at 5:05 PM, Jaroslav Gresula
 wrote:
> Xan Lopez wrote:
>> On Thu, Oct 22, 2009 at 11:18 AM, Jaroslav Gresula
>>  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.

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

[Xan Lopez]

On Thu, Oct 22, 2009 at 11:18 AM, Jaroslav Gresula
 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.

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

[Xan Lopez]

On Mon, Aug 24, 2009 at 8:23 PM, Serge Noiraud 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