Re: [webkit-dev] Exciting JS features (class fields) in need of review :)
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
Re: [webkit-dev] Exciting JS features (class fields) in need of review :)
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
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?
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
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
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
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
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?
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?
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
[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] Best practices for failing a flaky tests (was Re: Switching to new-run-webkit-tests)
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
