Re: [webkit-dev] LocalStorage spec and structured cloning
You can't store much data in cookies and thus you're only shooting yourself in the foot with a bb gun. 5mb means you're shooting yourself in the foot with a real gun. And if you're allowing over 5mb, it's a bazooka. Anyway, I've written extensively about this many times on many different lists. Luckily for me, it doesn't look like I need to write yet again since it looks like I've convinced Jonas of my position. :-) J On Thu, Jun 2, 2011 at 10:04 PM, Alexey Proskuryakov a...@webkit.org wrote: I think that these shortcomings are also strengths. A synchronous localStorage is a drop-in replacement for cookies, which is a good thing to offer, and to encourage. Practically, if it's only cookies vs. IndexedDB (or SQL Database), I'd realistically choose the former for most code, and I'm sure that many Web developers would do the same. It doesn't matter all that much if developers encode to JSON themselves or the engine does that, but adding a little syntactic sugar seems beneficial. - WBR, Alexey Proskuryakov 02.06.2011, в 20:54, Darin Fisher написал(а): I'm concerned that implementing this will only encourage more use of localStorage. The API is very poor because it requires synchronous IO and synchronization between browser contexts, which may live on different threads. (Note: Chrome does not implement the required synchronization.) If we could fix localStorage to be asynchronous and transactional :-) then it'd be cool. Of course, one answer is that people should just use IndexedDB. FWIW, Jorlow (when he was still working on chrome) expressed similar sentiments. On Jun 2, 2011 4:13 PM, Maciej Stachowiak m...@apple.com wrote: Does anyone have an opinion on this Web Storage spec bug? The input of the WebKit community is desired. And probably Safari and Chrome folks in particular, if opinions differ. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that The getItem(key) method must return a structured clone of the current value associated with the given key. but all browsers I've tested return a string representation of the value instead. Regards, Maciej ___ 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] LocalStorage spec and structured cloning
On Fri, Jun 3, 2011 at 1:40 AM, Jeremy Orlow jor...@chromium.org wrote: You can't store much data in cookies and thus you're only shooting yourself in the foot with a bb gun. 5mb means you're shooting yourself in the foot with a real gun. And if you're allowing over 5mb, it's a bazooka. ...and for this reason, Chromium will never give developers more than 5mb of localStorage space (even if we give them more space for other APIs). (I've lobbied for even reducing the space we hand out...not sure if that'll happen though.) Anyway, I've written extensively about this many times on many different lists. Luckily for me, it doesn't look like I need to write yet again since it looks like I've convinced Jonas of my position. :-) J On Thu, Jun 2, 2011 at 10:04 PM, Alexey Proskuryakov a...@webkit.orgwrote: I think that these shortcomings are also strengths. A synchronous localStorage is a drop-in replacement for cookies, which is a good thing to offer, and to encourage. Practically, if it's only cookies vs. IndexedDB (or SQL Database), I'd realistically choose the former for most code, and I'm sure that many Web developers would do the same. It doesn't matter all that much if developers encode to JSON themselves or the engine does that, but adding a little syntactic sugar seems beneficial. Also note that such syntactic sugar breaks compat. (There's a concise example in the bug.) I think it's best just to leave localStorage as is... J - WBR, Alexey Proskuryakov 02.06.2011, в 20:54, Darin Fisher написал(а): I'm concerned that implementing this will only encourage more use of localStorage. The API is very poor because it requires synchronous IO and synchronization between browser contexts, which may live on different threads. (Note: Chrome does not implement the required synchronization.) If we could fix localStorage to be asynchronous and transactional :-) then it'd be cool. Of course, one answer is that people should just use IndexedDB. FWIW, Jorlow (when he was still working on chrome) expressed similar sentiments. On Jun 2, 2011 4:13 PM, Maciej Stachowiak m...@apple.com wrote: Does anyone have an opinion on this Web Storage spec bug? The input of the WebKit community is desired. And probably Safari and Chrome folks in particular, if opinions differ. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that The getItem(key) method must return a structured clone of the current value associated with the given key. but all browsers I've tested return a string representation of the value instead. Regards, Maciej ___ 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] bugid in ChangeLog
Can you please explain why? Its very little overhead and is useful for tracking regressions and such. J On Mar 28, 2011 9:52 AM, Darin Adler da...@apple.com wrote: On Mar 27, 2011, at 1:31 AM, Jeremy Orlow wrote: I'd even go a bit further and say that if something is worth a review (even if it's over the shoulder), it's worth a bug + a bug number. This is where I do not agree. Review is a requirement, but I don’t think bugs.webkit.org should be. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bugid in ChangeLog
On Mon, Mar 28, 2011 at 10:06 AM, David Levin le...@chromium.org wrote: Here's a change that I felt worth getting someone to glance at but didn't feel worth the overhead of a bug: http://trac.webkit.org/changeset/81305 Since I was gardener and this was affecting the bots, it was a timely situation. (Sometimes getting in your fix right before another break comes in is important in these cases.) dave PS Dmitry found a flaw in my original change log text -- due to my haste, I originally had put in the wrong valgrind error. This seems like the kind of thing that'd be nice to put in the bug after the fact, no? :-) If the issue is simply one of overhead, then we should allow committers to omit change logs when they're not necessary as well. For example, no matter how one feels about ChangeLogs, I don't think it's possible to claim it's useful here: http://trac.webkit.org/changeset/81864 J On Mon, Mar 28, 2011 at 9:58 AM, Jeremy Orlow jor...@chromium.org wrote: Can you please explain why? Its very little overhead and is useful for tracking regressions and such. J On Mar 28, 2011 9:52 AM, Darin Adler da...@apple.com wrote: On Mar 27, 2011, at 1:31 AM, Jeremy Orlow wrote: I'd even go a bit further and say that if something is worth a review (even if it's over the shoulder), it's worth a bug + a bug number. This is where I do not agree. Review is a requirement, but I don’t think bugs.webkit.org should be. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bugid in ChangeLog
On Mon, Mar 28, 2011 at 11:48 AM, Maciej Stachowiak m...@apple.com wrote: I think it's better to have no exceptions than a very narrow exception. This seems to be a reason for saying we should always have a bug for anything that's reviewed... J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bugid in ChangeLog
On Mon, Mar 28, 2011 at 11:51 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Mar 28, 2011 at 11:48 AM, Maciej Stachowiak m...@apple.com wrote: I think it's better to have no exceptions than a very narrow exception. This seems to be a reason for saying we should always have a bug for anything that's reviewed... Sorry, that may have been overly terse. What I mean to say is that there are probably more changes (like test meta-data changes) where a ChangeLog is clearly not necessary than changes that need to be reviewed but a bug is clearly not required. If we're splitting hairs about the one, then I think it's perfectly legit to talk about the other. (Which I brought up because of my particular hatred for ChangeLogs. :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Towards a unified build system
On Tue, Mar 1, 2011 at 11:08 AM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 01.03.2011 um 18:33 schrieb Maciej Stachowiak: On Mar 1, 2011, at 5:18 AM, Adam Roben wrote: Reducing the number of build systems is a face-meltingly worthy goal. I have one small question: On Mar 1, 2011, at 4:21 AM, Adam Barth wrote: 3) Remove the xcodeproj files from svn.webkit.org and integrate the generation of xcodeproj files with the WebKit build / update scripts. At this point, contributors will notice that something has changed because there'll be one less build system to worry about keeping up to date! Won't contributors who don't use update-webkit/build-webkit also notice something has changed, because they will no longer have any project files? (I ask this as a contributor who doesn't use update-webkit/build-webkit.) Another consequence of step 3 is it would break submissions to Apple's central build system, since those pull from the repository with vanilla SVN and do not run special scripts afterwards. What about checking in the generated Xcodeproj? Would that be an option? We could quickly find ourselves in the position of generating build files for many different ports every time we submit patches, which could add several minutes to the submit process (which is even worse if you lose a race with another committer and have to update/rebase and try again). Generating on checkout seems like the best answer--if feasible. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Towards a unified build system
On Tue, Mar 1, 2011 at 1:59 PM, David Levin le...@google.com wrote: On Tue, Mar 1, 2011 at 1:13 PM, Jeremy Orlow jor...@chromium.org wrote: We could quickly find ourselves in the position of generating build files for many different ports every time we submit patches, which could add several minutes to the submit process The alternative is to get everyone to spend this time :). (Seems better to submit them with the change from this perspective.) True. (which is even worse if you lose a race with another committer and have to update/rebase and try again). I did a log (git whatchanged --diff-filter=AD --pretty=oneline --abbrev-commit) and it appeared that there were about ~4 check-ins per day that added or deleted files, so this race wouldn't be hit very often. Good point. I was just thinking in terms of the times I get a ChangeLog conflict, but we should hit a conflict on build files much less often. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug
It seems like it'd be nice to be able to watch bugs that are assigned to someone too though. On Thu, Feb 10, 2011 at 11:18 AM, Alexey Proskuryakov a...@webkit.org wrote: 10.02.2011, в 10:58, Darin Fisher написал(а): What Mozilla does is they set the QA Contact field to an email address of the form component@product.bugs. We don't have that field in bugs.webkit.org, so we'd need to either add it, some other field, or maybe we could just get by with adding this email address to the CC list. One thing that can probably be easily done is changing default assignee for Inspector bugs. People could then watch this e-mail address. - WBR, Alexey Proskuryakov ___ 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] Using Visual Studio 2010 for Apple's Windows WebKit port
How hard will the transition be? If it's going to take a lot of time and cause a lot of churn anyway, would this be a good time to try and make that port use GYP or CMake? (I assume the answer is probably no, but figured it was worth asking anyway. :-) J On Mon, Jan 31, 2011 at 12:46 PM, Adam Roben aro...@apple.com wrote: On Jan 31, 2011, at 3:41 PM, Peter Kasting wrote: On Mon, Jan 31, 2011 at 12:30 PM, Adam Roben aro...@apple.com wrote: Please let me (and the list) know if this change will cause you trouble, and if there's something we can do to make the transition easier. This may make life hard on Chromium as right now we don't support building with VS2010. We are working on adding support (I think http://crbug.com/25628 may be the closest bug). I'm not sure what time frame that will happen in. I don't think we have any plans to drop VS2005 support. If WebKit drops support it may force us to do so as well. In both cases above we're not so much impacted by vcproj/sln changes (since we use GYP to construct our vcproj and sln files) as we are by code changes, e.g. code that requires VS2010 to build correctly. I doubt that maintaining compatibility with VS2005's compiler would be an issue. As long as there's an EWS and/or buildbot to catch problems, we should be able to work around any compiler differences. I didn't mean to imply that we'd intentionally break compilation with VS2005's compiler; all I meant was that using VS2005 to build Apple's port would no longer be supported. -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] Same Origin Restriction on WOFF fonts across WebKit
On Fri, Jan 28, 2011 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 28, 2011, at 3:06 PM, Tab Atkins Jr. wrote: The WOFF font specification requires that browsers apply Same Origin Restrictions (SOR) to WOFF fonts. So far, Firefox and IE9 follow this requirement, while we and Opera don't. As far as I know, our lack of SOR is basically an accident; we implemented support for WOFF before this requirement was added, and just haven't gotten around to adding it in yet. Chrome people seem amenable to applying SOR to WOFF fonts in Chrome. Is it okay to add this across all our webkit ports? It's not an accident. It has been our intent to willfully ignore this requirement. Can you please clarify whom you mean by our and the reason for ignoring it? Do we expect this to change in the future and/or are efforts being made to see it happen? J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blog post(s) about layout tests
On Thu, Jan 27, 2011 at 9:32 AM, Ryan Leavengood leaveng...@gmail.comwrote: On Tue, Jan 25, 2011 at 9:24 PM, Mihai Parparita mih...@chromium.org wrote: The post is link-heavy (generally into Trac, and Bugzilla), I'm hoping that would also encourage exploration of the code/site by people interested in contributing. As a WebKit porter who is actually not very familiar with the Layout Tests I found reading these posts pretty useful and informative (it also reminds me I really need to get the Layout Tests going in the Haiku port.) I do think that maybe it is a little too link heavy though. So many links can get a little overwhelming and distracting when reading an article like that. Though they are probably useful to illustrate your points so I think it would be fine to leave them. Maybe have a resources section at the end of the article and move most of the links there instead? I also tend to read like an editor and I did not see anything glaringly wrong spelling or grammar-wise. I don't know the process for getting blog posts on blog.webkit.org, but I'll at least give the content of these posts a +1. -- Regards, Ryan ___ 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] Using Git for WebKit development
The info is on https://trac.webkit.org/wiki/UsingGitWithWebKit as well. On Tue, Jan 18, 2011 at 8:42 AM, Philippe Normand pnorm...@igalia.comwrote: On Tue, 2011-01-18 at 11:26 +0300, Konstantin Tokarev wrote: Hi all, When I'm trying to cherry-pick or rebase something in my WebKit git clone, I constantly end up with conflicts in changelog files How do you fight this problem? Add in your .git/config: [merge changelog] driver = Tools/Scripts/resolve-ChangeLogs --merge-driver %O %A % B Philippe ___ 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] Getting at Settings object from WorkerContext
The RuntimeEnabledFeatures class [1] seems like what you're looking for. J [1] http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/bindings/generic/RuntimeEnabledFeatures.hq=RuntimeFeatureexact_package=chromiumd=6 On Thu, Jan 6, 2011 at 6:05 PM, Joe Mason jma...@rim.com wrote: I'm trying to add a setting to enable/disable WebSockets at runtime (so that the browser can make websockets available as a user preference, for instance). It's easy to add a flag to Settings, and check it from JSDOMWindowCustom::webSocket to return undefined for the websocket object when it's disabled. But you can also get a websocket object from a worker, with JSWorkerContext::webSocket. And since there's no frame or page associated here, there's no way to get a Settings object. Is it possible to get a Settings object from a WorkerContext? If not, I think I need to make the setting a static on the Settings object. There's precedent for this in setMinDOMTimerInterval and setShouldUseHighResolutionTimer, but it doesn't feel right for a high-level feature like this. Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Getting at Settings object from WorkerContext
Hmm. It might still be v8-only, though I'm surprised since the class was
moved from the v8 directory to generic. If that's the case, then I suppose
it'll need to be ported to JSC.
J
On Thu, Jan 6, 2011 at 7:24 PM, Joe Mason jma...@rim.com wrote:
Hmm, I can’t get the RuntimeEnabledFeatures class working.
bool RuntimeEnabledFeatures::webSocketEnabled()
{
return WebSocket::isAvailable();
}
So it looks from that like I should just be able to call
WebSocket::setIsAvailable(false), and then websockets would automatically
drop out. But when I tried that (and I’ve verified that nothings setting it
to true behind my back), JSDOMWindow::webSocket still gets called and
returns the socket prototype. I can’t seem to find any code that calls
webSocketEnabled.
I notice that RuntimeEnabledFeatures is referenced in CodeGeneratorV8.pm,
but not any other code generator. Is this a V8-only thing?
Joe
*From:* webkit-dev-boun...@lists.webkit.org [mailto:
webkit-dev-boun...@lists.webkit.org] *On Behalf Of *Joe Mason
*Sent:* Thursday, January 06, 2011 1:52 PM
*To:* Jeremy Orlow
*Cc:* webkit-dev Development
*Subject:* Re: [webkit-dev] Getting at Settings object from WorkerContext
Aha, there is already a “websocketsEnabled” method there! Thanks, that’s
perfect.
*From:* jor...@google.com [mailto:jor...@google.com] *On Behalf Of *Jeremy
Orlow
*Sent:* Thursday, January 06, 2011 1:25 PM
*To:* Joe Mason
*Cc:* webkit-dev Development
*Subject:* Re: [webkit-dev] Getting at Settings object from WorkerContext
The RuntimeEnabledFeatures class [1] seems like what you're looking for.
J
[1]
http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/bindings/generic/RuntimeEnabledFeatures.hq=RuntimeFeatureexact_package=chromiumd=6
On Thu, Jan 6, 2011 at 6:05 PM, Joe Mason jma...@rim.com wrote:
I'm trying to add a setting to enable/disable WebSockets at runtime (so
that the browser can make websockets available as a user preference, for
instance). It's easy to add a flag to Settings, and check it from
JSDOMWindowCustom::webSocket to return undefined for the websocket object
when it's disabled. But you can also get a websocket object from a worker,
with JSWorkerContext::webSocket. And since there's no frame or page
associated here, there's no way to get a Settings object.
Is it possible to get a Settings object from a WorkerContext?
If not, I think I need to make the setting a static on the Settings object.
There's precedent for this in setMinDOMTimerInterval and
setShouldUseHighResolutionTimer, but it doesn't feel right for a high-level
feature like this.
Joe
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman
Re: [webkit-dev] Getting at Settings object from WorkerContext
Btw, the reason that this behavior has to live in the bindings and not
WebCore is to ensure feature detection code still works. For example, if
indexedDB is disabled at runtime, then the webkitIndexedDB attribute on
window needs to not exist in any form.
Also, IIRC, because of optimizations, the runtime features are actually more
of initialize time features in v8. I.e. once window has been accessed, any
of the RuntimeEnabledFeatures settings are locked in until you restart
WebKit. I don't know how hard it'd be to make it something that can change
on the fly.
J
On Thu, Jan 6, 2011 at 7:38 PM, Jeremy Orlow jor...@chromium.org wrote:
Hmm. It might still be v8-only, though I'm surprised since the class was
moved from the v8 directory to generic. If that's the case, then I suppose
it'll need to be ported to JSC.
J
On Thu, Jan 6, 2011 at 7:24 PM, Joe Mason jma...@rim.com wrote:
Hmm, I can’t get the RuntimeEnabledFeatures class working.
bool RuntimeEnabledFeatures::webSocketEnabled()
{
return WebSocket::isAvailable();
}
So it looks from that like I should just be able to call
WebSocket::setIsAvailable(false), and then websockets would automatically
drop out. But when I tried that (and I’ve verified that nothings setting it
to true behind my back), JSDOMWindow::webSocket still gets called and
returns the socket prototype. I can’t seem to find any code that calls
webSocketEnabled.
I notice that RuntimeEnabledFeatures is referenced in CodeGeneratorV8.pm,
but not any other code generator. Is this a V8-only thing?
Joe
*From:* webkit-dev-boun...@lists.webkit.org [mailto:
webkit-dev-boun...@lists.webkit.org] *On Behalf Of *Joe Mason
*Sent:* Thursday, January 06, 2011 1:52 PM
*To:* Jeremy Orlow
*Cc:* webkit-dev Development
*Subject:* Re: [webkit-dev] Getting at Settings object from WorkerContext
Aha, there is already a “websocketsEnabled” method there! Thanks, that’s
perfect.
*From:* jor...@google.com [mailto:jor...@google.com] *On Behalf Of *Jeremy
Orlow
*Sent:* Thursday, January 06, 2011 1:25 PM
*To:* Joe Mason
*Cc:* webkit-dev Development
*Subject:* Re: [webkit-dev] Getting at Settings object from WorkerContext
The RuntimeEnabledFeatures class [1] seems like what you're looking for.
J
[1]
http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/third_party/WebKit/WebCore/bindings/generic/RuntimeEnabledFeatures.hq=RuntimeFeatureexact_package=chromiumd=6
On Thu, Jan 6, 2011 at 6:05 PM, Joe Mason jma...@rim.com wrote:
I'm trying to add a setting to enable/disable WebSockets at runtime (so
that the browser can make websockets available as a user preference, for
instance). It's easy to add a flag to Settings, and check it from
JSDOMWindowCustom::webSocket to return undefined for the websocket object
when it's disabled. But you can also get a websocket object from a worker,
with JSWorkerContext::webSocket. And since there's no frame or page
associated here, there's no way to get a Settings object.
Is it possible to get a Settings object from a WorkerContext?
If not, I think I need to make the setting a static on the Settings
object. There's precedent for this in setMinDOMTimerInterval and
setShouldUseHighResolutionTimer, but it doesn't feel right for a high-level
feature like this.
Joe
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.
-
This transmission (including any attachments) may contain confidential
information
Re: [webkit-dev] RuntimeEnabledFeatures for JSC (was RE: Getting at Settings object from WorkerContext)
On Thu, Jan 6, 2011 at 8:57 PM, Adam Barth aba...@webkit.org wrote: On Thu, Jan 6, 2011 at 12:47 PM, Darin Adler da...@apple.com wrote: On Jan 6, 2011, at 12:41 PM, Joe Mason wrote: I took a look at CodeGeneratorJS.pm to see how hard it would be to port this over. I have no idea where to start… The structure of CodeGeneratorJS.pm and CodeGeneratorV8.pm seem quite different. This also seems like a lot of work to do just to enable/disable one feature, but I guess if there’s no framework for enabling/disabling JS features in JSC at all then it’s necessary. I’m sad that the V8 code generator script diverged so much from the original. It would be great if they were kept closer. I have refactored them to become more similar and even share code whenever I had to modify both, such as when making changes to [Reflect]. That's one my list of things I'd like to do, but my Perl isn't strong enough yet. :( FWIW: Whenever this has come up in the past, I believe the consensus has been that a re-write in Python would be acceptable. Is there wide agreement that porting the RuntimeEnabledFeatures to JSC is a good idea? I think it would probably be good. Not sure why the person who did it originally did it V8-only. There's been some discussion about it in the past on webkit-dev. I think the issue revolves around the way JavaScriptCore uses static tables to store properties. It's important that runtime disabled properties are completely disabled (e.g., webkitIndexedDB in window returns false). If you're able to get it to work, that's great! 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] Tip: Use 64-bit git binaries on Mac OS X
For what it's worth, on my 12GB of ram mac pro: $ sudo sysctl -w kern.maxvnodes=384000 kern.maxvnodes: 197632 - 384000 Took times from 2.11-2.06 down to 2.05-2.02. I.e. it made a small difference, but not much. The 64 bit patch definitely seemed to help, but I didn't think to time before and after. J On Wed, Dec 8, 2010 at 11:38 PM, Eric Seidel e...@webkit.org wrote: Mark Rowe pointed out to me over IRC that the real problem is we're blowing out the vnode cache. Even on an 8GB machine, the default cache is too small for all of WebKit to fit in it. On my 4GB machine (and on Mark's 8GB) we tried incrementing the cache to 384000 (the 4GB default is 64512 and the 8GB default is 128000). My git status times dropped again by over 50% to 2.6 seconds! (still an eternity compared to a linux machine of course...) If you'd like to play around with this, you can set your vnode cache limit with: sudo sysctl -w kern.maxvnodes=384000 You can read it with: sysctl kern.maxvnodes You can test to see if the cache is large enough by trying: git status; time git status the second one should be very fast if your cache is large enough. I don't know what the exact right trade-off is. I believe the vnode cache uses wired memory (which is a limited resource!). As far as I can tell you can't decrease the cache max w/o rebooting. sysctl will set it, but setting it to a smaller number seems to have not effect. I don't know how to make the setting last across reboots. Mark mentioned that putting the setting in /etc/sysctl.conf should work, but that at least for his machine that didn't seem to have any effect for this particular setting. That's what I know. -eric On Wed, Dec 8, 2010 at 3:02 PM, Eric Seidel e...@webkit.org wrote: FYI, my git status runs on my Mac Book Pro were an average of 9.2 seconds (git version 1.7.1, git-osx-installer) before installing Mihai's 64bit build (git version 1.7.3.3), and were 6.0 seconds after. -eric On Wed, Dec 8, 2010 at 2:20 PM, Eric Seidel e...@webkit.org wrote: I've posted a patch to make webkit-patch warn users when they're on a 64-bit system with a 32-bit git: https://bugs.webkit.org/show_bug.cgi?id=50715 4 seconds on every git status is huge. webkit-patch upload has to run at least 3 git status commands (due to expecting files to change on disk during operation), so this means a savings of 12 seconds on your machine! -eric On Tue, Dec 7, 2010 at 4:04 PM, Mihai Parparita mih...@chromium.org wrote: After complaining to a Linux-using friend for the n-th time that git status was much slower on my Snow Leopard machine than on his Linux box, I decided to look into why this is. As it turns out, most people get git binaries from http://code.google.com/p/git-osx-installer/, which are 32-bit. Switching to 64-bit binaries made git status go from 6.58s to 2.50s (mainly because this does fewer mmaps). You can download a 64-bit binary installer from https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg , or you can build it yourself (more details at http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html ). Mihai ___ 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] [chromium] using WEBKIT_API properly
You forgot to mention virtual functions, which is another case where you do _not_ use WEBKIT_API. J On Thu, Dec 2, 2010 at 9:27 PM, Darin Fisher da...@chromium.org wrote: If you do not work on the Chromium port of WebKit, you can stop reading now. I've noticed that there is some confusion about how to use WEBKIT_API properly. WEBKIT_API causes a function to be exported from WebKit when it is built as a DLL, allowing Chromium to call the function. The rule is actually quite simple: WEBKIT_API should be affixed to any public, non-inline function that is intended for the embedder (Chromium) to call. Put another way: -- Do not apply WEBKIT_API to inline functions. -- Do not apply WEBKIT_API to private functions. -- Do not apply WEBKIT_API to public functions within a #if WEBKIT_IMPLEMENTATION block. (Of related note, we never put WEBKIT_API on public constructors and destructors. Instead, we have constructors call an initialize method and destructors call a reset method. Those then end up having the WEBKIT_API prefix applied.) Thanks! -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] Why are the mock implementations in WebCore/platform?
Note that it's still a bit of an open question as to where mocks should live in general. IIRC, the top candidates are like device orientation and speech do now, somehow in some central place but not compiled into production libraries, or in DRT (which means more copied code, but the platform layers will be better exercised). It would be nice to get this resolved once and for all and get the code cleaned up. J On Fri, Nov 26, 2010 at 6:33 PM, Sam Weinig sam.wei...@gmail.com wrote: Just a general question as to why the decision was made to put the mock implementation classes (DeviceOrientationClientMock, GeolocationServiceMock and SpeechInputClientMock) beneath WebCore/platform. WebCore/platform is not supposed to know about classes outside of WebCore/platform in WebCore (such as DeviceOrientationController) and this seems to be perpetuating the laying violation. Perhaps a top-level WebCore/mock/ would be preferable. - Sam ___ 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] Enhancements
On Tue, Nov 23, 2010 at 10:51 PM, Jack Allegrezza jackallegre...@mac.comwrote: Hello, I am proposing that WebKit have an Enhancements ability - Here is what the reason is - with abilities of WebKit to draw and handle THML,SVG, Canvas and Video, along with access to resources via AJAX and WebSockets and al the speed improvements to javascript, we can now make full applications in the browser, The draw back is that in loading the page you also get the application. And the use of plugins is not a good option because it breaks thru the sandbox protection aspect of the browser. And the javascript is visible to anyone. So we seems to be in need of a way to provide safe executable programs to the browser. So either a way to make the javascript invisible (but users may get the source like open source if you wish). Or allowing the download and loading of object code that has has been linked with a lib that only allows access to the DOM javascript and the connection (ajax) and doe not require restarting the browser - also the code should be run in a safe protected area of the browser to check it to see if it attempts to reach ares not allowed. So it is like a plugin or javascript but with invisibility and still maintains the security of the browser. So if a developer was to make some special image processing unit and then apply that an image - they would be able to without giving it away. In any case it's a discussion about private secure safe program in the browser - and is the need real and can it be done Please read http://webkit.org/contact.html This is not the right place for such discussions. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tiger?
Ping? On Mon, Oct 11, 2010 at 9:26 AM, Adam Barth aba...@webkit.org wrote: I don't see a Tiger buildbot anymore. Does that mean I'm allowed to break the Tiger build? If so, can we rip out all the Tiger-specific code? 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] Pixel test experiment
On Tue, Oct 12, 2010 at 1:43 PM, James Robinson jam...@google.com wrote: To add a concrete data point, http://trac.webkit.org/changeset/69517 caused a number of SVG tests to fail. It required 14 text rebaselines for Mac and a further two more for Leopard (done by Adam Barth). In order to pass the pixel tests in Chromium, it required 1506 new pixel baselines (checked in by the very brave Albert Wong, http://trac.webkit.org/changeset/69543). None of the rebaselining was done by the patch authors and in general I would not expect a patch author that didn't work in Chromium to be expected to update Chromium-specific baselines. I'm a little skeptical of the claim that all SVG changes are run through the pixel tests given that to date none of the affected platform/mac SVG pixel baselines have been updated. This sort of mass-rebaselining is required fairly regularly for minor changes in SVG and in other parts of the codebase. I'd really like for the bots to run the pixel tests on every run, preferably with 0 tolerance. We catch a lot of regressions by running these tests on the Chromium bots that would probably otherwise go unnoticed. However there is a large maintenance cost associated with this coverage. We normally have two engineers (one in PST, one elsewhere in the world) who watch the Chromium bots to triage, suppress, and rebaseline tests as churn is introduced. This isn't to say that it's 2 full time people worth of work to keep them up to date though. Background: Pixel tests and Chromium tests (i.e. tests that touch the full Chromium stack, performance tests, valgrind, etc) both rely on code in Chromium's SVN repo which is why we don't have them on build.webkit.org. One of the major jobs of the WebKit gardener (which James mentioned) is triaging these failures and fixing them, filing upstream bugs, backing out the changes (when they are true regressions and the author is not around and cannot be easily fixed), and/or rebaslining when appropriate. Another major job (and part of why we try to have near 24 hour coverage) is keeping the build from breaking so that our bots don't go blind. So the actual act of rebaslining is only a small component of their job. Questions: - If the pixel tests were running either with a tolerance of 0 or 0.1, what would the expectation be for a patch like http://trac.webkit.org/changeset/69517 which requires hundreds of pixel rebaselines? Would the patch author be expected to update the baselines for the platform/mac port, or would someone else? Thus far the Chromium folks have been the only ones actively maintaining the pixel baselines - which I think is entirely reasonable since we're the only ones trying to run the pixel tests on bots. - Do we have the tools and infrastructure needed to do mass rebaselines in WebKit currently? We've built a number of tools to deal with the Chromium expectations, but since this has been a need unique to Chromium so far the tools only work for Chromium. - James On Fri, Oct 8, 2010 at 11:18 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 08.10.2010 um 20:14 schrieb Jeremy Orlow: I'm not an expert on Pixel tests, but my understanding is that in Chromium (where we've always run with tolerance 0) we've seen real regressions that would have slipped by with something like tolerance 0.1. When you have 0 tolerance, it is more maintenance work, but if we can avoid regressions, it seems worth it. Well, that's why I initially argued for tolerance 0. Especially in SVG we had lots of regressions in the past that were below the 0.1 tolerance. I fully support --tolerance 0 as default. Dirk me are also willing to investigate possible problem sources and minimize them. Reftests as Simon said, are a great thing, but it won't help with official test suites like the W3C one - it would be a huge amount of work to create reftests for all of these... Cheers, Niko ___ 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] Pixel test experiment
I'm not an expert on Pixel tests, but my understanding is that in Chromium (where we've always run with tolerance 0) we've seen real regressions that would have slipped by with something like tolerance 0.1. When you have 0 tolerance, it is more maintenance work, but if we can avoid regressions, it seems worth it. J On Fri, Oct 8, 2010 at 10:58 AM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 08.10.2010 um 19:53 schrieb Maciej Stachowiak: On Oct 8, 2010, at 12:46 AM, Nikolas Zimmermann wrote: Am 08.10.2010 um 00:44 schrieb Maciej Stachowiak: On Oct 7, 2010, at 6:34 AM, Nikolas Zimmermann wrote: Good evening webkit folks, I've finished landing svg/ pixel test baselines, which pass with --tolerance 0 on my 10.5 10.6 machines. As the pixel testing is very important for the SVG tests, I'd like to run them on the bots, experimentally, so we can catch regressions easily. Maybe someone with direct access to the leopard snow leopard bots, could just run run-webkit-tests --tolerance 0 -p svg and mail me the results? If it passes, we could maybe run the pixel tests for the svg/ subdirectory on these bots? Running pixel tests would be great, but can we really expect the results to be stable cross-platform with tolerance 0? Perhaps we should start with a higher tolerance level. Sure, we could do that. But I'd really like to get a feeling, for what's problematic first. If we see 95% of the SVG tests pass with --tolerance 0, and only a few need higher tolerances (64bit vs. 32bit aa differences, etc.), I could come up with a per-file pixel test tolerance extension to DRT, if it's needed. How about starting with just one build slave (say. Mac Leopard) that runs the pixel tests for SVG, with --tolerance 0 for a while. I'd be happy to identify the problems, and see if we can make it work, somehow :-) The problem I worry about is that on future Mac OS X releases, rendering of shapes may change in some tiny way that is not visible but enough to cause failures at tolerance 0. In the past, such false positives arose from time to time, which is one reason we added pixel test tolerance in the first place. I don't think running pixel tests on just one build slave will help us understand that risk. I think we'd just update the baseline to the newer OS X release, then, like it has been done for the tiger - leopard, leopard - snow leopard switch? platform/mac/ should always contain the newest release baseline, when therere are differences on leopard, the results go into platform/mac-leopard/ Why not start with some low but non-zero tolerance (0.1?) and see if we can at least make that work consistently, before we try the bolder step of tolerance 0? Also, and as a side note, we probably need to add more build slaves to run pixel tests at all, since just running the test suite without pixel tests is already slow enough that the testers are often significantly behind the builders. Well, I thought about just running the pixel tests for the svg/ subdirectory as a seperate step, hence my request for tolerance 0, as the baseline passes without problems at least on my Dirks machine already. I wouldnt' want to argue running 20.000+ pixel tests with tolerance 0 as first step :-) But the 1000 SVG tests, might be fine, with tolerance 0? Even tolerance 0.1 as default for SVG would be fine with me, as long as we can get the bots to run the SVG pixel tests :-) Cheers, Niko ___ 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] Pixel test experiment
This does seem like a great idea. The more pixel tests we can run on the bots, the better! J On Thu, Oct 7, 2010 at 11:06 AM, Dirk Schulze k...@webkit.org wrote: I strongly support pixel tests for SVG on the bots! Niko and me are hard working to get SVG pxiel perfect at all time. We run pixel tests on every patch we apply to the SVG code. And it would really help us if the bots blame any change that causes a pixel test to fail, or at least give some kind of feedback. Dirk Good evening webkit folks, I've finished landing svg/ pixel test baselines, which pass with --tolerance 0 on my 10.5 10.6 machines. As the pixel testing is very important for the SVG tests, I'd like to run them on the bots, experimentally, so we can catch regressions easily. Maybe someone with direct access to the leopard snow leopard bots, could just run run-webkit-tests --tolerance 0 -p svg and mail me the results? If it passes, we could maybe run the pixel tests for the svg/ subdirectory on these bots? Cheers, Niko ___ 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] Upgrading VS (WAS: Any objections to switching to Xcode 3.2.4 or newer?)
Although this is a noble goal, wouldn't it require either 1) Us maintaining yet another build system or 2) Any Windows based WebKit hackers needing to upgrade their Visual Studio...which would require $$? [1] Either way, what's our migration plan (since we can't use VS 2005 forever)? J [1] Yes xcode does require a mac, and that's not free, but anyone already using a particular version of xcode should be able to upgrade, right? On Wed, Oct 6, 2010 at 8:08 PM, Brent Fulgham bfulg...@gmail.com wrote: Can we go one better and also update Visual Studio? :-) On Oct 6, 2010, at 5:55 PM, Chris Marrin wrote: +1 +1 +1 ! On Oct 6, 2010, at 5:00 PM, Darin Adler wrote: Hi folks. For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. ___ 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] a ping landed
Given that a ping really doesn't open up any new privacy holes (just makes it easier for sites to get the data they're going to gather anyway without slowing down the experience for the user), it seems like we might as well enable it by default. If a port doesn't want it, they can always disable it, right? Thanks, J On Fri, Oct 1, 2010 at 12:39 PM, Nate Chapin jap...@chromium.org wrote: This is a few days late, but I just wanted to let the team know that, as of http://trac.webkit.org/changeset/68166, WebKit can support a pinghttp://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#hyperlink-auditing(but support is disabled by default). The reason I left it disabled by default is that some ports may want to have a mechanism for disabling pings, and I didn't want anyone to accidentally pick it up before they were ready. I'm happy to flip it to enabled by default if that's what people prefer. ~Nate ___ 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] Disable sheriffbot bug posts?
They've also helped me on occasion. I get enough bug spam already that even in the worst case, I don't find the notices all that obtrusive. More useful messages would be nice though. J On Thu, Sep 23, 2010 at 10:28 PM, Geoffrey Garen gga...@apple.com wrote: Does anyone find the sheriffbot bug posts useful? My sense is that they're too noisy because of flaky tests and large blamelists. I'm inclined to turn them off unless someone else is finding them useful. FWIW, they've helped me on occasion and spammed me on occasion. Typically, I don't mind the spam too much because it comes after the last meaningful post in the bug, so it doesn't take too much cognitive load to ignore it when necessary. Geoff ___ 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] Bug system: Platform and OS fields don't quite align
On Tue, Sep 14, 2010 at 6:32 PM, David Levin le...@chromium.org wrote: On Tue, Sep 14, 2010 at 10:28 AM, Adam Barth aba...@webkit.org wrote: We're not very good at using these fields in Bugzilla. In this situation, folks will usually prefix the summary of the bug with [Chromium]. This is a signal to reviewers that they might be more or less interested in reviewing the patch depending on whether they like/feel comfortably with reviewing patches to WebKit/chromium. Note that bugs should only have [Chromium] in the title if the patch *only* touches Chromium specific files. (Right now, I consider this to be skia related files, v8 related files, and then the files that are obviously chromium due to name or directory structure -- I say right now because I see there are efforts to make skia useful outside of Chromium.) It's worth noting that Android also uses v8 and skia. They only have one reviewer at the moment, but it still might be best to not associate Chromium with skia/v8 changes. As for the original questions: does anyone actually use any of those categories in bugs? If not, is there any way to get rid of them? As far as I'm aware, they're just noise at the moment. Adam On Tue, Sep 14, 2010 at 10:20 AM, Mike Belshe m...@belshe.com wrote: Hi, I tend to hit code which is often chromium-platform specific. It's hard to know the appropriate Platform and OS fields for such a bug. For instance, I am working on a small change to WebKit/chromium/src/WebKit.cpp. It's not a Mac bug, its not a PC bug, its a Chromium bug. Chromium is a platform of sorts. Chromium bugs could be OS-specific (like Windows, MacOS, etc). So I think the platform field would be the right place to surface such a thing. Should the bug system surface a platform for Chromium? If so- perhaps there are other platforms to surface as well. I'm not sure when a particular flavor of webkit warrants a field in the bug system. If we aren't willing to reflect this through the bug system, what are the right values for these fields? I'm guessing the apple guys want to filter out these bugs - how do you do it today? Thanks, Mike ___ 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] GTK Skiplist
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. Thanks, Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GTK Skiplist
I promise to only put IndexedDB tests in the indexeddb directory. :-) On Fri, Sep 3, 2010 at 5:52 PM, Darin Adler da...@apple.com wrote: On Sep 3, 2010, at 5:50 AM, 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. That doesn’t sound quite right. One of the reasons the tests are grouped into directories is so that things like the Skipped list can take advantage of the categories created. However, we don’t want to disable tests just because someone made an unfortunate choice of what directory to put them in. Lets make sure that doesn’t happen! -- Darin ___ 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 6:15 PM, David Levin le...@chromium.org wrote: It looks like I made a comment (that I don't even remember at this point :) ) which may have triggered this. fwiw, I try to respect how other platforms are maintaining their code because I'd like other people to do the same even if they may think may platform is odd. There is of course a balance to be struck between the freedoms of a port to do things the way it likes with the burden it places on the community. (I say this knowing that Chromium has its equivalent of a Skiplist in a completely different format. But we do this for a very good reason, and I believe work is under way to unify things.) In this case, what is desired is very clearly spelled out in the file: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped#L4 Sure, but as is already clear by Xan and Darin's response, it seems that the situation may not be as clear as the text makes it sound. I don't know why that was added because I didn't do it :). If one disagrees with that comment, it seems like a very reasonable path to take would be to figure out who wrote that (which isn't hard in git or svn) and* take it up with them/the reviewer of that patch to understand if there is some reason for this peculiarity* (and then maybe clarify the comment in some way). The only thing I may have done wrong here is spam a list when a direct email could have done. But even then, the answer would have probably warranted a PSA style email to the list (given that many of us are apparently not on the same page with this policy). And such an email very well could have kicked off a debate of its own. So I felt like it was worth doing this in a broadcast manner. (If it were some nit in a particular part of a code, I would have done it differently.) Btw, I find it humorous that, by your own logic, you probably should have sent your rebuke in a private email. :-) J dave On Fri, Sep 3, 2010 at 9:54 AM, Jeremy Orlow jor...@chromium.org wrote: I promise to only put IndexedDB tests in the indexeddb directory. :-) On Fri, Sep 3, 2010 at 5:52 PM, Darin Adler da...@apple.com wrote: On Sep 3, 2010, at 5:50 AM, 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. That doesn’t sound quite right. One of the reasons the tests are grouped into directories is so that things like the Skipped list can take advantage of the categories created. However, we don’t want to disable tests just because someone made an unfortunate choice of what directory to put them in. Lets make sure that doesn’t happen! -- 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] Arena is crufty?
Isn't ref counting supposed to be _really_ optimized for exactly this use? It seems like a good match--unless you have major issues with cycles...which might be the issue? J On Thu, Sep 2, 2010 at 3:20 AM, Kenneth Russell k...@google.com wrote: I would be happy to not add another Arena client, but the primary reason I need an arena is not just for performance but to avoid having to keep track of all of the objects I need to delete. Is there any consensus yet on how to proceed with https://bugs.webkit.org/show_bug.cgi?id=45059 ? I'm concerned about taking on large-scale restructuring with potential performance impact as a prerequisite for my landing any initial code. I could revert my PODArena class to use its own memory allocation rather than that in Arena.h. -Ken On Wed, Sep 1, 2010 at 7:12 PM, David Hyatt hy...@apple.com wrote: Please let's not add another client of Arena though. That will just make it harder to remove, and I highly doubt you're getting any real performance gain from using it. dave ___ 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] How to specify files to be copied to WebKitBuild/Debug/WebCore.framework/PrivateHeaders/ ?
Is this documented somewhere? It seems like it comes up every now and then and can be quite frustrating. On the other hand, I really don't know where makes sense to document it. :-) Note that this is also what you do when needing to export something form wtf. J On Thu, Sep 2, 2010 at 12:37 PM, Eric Seidel e...@webkit.org wrote: Sorry, Private instead of Project. Public would put it in the public framework headers. WebCore has no public headers only Private headers which are exposed to WebKit. -eric On Thu, Sep 2, 2010 at 4:36 AM, Eric Seidel e...@webkit.org wrote: You need to modify the WebCore target settings to have that header marked as Private intead of public. There are various ways to do that, either via the Targets area of the left side bar, or by getting info on the header in the project file. On Thu, Sep 2, 2010 at 4:29 AM, Yuzo Fujishima y...@google.com wrote: Hi, webkit developers, I locally changed WebCore/platform/graphics/FontFallbackList.h such that it includes SegmentedFontData.h in the same directory [1]. Since then build-webkit complains that SegmentedFontData.h cannot be found [2]. Actually I don't see SegmentedFontData.h in WebKitBuild/.../PrivateHeaders/ directory. How can I specify that SegmentedFontData.h must be copied to the directory? Yuzo [1] diff --git a/WebCore/platform/graphics/FontFallbackList.h b/WebCore/platform/graphics/FontFallbackList.h index a0b94dd..d3409f9 100644 --- a/WebCore/platform/graphics/FontFallbackList.h +++ b/WebCore/platform/graphics/FontFallbackList.h @@ -22,6 +22,7 @@ #define FontFallbackList_h #include FontSelector.h +#include SegmentedFontData.h #include SimpleFontData.h #include wtf/Forward.h ... [2] ... CompileC WebKitSrc/WebKitBuild/WebKit.build/Debug/WebKit.build/Objects-normal/x86_64/WebRenderNode.o mac/WebView/WebRenderNode.mm normal x86_64 objective-c++ com.apple.compilers.gcc.4_2 cd WebKitSrc/WebKit /Developer/usr/bin/gcc-4.2 -x objective-c++ -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fno-exceptions -fno-rtti -fpascal-strings -fasm-blocks -O0 -Werror -Wmissing-prototypes -Wnon-virtual-dtor -Wnewline-eof -DDISABLE_THREAD_CHECK -DENABLE_WEBKIT_UNSET_DYLD_FRAMEWORK_PATH -DENABLE_3D_CANVAS -DENABLE_3D_RENDERING -DENABLE_BLOB -DENABLE_CHANNEL_MESSAGING -DENABLE_CLIENT_BASED_GEOLOCATION -DENABLE_DATABASE -DENABLE_DATALIST -DENABLE_DOM_STORAGE -DENABLE_EVENTSOURCE -DENABLE_FILTERS -DENABLE_FULLSCREEN_API -DENABLE_GEOLOCATION -DENABLE_ICONDATABASE -DENABLE_JAVASCRIPT_DEBUGGER -DENABLE_MATHML -DENABLE_METER_TAG -DENABLE_OFFLINE_WEB_APPLICATIONS -DENABLE_PROGRESS_TAG -DENABLE_RUBY -DENABLE_SANDBOX -DENABLE_SHARED_WORKERS -DENABLE_SVG -DENABLE_SVG_ANIMATION -DENABLE_SVG_AS_IMAGE -DENABLE_SVG_DOM_OBJC_BINDINGS -DENABLE_SVG_FONTS -DENABLE_SVG_FOREIGN_OBJECT -DENABLE_SVG_USE -DENABLE_VIDEO -DENABLE_WEB_SOCKETS -DENABLE_WORKERS -DENABLE_XPATH -DENABLE_XSLT -DFRAMEWORK_NAME=WebKit -DWEBKIT_VERSION_MIN_REQUIRED=WEBKIT_VERSION_LATEST -fobjc-gc -fvisibility-inlines-hidden -fno-threadsafe-statics -mmacosx-version-min=10.6 -gdwarf-2 -IWebKitSrc/WebKitBuild/WebKit.build/Debug/WebKit.build/WebKit.hmap -Wall -Wextra -Wchar-subscripts -Wextra-tokens -Wformat-security -Winit-self -Wmissing-format-attribute -Wmissing-noreturn -Wno-unused-parameter -Wpacked -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -Wcast-align -FWebKitSrc/WebKitBuild/Debug -F/System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks -F/System/Library/Frameworks/ApplicationServices.framework/Frameworks -F/System/Library/Frameworks/Carbon.framework/Frameworks -F/System/Library/Frameworks/Quartz.framework/Frameworks -F/System/Library/PrivateFrameworks -IWebKitSrc/WebKitBuild/Debug/include -IWebKitSrc/WebKitBuild/Debug/WebCore.framework/PrivateHeaders/ForwardingHeaders -IWebKitSrc/WebKitBuild/Debug/WebCore.framework/PrivateHeaders/icu -IWebKitSrc/WebKitBuild/Debug/usr/local/include -IWebKitSrc/WebKitBuild/Debug/DerivedSources/WebKit -IWebKitSrc/WebKitBuild/WebKit.build/Debug/WebKit.build/DerivedSources/x86_64 -IWebKitSrc/WebKitBuild/WebKit.build/Debug/WebKit.build/DerivedSources -include /var/folders/++/++-8Jk++6+0++4RjPqRgNE++GZQ/-Caches-/com.apple.Xcode.19031/SharedPrecompiledHeaders/WebKitPrefix-cejasxonupvwgnfamqhxhbfgzugy/WebKitPrefix.h -c WebKitSrc/WebKit/mac/WebView/WebRenderNode.mm -o WebKitSrc/WebKitBuild/WebKit.build/Debug/WebKit.build/Objects-normal/x86_64/WebRenderNode.o In file included from WebKitSrc/WebKitBuild/Debug/WebCore.framework/PrivateHeaders/Font.h:30, from WebKitSrc/WebKitBuild/Debug/WebCore.framework/PrivateHeaders/RenderStyle.h:47, from WebKitSrc/WebKitBuild/Debug/WebCore.framework/PrivateHeaders/RenderObject.h:36, from
Re: [webkit-dev] Misplaced files
On Mon, Aug 30, 2010 at 5:17 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 9:11 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 30, 2010, at 8:36 AM, Darin Fisher wrote: On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote: Yes. The file-related stuff should all be in one directory, I think. Ok. I moved the files from WebCore/html to WebCore/fileapi. On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? Are these the files you're talking about? WebCore/storage/DOMFilePath.cpp WebCore/storage/DOMFilePath.h WebCore/storage/DOMFileSystem.cpp WebCore/storage/DOMFileSystem.h WebCore/storage/DOMFileSystem.idl WebCore/storage/FileEntry.cpp WebCore/storage/FileEntry.h WebCore/storage/FileEntry.idl WebCore/storage/FileSystemCallback.h WebCore/storage/FileSystemCallback.idl WebCore/storage/FileSystemCallbacks.cpp WebCore/storage/FileSystemCallbacks.h WebCore/storage/LocalFileSystem.cpp WebCore/storage/LocalFileSystem.h I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it. Thanks, Adam How about just moving everything into WebCore/storage? This is all storage-related stuff. I think the File API is large enough to deserve its own directory. In fact, it might be worth splitting up the remaining contents of the storage directory too. It is confusing to have large but almost entirely separate APIs all piled into one directory. It is true they are all storage-related, but that is a pretty broad theme, and LocalStorage, SQL Storage, Indexed DB and File API have little or no interaction with each other. Regards, Maciej That's fair. Plus, there are a lot of files in there already. What names should we use? WebSQLDatabase: Like WebSockets, I think the web part is pretty important to keep people from getting confused. 'websqldatabase' seems a bit long though. 'websqldb' maybe? WebStorage: Currently we call this Dom Storage throughout the codebase (including in the ENABLE macro), so we may want to call it domstorage. Like WebSockets and WebSQLDatabase, I think storage with no prefix seems like a generic storage directory so we should probably call it webstorage if domstorage isn't acceptable. Indexed Database API: IndexedDB is what it's commonly called, so a directory of indexeddb seems like the way to go. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Misplaced files
You're talking about the module part of the IDL? Is that even used by anything or specified anywhere? As far as I can tell, the answer is no. On Tue, Aug 31, 2010 at 4:54 PM, Yaar Schnitman y...@chromium.org wrote: Regarding renaming files: The .cpp and .h file names need to correspond with .idl names, which in turn correspond with the interfaces specified in these .idl. The later are standard, user-facing strings. This means that you can't change them without fixing a lot of generation and build rules. If your goal is reducing complexity, this might not be a good idea. On Tue, Aug 31, 2010 at 3:02 AM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Aug 30, 2010 at 5:17 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 9:11 AM, Maciej Stachowiak m...@apple.comwrote: On Aug 30, 2010, at 8:36 AM, Darin Fisher wrote: On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth aba...@webkit.org wrote: On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote: Yes. The file-related stuff should all be in one directory, I think. Ok. I moved the files from WebCore/html to WebCore/fileapi. On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? Are these the files you're talking about? WebCore/storage/DOMFilePath.cpp WebCore/storage/DOMFilePath.h WebCore/storage/DOMFileSystem.cpp WebCore/storage/DOMFileSystem.h WebCore/storage/DOMFileSystem.idl WebCore/storage/FileEntry.cpp WebCore/storage/FileEntry.h WebCore/storage/FileEntry.idl WebCore/storage/FileSystemCallback.h WebCore/storage/FileSystemCallback.idl WebCore/storage/FileSystemCallbacks.cpp WebCore/storage/FileSystemCallbacks.h WebCore/storage/LocalFileSystem.cpp WebCore/storage/LocalFileSystem.h I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it. Thanks, Adam How about just moving everything into WebCore/storage? This is all storage-related stuff. I think the File API is large enough to deserve its own directory. In fact, it might be worth splitting up the remaining contents of the storage directory too. It is confusing to have large but almost entirely separate APIs all piled into one directory. It is true they are all storage-related, but that is a pretty broad theme, and LocalStorage, SQL Storage, Indexed DB and File API have little or no interaction with each other. Regards, Maciej That's fair. Plus, there are a lot of files in there already. What names should we use? WebSQLDatabase: Like WebSockets, I think the web part is pretty important to keep people from getting confused. 'websqldatabase' seems a bit long though. 'websqldb' maybe? WebStorage: Currently we call this Dom Storage throughout the codebase (including in the ENABLE macro), so we may want to call it domstorage. Like WebSockets and WebSQLDatabase, I think storage with no prefix seems like a generic storage directory so we should probably call it webstorage if domstorage isn't acceptable. Indexed Database API: IndexedDB is what it's commonly called, so a directory of indexeddb seems like the way to go. J ___ 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] Misplaced files
On Tue, Aug 31, 2010 at 5:57 PM, Yaar Schnitman y...@chromium.org wrote: No, the file names. The module part matters when IDLs refer to each other (typedefs and includes) - but these are easy to fix. Can you give an example of what you're talking about? I can't remember seeing anything like this in the past. Also, is there a reason why they're necessary? On Tue, Aug 31, 2010 at 9:00 AM, Jeremy Orlow jor...@chromium.org wrote: You're talking about the module part of the IDL? Is that even used by anything or specified anywhere? As far as I can tell, the answer is no. On Tue, Aug 31, 2010 at 4:54 PM, Yaar Schnitman y...@chromium.orgwrote: Regarding renaming files: The .cpp and .h file names need to correspond with .idl names, which in turn correspond with the interfaces specified in these .idl. The later are standard, user-facing strings. Sure... but the _directories_ are not user facing. That's all we're talking about here. This means that you can't change them without fixing a lot of generation and build rules. If your goal is reducing complexity, this might not be a good idea. On Tue, Aug 31, 2010 at 3:02 AM, Jeremy Orlow jor...@chromium.orgwrote: On Mon, Aug 30, 2010 at 5:17 PM, Darin Fisher da...@chromium.orgwrote: On Mon, Aug 30, 2010 at 9:11 AM, Maciej Stachowiak m...@apple.comwrote: On Aug 30, 2010, at 8:36 AM, Darin Fisher wrote: On Mon, Aug 30, 2010 at 12:18 AM, Adam Barth aba...@webkit.orgwrote: On Fri, Aug 27, 2010 at 8:12 PM, Maciej Stachowiak m...@apple.com wrote: Yes. The file-related stuff should all be in one directory, I think. Ok. I moved the files from WebCore/html to WebCore/fileapi. On Aug 27, 2010, at 6:19 PM, Kinuko Yasuda wrote: We have bunch of FileSystem (which is a part of File API) related files in WebCore/storage/. Maybe we should move them to the new directory too? Are these the files you're talking about? WebCore/storage/DOMFilePath.cpp WebCore/storage/DOMFilePath.h WebCore/storage/DOMFileSystem.cpp WebCore/storage/DOMFileSystem.h WebCore/storage/DOMFileSystem.idl WebCore/storage/FileEntry.cpp WebCore/storage/FileEntry.h WebCore/storage/FileEntry.idl WebCore/storage/FileSystemCallback.h WebCore/storage/FileSystemCallback.idl WebCore/storage/FileSystemCallbacks.cpp WebCore/storage/FileSystemCallbacks.h WebCore/storage/LocalFileSystem.cpp WebCore/storage/LocalFileSystem.h I'm happy to move them to WebCore/fileapi, but I'm also happy for you to do it. Thanks, Adam How about just moving everything into WebCore/storage? This is all storage-related stuff. I think the File API is large enough to deserve its own directory. In fact, it might be worth splitting up the remaining contents of the storage directory too. It is confusing to have large but almost entirely separate APIs all piled into one directory. It is true they are all storage-related, but that is a pretty broad theme, and LocalStorage, SQL Storage, Indexed DB and File API have little or no interaction with each other. Regards, Maciej That's fair. Plus, there are a lot of files in there already. What names should we use? WebSQLDatabase: Like WebSockets, I think the web part is pretty important to keep people from getting confused. 'websqldatabase' seems a bit long though. 'websqldb' maybe? WebStorage: Currently we call this Dom Storage throughout the codebase (including in the ENABLE macro), so we may want to call it domstorage. Like WebSockets and WebSQLDatabase, I think storage with no prefix seems like a generic storage directory so we should probably call it webstorage if domstorage isn't acceptable. Indexed Database API: IndexedDB is what it's commonly called, so a directory of indexeddb seems like the way to go. J ___ 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] Place For new Core Module
On Tue, Aug 24, 2010 at 11:50 PM, Chinmaya Sn chinm...@gmail.com wrote: Thanks All. I think I am getting the general idea of what can get into to WebKit and how things fit. Right now both the standard and implementation are WIP, spec is intended to be a Web standard. At this point, neither the standard nor the implementation are public. Even if you want to use your prototype implementation to inform your spec's design, I'd highly recommend bringing up your general ideas on some standards list ASAP. These lists often have a lot of smart people with a lot of varied experience. Often they'll be able to point out major flaws in your idea or other technologies you might want to look at. And, at very least, it'll give you an idea of how your final spec will be received. I'd highly suggest at least floating the general concepts around some standards lists otherwise there's a good chance your proposal will be dead on arrival. On Tue, Aug 24, 2010 at 11:59 PM, Eric Seidel e...@webkit.org wrote: Secret ports have an absolutely horrible track record of ever catching up with public WebKit. Only one has ever been successful to my knowledge (Chromium) and I'm not even sure we could call it full success yet. (They've spent 2 years attempting to fully catch up, and yet you can't build a useable binary out of webkit.org -- although that's very close!) Apple's iPhone fork has (or had, maybe this has changed) one full-time person who's job is constantly merging. I'm not sure how close to tip-of-tree they're able to stay. It's possible that you work with the most fantastic engineers WebKit will ever see. But let me caution you: if CableKit forks in secret, you're very likely to always be months if not years behind and riddled with security vulnerabilities. :) Furthermore, specs take a long time and a lot of buy-in. Spec-work done in secret is unlikely to end up ever getting the buy-in it needs to become a spec. Best of luck. +1 J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Not enough space message when linking webkit (lots of free disk space)
The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address space for itself + you can get fragmentation. So the linker only can use part of the 4gb of ram in your machine. So switching to a 64 bit linker would probably fix the problem for now. Another option is to disable some parts of WebKit you don't need (like SVG). J On Mon, Aug 23, 2010 at 3:26 AM, Chris Hatko cha...@gmail.com wrote: Hi Nico, Yes, I've got 32 bit MSVS2005. I found that turning off /LTCG and /GL optimization allowed me to get past this error. Do we now need more than 4Gigs of RAM to compile webkit with release optimizations? Chris On Sun, Aug 22, 2010 at 4:09 PM, Nico Weber tha...@chromium.org wrote: Are you using a 32 bit linker? Maybe it's running out of address space. Nico On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko cha...@gmail.com wrote: I'm running revision 65648 and building cairo-win32 release I'm getting Not enough space when linking WebKit project. I have 40Gig free space on this drive and 4Gigs of ram. Linking... 11fatal error C1083: Cannot open compiler intermediate file: 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not enough space 11LINK : fatal error LNK1257: code generation failed 11Build log was saved at file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm 11WebKit - 1 error(s), 1 warning(s). Any idea what I can try? Thanks, Chris ___ 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] Getting rid of WebCore.xcodeproj developmentRegion diff
In that case, can we please standardize on the Xcode 3 behavior and ask those using the beta to keep it out manually? J On Tue, Aug 17, 2010 at 7:41 PM, Jeff Johnson opendar...@lapcatsoftware.com wrote: Actually, this is caused by Xcode 4 (still in beta). See rdar://problem/8295614 Xcode 4 fights with Xcode 3 over developmentRegion -Jeff On Aug 17, 2010, at 1:28 PM, Darin Adler wrote: It’s the Xcode team’s fault, caused by people using different versions of Xcode. Short term, I don’t know any way to make it go away. Long term it will disappear once all contributors are using Xcode 3.2.3 or newer. -- 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] Tests that separate JS and HTML
On Fri, Aug 13, 2010 at 11:17 AM, Alexey Proskuryakov a...@webkit.org wrote: On multiple occasions, I've been noticing that separating JavaScript for tests into its own file has been causing me pain. There are several disadvantages that I know of: 1. One doesn't see test content when a tool (such as run-webkit-tests) sends them to a failing test. If I want to see it in browser, I need to copy/paste script src, or manually edit the address in address bar. 2. The proliferation of script-tests prompts some contributors to unnecessarily complicate their tests to fit the format. Sometimes, the DOM that could just be in the HTML content is dynamically created. Other times, complicated schemes for async tests are used, instead of directly calling notifyDone(). 3. These tests cannot be attached to Bugzilla bugs in a working form (e.g. if one wants to file a bug against another browser). 4. The test does not live next to its expected results, so one has to keep two folders open when working on the test. On the other hand, I can't think of any clear advantages. Some potential advantages could be: 1. Ease of boilerplate modification. I don't see why we would want to modify boilerplate in existing tests - it's more likely that such changes would break them than improve them. 2. Ease of test writing. Maybe people who use script tests often would object, but for me, a step that I must do any time I start working on a test - at a very specific moment - is a problem. Usually, I start with a simple test that I keep on desktop (or in Bugzilla), and only move it to LayoutTests later. 3. Higher quality of boilerplate. The boilerplate is quite straightforward, all the logic is in external files. 4. Tests become more concise. This is true, but I don't think it has practical benefits - it's quite easy to focus on test code even if everything is in one file. Of course, there is the special case of fast/js tests, which we (I think) still hope to run without a WebView one day. For that, keeping JS separate is obviously desirable. We have lots of imported tests in WebKit regression test suite, as well as tests employing various custom runners developed by WebKit contributors. So to a degree, the manner in which a test is written will always remain a matter of personal preference, we can't and shouldn't standardize this. However, as I was personally seeing more script-tests not just being added, but living their active lives, I started feeling frustration towards them. When reviewing patches, I recommend against using tests that have their main logic in files other than the main HTML. I don't feel nearly as strongly as Alexey, but I think he makes some good arguments. The main advantage of the script tests style tests is the common code (the function shouldBe for example), but there's no reason we can't still include fast/js/resources/js-test-pre.js (or other files) in self-contained tests. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Build system complexity
Are there currently any plans for simplifying the situation regarding build systems? I haven't seen any threads for a while, which I assume means no. Is there any low hanging fruit out there? Since many of the build systems are little more than lists of files, it really seems like we should be able to do some sort of consolidation. Or reduce the process down to updating one file and then running a script that updates/generates the rest. Currently, I cringe every time I find out I need to add a new file. In addition, has anyone ever looked at simplifying the mac port's xcode project? It's _by far_ the heaviest burden on the project given that you pretty much need to use xcode (which is mac only...no other port requires this), exported linker symbols are in a separate file, extra effort to expose a new file in WTF to WebCore, extra effort to expose a new file in WebCore to WebKit, etc. Has anyone recently looked at how the mac build could be simplified--especially from the perspective of contributors whose main development platform isn't a mac? Thanks! Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer ddkil...@webkit.org wrote: On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote: i completely agree with jeremy. is it possible to at least drop the cryptic hashcodes/timestamps? without them, the .xcodeproj files should at least be editable by hand. Doesn't gyp already generate Xcode projects for Chrome? I think the issue is that gyp can't generate replacement project files for Apple's Mac port or other build systems yet. That was my take-away from the last discussion--that gyp needed to be enhanced so that all build systems could be generated, making addition or removal of source files a trivial task. Chrome has been using GYP for some time and it's pretty stable. I suspect that anyone trying to port the Mac port's xcode project to it will run into some bugs and/or need to build some additional features into it, but it is quite stable. And the GYP guys are very friendly people though, so I bet they'd be happy to help with any such problems. It's also worth noting that GYP was designed from the start to allow a project to move over to it slowly (you can have custom projects depend on GYP projects and vice versa). But moving to GYP is definitely not the only way to solve this issue--and quite possibly not the best way. I suspect that there are also many smaller steps that could be taken that'd have a big impact. For example, coming up with ways to generate sane/informative error messages for when someone doesn't export some symbol/header file properly would awesome and doesn't require changing the entire build system. Or creating some script that can add files to the xcode project. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build system complexity
Let me re-iterate (because even some co-workers are getting confused): I'm not secretly trying to get the mac port to start using GYP. (Or saying it's a bad idea either, mind you.) I'm just concerned that the process associated with adding a file (or adding a dependency between projects on the mac port) is out of hand--and has been for some time. And I'm hoping we can come to some sort of conclusion that'll start the project moving in the right direction--even if it's slowly. That's it. I promise! J On Thu, Aug 12, 2010 at 3:37 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer ddkil...@webkit.org wrote: On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote: i completely agree with jeremy. is it possible to at least drop the cryptic hashcodes/timestamps? without them, the .xcodeproj files should at least be editable by hand. Doesn't gyp already generate Xcode projects for Chrome? I think the issue is that gyp can't generate replacement project files for Apple's Mac port or other build systems yet. That was my take-away from the last discussion--that gyp needed to be enhanced so that all build systems could be generated, making addition or removal of source files a trivial task. Chrome has been using GYP for some time and it's pretty stable. I suspect that anyone trying to port the Mac port's xcode project to it will run into some bugs and/or need to build some additional features into it, but it is quite stable. And the GYP guys are very friendly people though, so I bet they'd be happy to help with any such problems. It's also worth noting that GYP was designed from the start to allow a project to move over to it slowly (you can have custom projects depend on GYP projects and vice versa). But moving to GYP is definitely not the only way to solve this issue--and quite possibly not the best way. I suspect that there are also many smaller steps that could be taken that'd have a big impact. For example, coming up with ways to generate sane/informative error messages for when someone doesn't export some symbol/header file properly would awesome and doesn't require changing the entire build system. Or creating some script that can add files to the xcode project. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 tree builder enabled
Impressive! Thanks Eric+Adam for all the work on this! You guys are quite a team. J On Thu, Aug 5, 2010 at 9:10 AM, Adam Barth aba...@webkit.org wrote: The HTML5 tree builder is enabled as of http://trac.webkit.org/changeset/64712. Check out our awesome SVG-in-HTML demo (in a post r64712 build, of course): http://trac.webkit.org/export/LATEST/trunk/LayoutTests/svg/in-html/circle.html In light of the other thread about wanting more blog posts, I'm working on a blog post about this change that I hope to post some time later today. If we've horribly broken everything, please file a bug and CC me and Eric. Thanks again, 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] Some new coding style rules
On Wed, Aug 4, 2010 at 9:29 AM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Good morning WebKit crowd,
I'd like to discuss some style issues, that I'm frequently unsure about:
1. namespace closing brace
It was discussed in
http://article.gmane.org/gmane.os.opendarwin.webkit.devel/10563, but with
no real result.
When writing headers, do we need the // namespace Foo comment after the
namespace closing brace? I think it's visual noise and would like to see a
style rule that forbids it.
(A rule that says we need this would also be fine with me, as long as we
write it down. But I'd vote for removing those comments, I don't trust them
anyways, if I'm unsure.)
namespace WebCore {
...
} // namespace WebCore
2. ENABLE(FOO) #endif comments
#if ENABLE(FOO)
..
#endif // ENABLE(FOO)
Shall we remove the comment, or require it explicitely in the style rules?
3. Inclusion order
Say Foo.h is guarded with ENABLE(FOO) macros
Foo.h:
#if ENABLE(FOO)
namespace WebCore {
class Foo...
}
#endif
What's the correct inclusion order in Foo.cpp:
#include config.h
#include Foo.h
#if ENABLE(FOO)
..
#endif
or
#include config.h
#include Foo.h
#if ENABLE(FOO)
..
#endif
I don't see the difference between these two examples.
I'm not sure if this is what you were asking, but here's another: Should we
do this:
#include config.h
#include Foo.h
#if ENABLE(FOO)
#include other
#include includes
...
#endif
or this
#include config.h
#include Foo.h
#include other
#include includes
#if ENABLE(FOO)
...
#endif
or this
#include config.h
#if ENABLE(FOO)
#include Foo.h
#include other
#include includes
...
#endif
The last one is definitely required in custom JS* or V8* files since the
Foo.h file will only exist if the guard is enabled. But besides this one
case where we have to, I feel splitting the #include config from the main
header file adds unnecessary noise and is ugly. So, for the common case,
I'd like to suggest we go with my first example since it doesn't include a
bunch of unnecessary files, but it keeps our standard convention even in
(the many) files that are entirely encapsulated in an ENABLE block.
I'd agree that it'd be nice to get some of this stuff nailed down so
we're consistent.
(I think the former, as it makes no sense to process the header, if I
already know it's enclosed in ENABLE(FOO) blocks)
I'd be happy if we could agree on rules and write them down.
Cheers,
Niko
___
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] Rendering a PDF on an HTML5 Canvas using WebKit/AIR
This is not the right mailing list for such questions. Please see http://webkit.org/contact.html On Tue, Aug 3, 2010 at 4:26 AM, Andrew Sealy-Bell andyamsterdam2...@gmail.com wrote: Hi, I'd like to know if anybody has experience with rendering a PDF on an HTML5 canvas? I'd like to to this and listen for mouse events etc. do overlay some customised functionality on top. I'd like to be able to do this both on a desktop AIR app and on the browser if possible. Any help or advice would be much appreciated. Regards, Andrew. ___ 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] Sharing WebKit mocks across platforms
Why wasn't it done that way originally? That sounds (to my uneducated ear) much better than what's done today. J On Thu, Jul 29, 2010 at 11:19 PM, Adam Barth aba...@webkit.org wrote: WebCore::LayoutTestController would be exposed to JavaScript running in LayoutTests directly (like the DOM), so we can skip the type conversions. Adam On Thu, Jul 29, 2010 at 9:20 AM, Satish Sampath sat...@google.com wrote: With a WebCore::LayoutTestController, would there be a need for code in WebKit to convert the call parameters from WebKit types (which DRT uses) to WebCore types (which the mocks may use) ? If yes seems like we need wrappers to proxy the mock calls anyway on different platforms.. Cheers Satish On Thu, Jul 29, 2010 at 4:16 PM, Adam Barth aba...@webkit.org wrote: Thanks for bring this question to the list. I don't have a strong opinion here, but I want to make sure we think project-wide and pick something scalable. This discussion is also related to the discussion about adding something like a layoutTestController object to WebCore. Plumbing this mock API all the way through WebKit for each port seems like a waste. If we had something like a WebCore::LayoutTestController, it would make a lot more sense to expose that functionality there. Adam On Wed, Jul 28, 2010 at 11:30 AM, Steve Block stevebl...@google.com wrote: I'm in the process of adding a mock client for DeviceOrientation, which will be used in DumpRenderTree to test the feature. In order to share the mock across platforms, I'd like to add the mock to WebCore/platform/mock. An interface to the mock will have to be exposed to the embedder through the platform's WebKit API, so that it can be configured by DRT, eg ... mWebView.getDeviceOrientationClientMock().setOrientation(...); To avoid each platform having to produce it's own WebKit wrapper for the mock, I'm considering adding a common WebKit wrapper, perhaps to WebKit/common, and I wanted to get some feedback on the idea. The mock would be shared between all C++ WebKit platforms. (Note that this is for convenience only, a platform could equally use it's own WebKit wrapper around the WebCore mock (eg Mac may do so in ObjectiveC), or use its own mock altogether.) Of course we also need WebKit wrappers for all of the non-POD types used by the mock's interface, and these have to be common between all platforms. One obvious potential difficulty is the wrapper for WebCore::String. Each platforms already has a wrapper for this type, but there's no guarantee of interoperability, so we'd need to write a new common interface if we're to use the string type. If a wrapper for string ends up being too problematic, the approach could still be used for mocks that don't need the string type (of which DeviceOrientation is one), but the approach then seems less compelling. Do people think that this is a reasonable proposal and worth pursuing? Has there been any attempt to do anything similar before? Or is any attempt to write this kind of common WebKit code not worth the effort and destined to failure? You can see the work in progress for DeviceOrientation at https://bugs.webkit.org/show_bug.cgi?id=39589 and a similar patch for SpeechInput mocks at https://bugs.webkit.org/show_bug.cgi?id=42603 I'd appreciate any feedback you may have. Thanks, Steve -- Google UK Limited Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ Registered in England Number: 3977902 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Remove me from your mailing list..
Seriously? It's the first result: http://www.lmgtfy.com/?q=webkit-dev Clearly you overly value your own time if you couldn't even do a quick search on how to properly unsubscribe and instead spammed an entire mailing list. J On Mon, Jul 12, 2010 at 11:23 AM, Johnson, Christopher christopher.john...@saic.com wrote: *Please remove me from your mailing list.* * * *Thanks…* * * *V/R,* * * *Christopher Johnson* | *SAIC* Electronic Technician 1 | Defense Solutions Group Office: 843-218-3064 | Fax 843-218-7727 Cell: 843-532-4285 | *NIPR:* *christopher.john...@saic.com* *Science Applications International Corporation* 1545 Truxton Ave. Charleston, SC 29405 *www.saic.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] Frustrated at inconsiderate behavior
On Fri, Jul 9, 2010 at 2:14 AM, Xan Lopez x...@gnome.org wrote: 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. 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. 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. 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
I agree with Maciej's response, but at the same time I can understand why Adam was so frustrated. He (and others) have pointed out stuff like this on and off list over and over again with little apparent change... But that's not what I'm most worried about; why this was broken in the tree for 12 hours?? It seems like, at the very least, every single person who committed in that time frame should have taken a look at the tree after committing [1]. Why did not one of those people roll the patch out when it was clear that there were failures and Alexey wasn't in the process of fixing them? J [1] Yeah, in theory looking before hand and not landing while it's on fire is better, but I'm talking about the _bare minimum_ of what should have happened. On Thu, Jul 8, 2010 at 12:18 AM, Adam Barth aba...@webkit.org wrote: Sorry for singling you out Alexey. I was just frustrated last night. On Wed, Jul 7, 2010 at 8:58 AM, Alexey Proskuryakov a...@webkit.org wrote: 07.07.2010, в 00:47, Adam Barth написал(а): If you're tired of my complaining about the tree being red, you can skip this message. I understand that you're frustrated, but I think that you're misinterpreting what happened. 1) He could have run-webkit-tests before committing his change. I did that. I made the mistake of running a wrong subset though (forgot that local xmlhttprequest tests were no longer in fast/dom). Maybe the root cause here is that the test suite takes too long to run? We can make run-webkit-tests faster... 2) If he didn't have time to run the tests locally, he could have used the commit-queue to run-webkit-tests before it landed his patch. Using commit-queue while it still doesn't provide correct svn blame is trading short term problems for longer term ones. Yes, one can still open a changeset by number, but having names really helps read svn blame. This problem is now fixed thanks to William Siegrist. Patches written by committers show up correctly in SVN blame and trac even if they're landed by the commit-queue. 3) He could have looked at the tree when sheriff-bot informed him that he might have broken Leopard Intel Debug by pinging him in #webkit and commenting on his bug: https://bugs.webkit.org/show_bug.cgi?id=41156#c8. I worked with Qt guys on fixing tests on Qt, and I watched the tree, which didn't show any sign of a problem from my patch at the time. Perhaps I'm starting to rely on sheriff bot too much - it didn't complain about any platforms besides Leopard Intel Debug. It only complains once to avoid spamming when it makes a mistake. Leopard builder was seriously broken yesterday, so I didn't pay attention when it complained about a problem many hours later. In retrospect, that was a mistake. I think we can improve this by having sheriff-bot say which tests broke. I bet if you saw these tests listed, you'd have realized what was going one. these failures remained in the tree until I cleaned them up I see that Tiger bot still has a unique failure, and will investigate it as soon as possible. Thanks. 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 2:03 AM, Alexey Proskuryakov a...@webkit.org wrote: 07.07.2010, в 9:49, Jeremy Orlow написал(а): Why did not one of those people roll the patch out when it was clear that there were failures and Alexey wasn't in the process of fixing them? Just to avoid any misunderstanding, the best thing to do would have been to tell me about the problem on IRC. I wasn't around at midnight, when Adam noticed the problem, but I was on IRC for many hours after landing that patch. Surewell, why did neither happen? Can any committers who saw the redness but didn't work to resolve the problem comment on how the process broke down? J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Frustrated at inconsiderate behavior
On Thu, Jul 8, 2010 at 10:19 AM, Oliver Hunt oli...@apple.com wrote: On Jul 7, 2010, at 7:16 PM, Tony Gentilcore wrote: On Wed, Jul 7, 2010 at 6:50 PM, Mo, Zhenyao zhen...@gmail.com wrote: Maybe I should complain this in a different threads, but recently the commit bot waiting time is way too long. Several times a patch of mine got the r+ and cq+ and it landed two days later. This is really frustrating. I am very tempted to use svn directly to commit patches, but that means the patch only gets tested in my local environments. Like one time my patch breaks the leopard bot, turns out the failed test is skipped on leopard, which is exactly my OS. If I land it through the commit bots, I could identify the issue earlier. I agree they are closely related. A greener tree means a faster commit queue and a faster commit queue means less people subvert it and break the tree. The hard problem is figuring out how to fix the incentives so subverting the queue isn't so desirable. What do you mean by subvert the queue? The commit queue is a tool to streamline commits from contributors who do not have commit access to the repository. If you have the ability to commit you should not be using the commit queue to land your patches. That is the opinion of a few contributors, yes. But even when there were some big downsides to committers using the commit queue, there was definitely no definitive direction to not use the queue. And now that pretty much all the problems with the queue have been systematically eliminated, I would argue that--if anything--we should actually ask everyone to use the queue when practical. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
That would be the standard thing to do. The sooner someone gets started on the feature, the easier it'll be to revert the patch that removes the code. :-) J On Thu, Jul 8, 2010 at 10:55 AM, David Levin le...@chromium.org wrote: On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.org wrote: I'd lean to the removal, unless there is a port that has work ongoing or planned soon for those implementations. Does anybody vote for #ifdefs? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) *Even if someone to implement them for chromium, it doesn't seem to fix the overall problem. *Dmitry indicated that the presences of these is breaking feature detection in browsers using WebKit (-- which is something being heard from web developers). A simple solution is to remove them. Later, any port (including chromium) who gets someone to work on them could re-add these methods back properly under ifdef's. dave ___ 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] strategy for evaluating performance issues related to memory.
On Mon, Jun 21, 2010 at 2:21 PM, Mike Marchywka marchy...@hotmail.comwrote: So where does this stand right now? I hope to actually contribute at some point. but right now I'm just trying to determine approaches to even finding the problems. ( and yes my disk light still comes on for minutes at a time locking me out of doing antyhing with iceweasel or firefox) Yes, you've mentioned your disk light blinking several times now. If you have specific bugs to file against specific projects, I suggest you do that. Repeatedly posting about it on webkit-dev (until now, in unrelated threads) doesn't seem particularly useful. I guess at a gross level it would be nice to know when and why page faults occur but a more pro-active approach would be to start understanding the memory needs during design or code examination for other reasons. If there is nothing better, perhaps people could put in formatted comments about memory needs and access patterns and various parameters or issues or assumptions that in the code. I haven't entirely thought this through (duh) and hope to stimulate a discussion ( actually I'd be happy if someone had a one line answer or link to an answer but am not that opitmistic). I would approach this as an addition to finding memory leaks but maybe the worst offenders will go away if there is less clutter. This is all fairly hand-wavy. If you have specific problems you've seen, please file bugs. If you want to spend some time investigating these issues, great. But I don't understand why you keep bringing this up. Especially since, as far as I can tell, it only involves situations where WebKit memory is spilling to virtual memory which, AFAIK, is not something anyone has spent time optimizing. Unless you're actively working on this problem within WebKit, these emails seem out of scope for webkit-dev. Thanks. - - - - - - Mike Marchywka | V.P. Technology 415-264-8477 marchy...@phluant.com Online Advertising and Analytics for Mobile http://www.phluant.com note new address Mike Marchywka 1975 Village Round Marietta GA 30064 415-264-8477 (w)- use this 404-788-1216 (C)- leave message 989-348-4796 (P)- emergency only marchy...@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 ___ 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] strategy for evaluating performance issues related to memory.
On Mon, Jun 21, 2010 at 7:08 PM, Mike Marchywka marchy...@hotmail.comwrote: Unless you're actively working on this problem within WebKit, these emails seem out of scope for webkit-dev. The topic addresses this doesn't it? I would think that outlining a development strategy would be actively working. I don't expect to dig into the code right now beyond what I have already done but if I could figure out what to do I might be able to make more specific contributions later. If you're not contributing code and you don't have people interested in following your lead, then no I don't think this is the applicable list. I'm not aware of any WebKit contributor that's twiddling their thumbs trying to find something to work on. Maybe this topic will rise to the top of a contributors priority queue at some point, in which case I could see a discussion being on topic and useful. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Style question: static, protected, or public members
On Sun, Jun 13, 2010 at 12:46 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 4, 2010, at 3:54 PM, Joe Mason wrote: I'm strongly in favour of g_. It seems weird and ugly to me to have prefixes for some non-local scopes but not all. And it's very helpful to be able to look at a variable reference and immediately know that it's a global, and not a local whose definition you skimmed over. I think file-scope static globals don't need a prefix. In the few cases of globals with extern linkage, I think a prefix would make them needlessly unpleasant to use. HTMLNames.h is one of the most prominent examples. I don't think we'd want to write g_divTag and g_widthAttr instead of divTag and widthAttr. For what it's worth, I think having a special prefix has benefits beyond conflicts when linking. I agree 100% with what Joe said. (That said: if there isn't a lot of support for this, I don't think anything should change...but I figured I'd throw it out there in case others agreed.) J ___ 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 ??
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. J On Sat, Jun 5, 2010 at 8:34 PM, Saravanan Shanmugham sarvil...@gmail.comwrote: Hi webkit gurus, I am using Pyjamas Desktop which uses webkit and requires a patch to webkit. The patch has been published to the open source i believe. https://bugs.webkit.org/show_bug.cgi?id=16401 Will this patch get into webkit? What are your plans/status regarding this patch to webkit. I am on a MAC and trying to install pyjamas-webkit and having trouble getting this to work since i have to use a custom patched webkit. I notice that this bug has been duplicated another bug is marked as resolved. Not sure I understand the state of this patch. Thanks, Sarvi ___ 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] sick of forgetting bugzilla email addresses?
This will save me so many iterations of trying a name into gmail and then copying it over to bugzilla. :-) Thanks Ojan! On Mon, Jun 7, 2010 at 9:28 PM, Adam Barth aba...@webkit.org wrote: Wow, that's pretty awesome. Thanks Ojan. Adam On Mon, Jun 7, 2010 at 1:25 PM, Ojan Vafai o...@chromium.org wrote: I sure am. I wrote a Chrome extension that adds autocomplete to bugzilla email input boxes based off the data in http://svn.webkit.org/repository/webkit/trunk/WebKitTools/Scripts/webkitpy/common/config/committers.py . It will autocomplete based on first name, last name, irc nick or email address. https://chrome.google.com/extensions/detail/olaabhcgdogcbcoiolomlcodkngnemfb Please let me know if I missed any email input boxes. The only ones I saw were on the advanced search page and the individual bug page. If anyone would like to integrate this directly into bugzilla, it's ~250 lines of JS to do the autocomplete, which you're welcome to use or modify. You'll just need to write code to generate the list of email addresses. You can't just use my JS code for that if you want to use committers.py since it's on a different domain. Ojan ___ 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] How to handle a new protocol for Blob.url support?
On Thu, Jun 3, 2010 at 2:08 AM, Darin Adler da...@apple.com wrote: On Jun 1, 2010, at 5:14 PM, Jian Li wrote: I am working on Blob.url support as defined in the latest version of File API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a URL that can be used to refer to the blob object in a resource request, like blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent a whole file, a partial file (created by Blob.slice), or a byte array (created by BlobBuilder defined in the FileWriter spec). What is the right place I can hook up with in order to interpret and process the blobdata request? Should it be in the WebKit library layer that will be implemented by individual platform or in the higher layer like what application cache does the work? Definitely a higher level. We don’t want to have to reimplement a feature like this for each platform. Bonus points if whatever you come up with for Chromium shares as much code as possible with WebKit2. -- 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] Need more diagnostic information for ApplicationCache events
If you want to change the web platform (which adding information to events is), sending an email to WhatWG [1] is probably the right first step. The other option is to think about how to extend the existing developer tools to aid in debugging. Personally, that makes more sense to me, and I believe there are people from both Apple and Google working on this. J [1] http://www.whatwg.org/mailing-list On Wed, May 19, 2010 at 4:52 PM, Patrick Mueller pmue...@muellerware.orgwrote: After some frustrating experiences using AppicationCache for some private, but field-tested apps, I'd like to see some additional information provided in the ApplicationCache events. I posted down some thoughts here: http://bit.ly/9Bfjeh [whatwg ml] Seems like these would be a good candidate for an experimental feature. Did anything ever happen regarding formalizing or just organizing thoughts around experimental features, after the Contributor's Meeting last month? -- Patrick Mueller - http://muellerware.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] What is the webkit-patch version of svn-unapply?
On Wed, May 19, 2010 at 7:15 PM, Adam Barth aba...@webkit.org wrote: On Wed, May 19, 2010 at 11:06 AM, Darin Adler da...@apple.com wrote: On May 19, 2010, at 10:56 AM, Adam Barth wrote: On Wed, May 19, 2010 at 10:41 AM, Darin Adler da...@apple.com wrote: Lets say I just did webkit-patch upload and I am Subversion user and I now want the patch out of my tree. Does webkit-patch have a command to help me do it? I can’t just use svn revert because that doesn’t handle things like added, removed, and moved files. I've had a similar problem when using SVN. On git, I use the command git reset --hard. Currently, you can use the following command: webkit-patch update --force-clean That runs both the update and the clean steps: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/tool/commands/download.py#L46 We could expose a command that runs just the clean step: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/tool/steps/cleanworkingdirectory.py These aren’t great replacements for svn-unapply for me. All I want to do is remove a particular patch from my tree; updating and reverting everything is both slower and may have unwanted side effects, such as removing changes I made after uploading the patch. I can see how someone would no longer need svn-unapply once they had switched to git. Personally, I don't have multiple patches in my tree at the same time, so I don't understand what would be the most convenient for you. Removing the update step is easy, but I'm not sure how you would like to specify the changes to remove from the tree. We could add an unapply-from-attachment command, but that would involve fetching the patch from bugs.webkit.org again... Another option is that the upload command could store a copy of the patch locally that you could then use with svn-apply and svn-unapply directly. What if we added an option to webkit-patch upload that unapplies the patch at the end? In fact, for the first iteration, it could simply save the patch in some temporary location and then run 'svn-unapply'. In other words, do what you just described but without the second webkit-patch run. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Local Storage (SQL Database) not working in my app built with XCode
See the enable functions in WebCore/page/Settings.h. On Fri, May 14, 2010 at 2:48 PM, Adam Thorsen adam.thor...@gmail.comwrote: I've got a minimal browser app that is linked against the WebKit framework that I'm building with XCode. I'm developing a website that uses some HTML5 local storage features, including the ability to create a local SQL database. This site works properly in in Safari and Chrome, but I can't create the database in my WebKit based app (I just get a null return value when I call openDatabase(shortName, version, displayName, maxSize). What do I need to do to be able to build an app that can create a local SQL database? I've posted on cocoa-dev and webkit-help already a few days ago, so this post is a last resort. Apologies if this is too off-topic. Thanks, -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] Ancient patches in pending-review
On Thu, May 13, 2010 at 5:41 PM, David Levin le...@google.com wrote: On Thu, May 13, 2010 at 9:12 AM, Adam Barth aba...@webkit.org wrote: One of the least fun things in the project is to pour a bunch of effort into writing a patch only to see it sit forever waiting for review. In the past, I've tried to single-handedly tackle the patches that have been up for review for more than a month. That approach is less than ideal because (1) it's too big a task for one person and (2) it causes me to review outside my area. As we've been discussing on #webkit recently, we'd like for reviewers to focus their reviews on their area of expertise to make sure each patch gets a high-quality review before landing. I've triaged the oldest patches in http://webkit.org/pending-review into groups and assigned an owner (see below). You don't need to review the patches in a group just because I've assigned it to you, but if you don't review them, please find someone to look at them. If a patch is unassigned, please consider whether you feel confident reviewing patches in that area. If you're an expert in an area by not necessarily a reviewer yet, please consider giving one or more of these patches an informal review. An informal review is especially useful if it points out areas of a patch that the contributor can improve. Ideally, an informal review would cause the contributor to improve their patch before it receives a formal review. (If you're not a reviewer, please don't alter the Review flag; just leave a comment.) Our biggest problem spots appear to be Editing and WINCE. Below, I've asked Enrica to provide informal reviews of the editing patches and Ojan to provide the formal reviews. Dave, I think you missed this bit :-) I've also asked jamesr to provide informal reviews for the CSS and Rendering patches because he's expressed interest in learning Hyatt's secret tricks. As for WINCE, are there any reviewers interested in reviewing patches for that port? Adam Editing (Enrica, Ojan) Unfortunately, Enrica is not a reviewer yet and can't be (56 patches) but was been willing to look at a patch when I asked. It may be a good opportunity to do some reviews as if they were real before being nominated to be a reviewer (which I find very to be nice to submit with a reviewer nomination). Definitely agree! * 24943: Command-B and Command-I do not generate keydown events in contentEditable regions. * 35632: htmlediting.cpp : isEmptyTableCell() is incomplete * 32605: Regression: Selection anchor + focus swap when arrow keys after setBaseAndExtent * 32077: textarea grows when you type * 36359: Double clicking page's last editable inline element doesn't select a word. * 32123: cursor movement and text selection does not work well if a block is followed by an inline * 35791: 2x execCommand rea...@null * 35530: Enum value FORWARD, BACKWARD, RIGHT, LEFT are causing macro conflicts. WINCE (???) - Do we have any WINCE reviewers? * 34953: Implement DEFINE_STUB_FUNCTION for WinCE * 33004: NetworkStateNotifierWin.cpp doesn't work always * 32169: Implement TextCodec for WINCE port * 37287: Rename Wince file to WinCE * 32963: buildfix for ResourceHandleWin.cpp * 37440: [WINCE] Port tiled backing store * 28272: WINCE PORT: graphics files only for WINCE DOM (Depends on area...) * 34945: Improve form validation messages. * 31718: Framework to show form validation message for invalid controls * 37012: dropEffect not set to correct default values in dragenter / dragover I think JianLi has been doing work in drag/drop. * 37117: Add platform-independent JPEG/PNG image encoders and toDataURL * 22261: Clicking button input does not give it focus CSS (dhyatt, dethbakin, jamesr) * 32412: css2:order of counters in out-of flow content * 32309: noAccess url schemes block access to inline stylesheets * 13097: Unsupported content:inherit value * 37443: CSSStyleSelector should pass through origin information when determined if link visited Rendering (dhyatt, jamesr) * 15994: REGRESSION: Incomplete repaint of CSS image substitution * 23556: On RTL pages, horizontal scrollbar is missing JavaScriptCore (gbarra, ggaren, olliej) * 36050: Add the possibility for a head and footer section to create_jit_stubs * 36500: Generated JIT stubs does not compile because of compiler directives Websocket (dave_levin?) * 35573: WebSocket add new event: CloseEvent I think ap is much more familiar with WebSockets -- though I am willing to look if needed. Qt (tronical) * 36171: QtWebKit doesn't support NPAPI for DirectFB Gtk (xan) * 37369: [GTK] Enable building whatever already exists of WebKit2 Plugins (???) * 36721: Use Chromium's plugins/get-url-with-blank-target.html for all platforms Inspector (xenon, yurys) * 18530: Inspector's Console should distinguish console.info from console.log
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On Tue, May 11, 2010 at 10:11 PM, Geoffrey Garen gga...@apple.com wrote: We require a ChangeLog for every patch. Isn't that a TPS report? No. A ChangeLog is much less time-consuming to manage. For me, letting webkit-patch make the bug for me and post updates to the bug is maybe 10-15 seconds longer than doing the entire process manually _without_ creating a bugzilla bug. That's far less time than I put into change logs. Another perspective is that we have lots of tools to help you not break the build. If you bypass those tools and break the build, you're going to piss people off. We've discussed having a rigid green tree policy in the past. This line of discussion seems to say, We know the project decided against a rigid green tree policy, but we'd like to have one anyway. What exactly is a rigid green tree policy? I know that WebKit has the policy to roll out patches that cause redness after 15ish mins if the author can't be contacted (or if the author can't quickly fix the problem). I consider that fairly rigid (in a good way), so I guess your use of rigid is referring to the level of testing before committing a patch? I took a look at http://webkit.org/coding/contributing.html and it only lists compiling and testing as recommended steps. Maybe we (as a project) should better document our expectations regarding compiling/testing patches. Here's some proposed text: When possible, committers should test their patches at least by compiling and running all the layout tests on them. When your patch touches port-specific code, you should ideally do the same on those platforms as well. The WebKit a href=...Early Warning System (EWS)/a tests compilation on several WebKit ports and runs the layout tests on the mac port, so waiting for those bots to show green is an alternative to running the tests by hand. I'm not exactly sure what page text like this would belong on, though. Maybe the contributing page? Maybe the webkit committers/reviewers policy? On Tue, May 11, 2010 at 10:28 PM, Peter Kasting pkast...@google.com wrote: On Tue, May 11, 2010 at 2:20 PM, Geoffrey Garen gga...@apple.com wrote: Yes, this way of doing things has more overhead for you personally but saves overhead for everyone else in the project. I don't think it's fair to frame my perspective as me personally and your perspective as everyone else in the project. I don't think that's a valid interpretation of the above sentence. It seems to simply be saying there is a cost to the patch creator of running the patch past the bots, and there is a cost to the developer community at large if the tree is broken, which is undeniably true. If you'll permit me to editorialize, my guess is that some Google employees prefer a rigid green tree policy because it matches their internal development process, and it makes integrating with that process and committing patches for other Google employees easier. As a Google employee I am puzzled as to how a green tree policy makes integrating with the process and committing patches for other Google employees easier. You seem to be suggesting that familiarity/similarity to another policy is some sort of benefit. I can't see how that's true, nor have I ever heard a Google employee suggest such. For the people who would prefer a green tree policy, I suspect the rationale is that they believe it lowers overall development costs, irrespective of what other policies on other projects may be, which clearly you do not agree with. Exactly. Chromium has a WebKit Gardener rotation for this purpouse. The current gardener watches the various bots to decide what the latest WebKit CL that's safe to use with Chromium is. If there's breakage in WebKit, we obviously don't roll to one of those CLs. So really, the WebKit tree being red has almost no impact on Chromium development. Note that Adam and Eric are not on this rotation, so their arguments can't be based on what's easiest for the integration process in Chromium (or anything like that). That said, many WebKit developers (who happen to work for Google and/or on Chromium) find the tree being red a problem for other reasons. Whether or not you personally agree with the commit queue, a lot of WebKit developers do. And tree redness is not compatible with that. Personally, I like being able to just sync to head and assume that there's a very good chance the code will just work. Requiring everyone who's syncing a tree to go to build.webkit.org seems annoying. But most importantly, when you allow failures to linger around, it becomes much harder to pinpoint where regressions crept in. I remember at least one well documented case of such a thing happening (and taking several people over a day to figure out) being posted to webkit-dev. Avoiding such problems is the primary reason why rolling out regressions and/or fixing regressions quickly is important to many WebKit developers (including some who
Re: [webkit-dev] Yet another bug-less change hosed the tree.
On Tue, May 11, 2010 at 5:51 PM, Alexey Proskuryakov a...@webkit.org wrote: 11.05.2010, в 0:56, Maciej Stachowiak написал(а): I do think making it capable of handling subdirectories would be an improvement for SVN users. Also, I suspect it doesn't work as well as it could for people who prefer to edit ChangeLogs in a non-command-line editor, and for people who are very much in the habit of running prepare-ChangeLog before they even think about uploading a patch. Even with those limitations, I personally find it very useful, and I am a grumpy curmudgeon about tools. FWIW, I'm unwilling to use a command line tool to deal with Bugzilla, no matter how refined. I don't work on a browser engine to run away from the experience it provides. The problem with the experience is not the web browser but bugzilla + integration with other tools. Maybe if you were editing in bespin and using some sort of cloud based compiling farm (cool idea...) then it'd make sense to stay in the browser for the patch review/tracking side of things. But the reality is that most of us use some sort of IDE/editor + command line tools to do our job. I don't see how not using a web browser for one particular task on one particular site (that's not very great anyway) is somehow betraying the product you're working on. J P.S. Thanks so much everyone who's worked on webkit-patch! It takes SO much pain out of working on WebKit. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Testing changes to CodeGenerator*.pm
On Thu, Apr 29, 2010 at 9:05 PM, Adam Barth aba...@webkit.org wrote: On Thu, Apr 29, 2010 at 12:43 PM, Maciej Stachowiak m...@apple.com wrote: It seems to me a better model would be to regenerate the bindings test file automatically as part of the build. Then the changes can still be reviewed by you, or as part of a diff, but there would be no extra manual steps involved. And people making behaviorally transparent changes to codegen output would perhaps feel a little less burdened. That sounds like a good improvement. I think it would be fine to regenerate the output as part of the build. However, I think we should still preserve the ability to run the script along it test mode because that's about three orders of magnitude faster than performing a build after touching CodeGeneratorJS. From reading this thread, this seems like the best solution and most easy to accomplish. We already have the standalone script, so all we need to do is hack it into the build. Isn't there some makefile that generates the derived sources for at least most of the platforms? Couldn't we just add it to that? People who don't care or value it could continue with their current work-flows unaffected. And those that it helps can continue with their workflows as well, as far as I can tell. And, optionally, if someone would like to create more robust testing frameworks in the future could. Am I totally missing something? I feel like I must since this discussion has continued on for a while beyond this point. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MD5 in WebCore
Agreed. Can you give us a pointer to the email thread this decision was
made on?
On Tue, Apr 20, 2010 at 12:12 PM, Alex Russell slightly...@google.comwrote:
Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.
On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman micha...@google.com
wrote:
In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows and md5.cc elsewhere?
For chrome, I don't think we can have a dependency between
WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit'
also
doesn't work. How can we avoid replicating the code? I guess having
webcore's MD5 be platform specific could help us along those lines?
On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak m...@apple.com
wrote:
On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
I'm implementing new protocol of WebSocket
( http://www.whatwg.org/specs/web-socket-protocol/ ).
Since it now requires MD5 in handshake, I wonder how I could add MD5 in
WebCore. For now, there is no MD5 in WebCore. It is in
WebKitTools/DumpRenderTree to get message digest of image file.
I'm thinking to add new header file as WebCore/platform/MD5.h, which
provides the following functions.
struct MD5_CTX;
void MD5_Init(MD5_CTX*);
void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
void MD5_Final(unsigned char hash[16], MD5_CTX*);
In Windows platform, it is implemented using Cryptdll.dll. Is it ok
to
copy WebKitTools/DumpRenderTree/win/MD5.cpp to
WebCore/platform/win/MD5.cpp,
or move?
In Mac platform, it is provided by CommonCrypto/CommonDigest.h with
#define COMMON_DIGEST_FOR_OPENSSL ?
In Chromium, there is chrome/src/base/md5.{h,cc}. Should I copy this
in
WebCore/platform/chromium, or add dependency to base from WebCore?
How about other ports? is it ok to link openssl or some other library?
(or use implementation used in chromium?)
I'm also wonder I need to put these functions in namespace WebCore.
If you put this code in WebCore, it should go in the WebCore namespace.
I
think it would also be a good idea to turn the API into something more
WebCore-ish, something like:
namespace WebCore {
class MD5 {
MD5(); // what was MD5_Init
addBytes(uint8_t* input, size_t length); // what was MD5_Update
;
or maybe this should take a Vectoruint8_t?
Vectoruint8_t, 16 checksum(); // what was MD5_Final
};
}
(The key point being to match the coding style guidelines for names, but
it also seems better to use a class here instead of a struct and
functions
that take a pointer to it.)
Regards,
Maciej
___
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] Announcing WebKit2
On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote: On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote: On Apr 8, 2010, at 6:23 PM, Adam Treat wrote: Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? The time for that discussion is now. The forum is here. I suggest we use this mailing list, not a bug report. Isn't that a little cart before the horse? It is already actively being landed... I'd have to agree. A new port is a maintenance burden on the entire community. Normally we discuss such things before starting to commit them. For example, my first question is whether we can adapt the Chromium WebKit API (or devise an API that could replace the Chromium WebKit API) since it sounds like our goals and the goals of this new API are fairly similar. If we do the former, I'm sure we can talk about changing the name. :-) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [57262] trunk/JavaScriptCore
On Thu, Apr 8, 2010 at 5:59 PM, Alexey Proskuryakov a...@webkit.org wrote: On 08.04.2010, at 1:16, o...@webkit.org wrote: + // [Qt]r57240 broke Qt build (might be a gcc bug) + // FIXME! See: https://bugs.webkit.org/show_bug.cgi?id=37253 FIXME! is different from FIXME: in that Xcode doesn't recognize it. I wasn't even aware that Xcode did recognize it or that we used that convention because it does. We should probably document this somewhere. I'm surprised that style guide doesn't say anything about FIXME vs. TODO. What do you mean? Are you suggesting that we should be using both and for different purposes? But I'm not sure if a comment was even needed here - the ugliness of nested #ifs shouts the same. - WBR, Alexey Proskuryakov ___ 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] Windows mobile build
On Sun, Apr 4, 2010 at 10:45 AM, Patrick Roland Gansterer par...@paroga.com wrote: Hi, i had the same problem some months ago (https://lists.webkit.org/pipermail/webkit-dev/2010-January/011160.html), but didn't get any final reply. I had a look onto other (meta) buildsystems, but most of them lack WinCE (cross compile) support. I also tried gyp, but didn't get it working out of the box for WinCE. In my opinion qmake has the best support for building on WinCE at the moment. I also had the same idea like Kwang Yul. I think this (python) script should also generate all the other buildsystems (vcproj, xcode, GNUmake, qmake, ...). Then only this script must be changed when a file was added or removed. If I'm not wrong gyp was born to fulfil exactly this task? The best solution might be to add additional generators (e.g for the Qt-port) to gyp and then remove all other buildsystems from the tree? If somebody knows the long-term goal of the webkit buildsystem I'm very interested. If gyp is the preferred solution I might also spend some time with the WinCE part for it. The future of build systems in WebKit seems like a great topic for the meeting. It's already kind of ridiculous how much effort it requires to add one file. I'd hate for it to get that much more complex. - Patrick KwangYul, have you considered using gyp (and the files already there) rather than add another generating solution? Jason, have you considered using gyp to generate your solution? Disclaimer: I have no stake in gyp nor do I think it is necessarily better than anything else, but I do care about not modifying 7+ build files for any file additions/moves, etc. dave ___ 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 Icon license?
On Wed, Mar 24, 2010 at 12:28 AM, Maciej Stachowiak m...@apple.com wrote: On Mar 23, 2010, at 3:25 AM, Jeremy Orlow wrote: It seems as though we should at very least change the main icon on webkit.org to match what is apparently the official webkit logo. The icons for the Mac and Windows nightlies probably needn't change since they're run within Safari anyway, but probably the nightly source icon should change. Anyone disagree? There is no official WebKit logo, so I wouldn't make changes based on that assumption. What we have is artwork that has been used on various WebKit-related sites. It's certainly a change worth considering to create and consistently deploy an official WebKit logo. A design contest might be a good way to go with that, and perhaps it's something we could discuss at the contributor meeting. But I would suggest not messing with the visual design of the site in the meantime. Even if no logo is official, being consistent across the WebKit sites (, shirts, etc) seems like a good goal. That said, this certainly isn't an emergency. Maybe we should just hold off until the meeting and discuss this there? (And if any kind souls would like to make a proposal or two in time for the meeting, I'm sure that would help the process.) Even if we did have an official WebKit logo, it might still make sense to have an icon on nightly.webkit.org that matches the icon of the nightly launcher, rather than one that matches the WebKit logo. That's assuming we don't add any nightly launchers with a different icon (which would presumably occur if we had any that launched a browser other than Safari). Agreed. (That's what I was trying to say.) Except that the nightly source would probably use a more generic icon since it's not tied to any particular launcher. Regards, Maciej I'll spin up a patch later this week. J On Tue, Mar 23, 2010 at 6:02 AM, Eric Seidel e...@webkit.org wrote: So it would appear then that www.webkit.org and nightly.webkit.org are the odd men out. :) On Mon, Mar 22, 2010 at 10:57 PM, Sam Weinig sam.wei...@gmail.com wrote: And our own http://planet.webkit.org/. -Sam On Mon, Mar 22, 2010 at 3:11 PM, Chris Jerdonek cjerdo...@webkit.org wrote: On Mon, Mar 22, 2010 at 2:30 PM, Eric Seidel e...@webkit.org wrote: Interesting. Looks like the WebKit icon on CIA is different from webkit.org. I could have sworn they used to be the same: http://cia.vc/stats/project/webkit That's also the icon used for the WebKit group on LinkedIn: http://www.linkedin.com/groups?about=gid=91394 [Resent from correct address.] -eric On Mon, Mar 22, 2010 at 11:07 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Contest is fine :-) That is how our designers created the Maemo logo: https://wiki.maemo.org/Task:maemo.org_logo_contest http://wiki.maemo.org/Maemo.org_logo_contest_submissions I'm cc'ing Marcelo, who is our Brazilian Head of User Experience and Design. Cheers, Kenneth On Mon, Mar 22, 2010 at 12:55 PM, Dimitri Glazkov dglaz...@chromium.org wrote: I just reached out to the Russian icon powerhouse, Turbomilk (turbomilk.com), and they're interested in pitching in as well. Maybe we should have a contest? :DG On Mon, Mar 22, 2010 at 5:43 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I have asked our designers to look into it :-) Kenneth On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler da...@apple.com wrote: On Mar 19, 2010, at 8:40 AM, Dimitri Glazkov wrote: Would you happen to know how WebKit icon is licensed? The icon currently on webkit.org has the icon for Apple’s Safari web browser in it. Because of that, Apple has provided no license to use the icon; we are continuing to use it with informal permission from Apple. Given that WebKit has been more than just the rendering engine Safari uses for quite some time now, I wonder if it'd be worth trying to come up with something unique for the project. One benefit would be that it could be used more freely. Anyone with graphic design skillz going to the WebKit meeting? :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior
Re: [webkit-dev] WebKit Icon license?
It seems as though we should at very least change the main icon on webkit.org to match what is apparently the official webkit logo. The icons for the Mac and Windows nightlies probably needn't change since they're run within Safari anyway, but probably the nightly source icon should change. Anyone disagree? I'll spin up a patch later this week. J On Tue, Mar 23, 2010 at 6:02 AM, Eric Seidel e...@webkit.org wrote: So it would appear then that www.webkit.org and nightly.webkit.org are the odd men out. :) On Mon, Mar 22, 2010 at 10:57 PM, Sam Weinig sam.wei...@gmail.com wrote: And our own http://planet.webkit.org/. -Sam On Mon, Mar 22, 2010 at 3:11 PM, Chris Jerdonek cjerdo...@webkit.org wrote: On Mon, Mar 22, 2010 at 2:30 PM, Eric Seidel e...@webkit.org wrote: Interesting. Looks like the WebKit icon on CIA is different from webkit.org. I could have sworn they used to be the same: http://cia.vc/stats/project/webkit That's also the icon used for the WebKit group on LinkedIn: http://www.linkedin.com/groups?about=gid=91394 [Resent from correct address.] -eric On Mon, Mar 22, 2010 at 11:07 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Contest is fine :-) That is how our designers created the Maemo logo: https://wiki.maemo.org/Task:maemo.org_logo_contest http://wiki.maemo.org/Maemo.org_logo_contest_submissions I'm cc'ing Marcelo, who is our Brazilian Head of User Experience and Design. Cheers, Kenneth On Mon, Mar 22, 2010 at 12:55 PM, Dimitri Glazkov dglaz...@chromium.org wrote: I just reached out to the Russian icon powerhouse, Turbomilk (turbomilk.com), and they're interested in pitching in as well. Maybe we should have a contest? :DG On Mon, Mar 22, 2010 at 5:43 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I have asked our designers to look into it :-) Kenneth On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler da...@apple.com wrote: On Mar 19, 2010, at 8:40 AM, Dimitri Glazkov wrote: Would you happen to know how WebKit icon is licensed? The icon currently on webkit.org has the icon for Apple’s Safari web browser in it. Because of that, Apple has provided no license to use the icon; we are continuing to use it with informal permission from Apple. Given that WebKit has been more than just the rendering engine Safari uses for quite some time now, I wonder if it'd be worth trying to come up with something unique for the project. One benefit would be that it could be used more freely. Anyone with graphic design skillz going to the WebKit meeting? :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.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 ___ 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] WebKit Icon license?
And does anyone know where the original artwork is and/or came from? On Tue, Mar 23, 2010 at 10:25 AM, Jeremy Orlow jor...@chromium.org wrote: It seems as though we should at very least change the main icon on webkit.org to match what is apparently the official webkit logo. The icons for the Mac and Windows nightlies probably needn't change since they're run within Safari anyway, but probably the nightly source icon should change. Anyone disagree? I'll spin up a patch later this week. J On Tue, Mar 23, 2010 at 6:02 AM, Eric Seidel e...@webkit.org wrote: So it would appear then that www.webkit.org and nightly.webkit.org are the odd men out. :) On Mon, Mar 22, 2010 at 10:57 PM, Sam Weinig sam.wei...@gmail.com wrote: And our own http://planet.webkit.org/. -Sam On Mon, Mar 22, 2010 at 3:11 PM, Chris Jerdonek cjerdo...@webkit.org wrote: On Mon, Mar 22, 2010 at 2:30 PM, Eric Seidel e...@webkit.org wrote: Interesting. Looks like the WebKit icon on CIA is different from webkit.org. I could have sworn they used to be the same: http://cia.vc/stats/project/webkit That's also the icon used for the WebKit group on LinkedIn: http://www.linkedin.com/groups?about=gid=91394 [Resent from correct address.] -eric On Mon, Mar 22, 2010 at 11:07 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Contest is fine :-) That is how our designers created the Maemo logo: https://wiki.maemo.org/Task:maemo.org_logo_contest http://wiki.maemo.org/Maemo.org_logo_contest_submissions I'm cc'ing Marcelo, who is our Brazilian Head of User Experience and Design. Cheers, Kenneth On Mon, Mar 22, 2010 at 12:55 PM, Dimitri Glazkov dglaz...@chromium.org wrote: I just reached out to the Russian icon powerhouse, Turbomilk (turbomilk.com), and they're interested in pitching in as well. Maybe we should have a contest? :DG On Mon, Mar 22, 2010 at 5:43 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: I have asked our designers to look into it :-) Kenneth On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler da...@apple.com wrote: On Mar 19, 2010, at 8:40 AM, Dimitri Glazkov wrote: Would you happen to know how WebKit icon is licensed? The icon currently on webkit.org has the icon for Apple’s Safari web browser in it. Because of that, Apple has provided no license to use the icon; we are continuing to use it with informal permission from Apple. Given that WebKit has been more than just the rendering engine Safari uses for quite some time now, I wonder if it'd be worth trying to come up with something unique for the project. One benefit would be that it could be used more freely. Anyone with graphic design skillz going to the WebKit meeting? :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.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 ___ 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] WebKit Icon license?
On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler da...@apple.com wrote: On Mar 19, 2010, at 8:40 AM, Dimitri Glazkov wrote: Would you happen to know how WebKit icon is licensed? The icon currently on webkit.org has the icon for Apple’s Safari web browser in it. Because of that, Apple has provided no license to use the icon; we are continuing to use it with informal permission from Apple. Given that WebKit has been more than just the rendering engine Safari uses for quite some time now, I wonder if it'd be worth trying to come up with something unique for the project. One benefit would be that it could be used more freely. Anyone with graphic design skillz going to the WebKit meeting? :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Unofficial reviews (WAS: Why I'm reviewing patches outside my area (and why you should too))
On Wed, Mar 10, 2010 at 7:45 AM, Zoltan Herczeg zherc...@inf.u-szeged.huwrote: Hi, It's also a big help when peers (which aren't necessarily WebKit reviewers) look over it and give review-style feedback as well. Especially when said peers know more about that code than any of the official reviewers. Is that really help? Sometimes when a patch looks good to me, it still rots in the bugzilla for weeks. On the other hand, sometimes I have concerns about the patch, and somebody just pop in and give an r+ without any comments. It depends on a lot of things. It depends on the webkit reviewer. It depends on the unofficial reviewer (are they an expert in the subject, for example). I can give you a success story though: michaeln is probably the most qualified reviewer of WebSQLDatabase code these days. He looks at most patches that go by, and I think on average he offers more and better comments than the official reviewers. The few WebSQLDatabase patches I have reviewed, I asked for Michael's sign off before r+ing. Are there any specific examples of where you've seen that happen? It might be easier to talk about specific instances. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unofficial reviews (WAS: Why I'm reviewing patches outside my area (and why you should too))
On Wed, Mar 10, 2010 at 1:16 PM, Adam Treat tr...@kde.org wrote: On Wednesday 10 March 2010 07:06:16 am Jeremy Orlow wrote: I can give you a success story though: michaeln is probably the most qualified reviewer of WebSQLDatabase code these days. He looks at most patches that go by, and I think on average he offers more and better comments than the official reviewers. The few WebSQLDatabase patches I have reviewed, I asked for Michael's sign off before r+ing. I'd say that the solution is to nominate him for reviewing then. He's got a ways to go to 80: http://trac.webkit.org/search?q=michaeln :-) Besides, a WebKit reviewer is a bit different than someone who does a code review in most projects. It's partially about making sure the semantics of the code are right, but it's also about helping guide the project as a whole in a healthy direction and mentoring new WebKit contributors. I think it's a good thing that non-reviewers take a look at code and offer comments. And I think it's good for reviewers to consider these comments when doing their review--or maybe even solicit comments. But I don't necessarily think that every subject matter expert should be a WebKit reviewer. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Tue, Mar 9, 2010 at 9:19 AM, Robert O'Callahan rob...@ocallahan.orgwrote: Mozilla has been using this technique for years. Perhaps we can pick their brains for some good tricks. Or, dare I say it, share some tests. Hi, hope I'm not crashing the party, and sorry I'm late :-). Let me just say a few things about reftests... Maciej mentioned that a reftest can assert that b and style=font-weight:bold are equivalent, but would not catch a bug that completely disabled font-weight. That is true. However, in our reftest framework you can also assert that two pages render differently, so you can test that font-weight:normal renders differently from font-weight:bold, which would catch a bug like that. If you look in the Mozilla reftests, there are many tests with 'sanity' in the name ensuring that pages that should render differently, do. You could still miss a weird bug like font-weight:bold making the text italic instead. But in practice, we hardly ever encounter bugs that cause some reftests to render incorrectly and still all tests pass. Over time we have learned a number of tricks for writing reftests. Here are a few: -- In general we require tests to match pixel-perfectly. It's always tempting to allow a fudge factor, but tiny differences can indicate significant bugs. -- We have nifty SVG filter tricks to help find those tiny differences, e.g. http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/reftest-analyzer.xhtml -- If some pixels of a test are unpredictable or platform-dependent, but not relevant to the test, you can censor them out by placing an opaque element over them in the test and reference. This and several of the other tips in here seem like they can apply nicely to our existing layout tests as well. -- In other tests with unpredictable pixel values, e.g. video, we use SVG filters to threshold pixel channel values. -- The Web usually has More Than One Way To Do It. E.g. for CSS gradients, a lot of our reference pages use canvas to render a reference gradient. -- Many Web features have particular cases that are easy to reduce to reftests even when general cases aren't. For example, box-shadow and text-shadow with no blur are trivial to test with reftests. You can create gradients using repeated stops to achieve abrupt transitions and test them against colored boxes. You could use a similar trick to test patterns in SVG text. -- Aggressive subpixel antialiasing is a real pain. For example, wrapping text in an overflow:hidden container isn't always a no-op even if the container is sized to its contents. Using sans-serif fonts helps, using CSS padding helps more. -- For speed, conciseness and overall expediency, you can often pack many variations of a test into a single reftest page, and in practice there's no significant downside to that. One might argue that although reftests are a good way to test what they test, they don't provide enough broad functional testing, e.g. to make sure that blurs look right. I don't have good data to refute or confirm that. However, if we want to, we can get an image test just by making the reference page a PNG ... but I can only see two cases out of over 4000 where we felt we needed to do that. Overall, I'm extremely enthusiastic about reftests! As others mentioned, we'd like to get official CSS and SVG test suites using reftests; they're the best approach I know of for writing robust automated layout and rendering tests across platforms and browsers. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] ___ 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] Why I'm reviewing patches outside my area (and why you should too)
On Tue, Mar 9, 2010 at 9:39 PM, David Levin le...@chromium.org wrote: (3) Someone reviewed an earlier version of the patch but then didn't follow up. I think having a partial review by one person encourages other people to assume that person will finish the review. That cause the patch to float upwards in pending-review until it gets lost in the sea of ancient patches. I'd encourage reviewers to follow through with their reviews Don't be afraid of r-ing a patch. Believe me, folks are thankful for feedback (even negative feedback) when their patches have been sitting around collecting dust. However as soon as you r- a patch, according to 3, you need to finish the review when it gets re-submitted. This leads me to believe that *one shouldn't avoid a patch that has feedback from someone else* unless one doesn't feel qualified to judge whether the feedback has been addressed. I plea to folks submitting patches: 1. Keep your patches as small as possible. It is no fun to deal with a 60K patch. 2. Review your own patches before or right after you attach them to the bug as if you were reviewing someone else's code. 3. Address any style issues, build issues that the bots notice. You don't need to wait for a review to point out the same issue. It's also a big help when peers (which aren't necessarily WebKit reviewers) look over it and give review-style feedback as well. Especially when said peers know more about that code than any of the official reviewers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Crashes during testing
On Fri, Feb 26, 2010 at 12:03 AM, Oliver Hunt oli...@apple.com wrote: But any regressions would have been blamed on eric. His name would show up in the SVN log, sure, but I don't think that'd fool your average WebKit developer for long. webkit-patch land does the correct thing, but i disable the testing prior to commit because a 25 minute delay prior to committing is more or less guaranteed to cause it to fail to commit due to someone else landing. Did you run the layout tests at all? I generally land with --no-build as well, but only after it's successfully passed at least one build + run of the layout tests. On Feb 25, 2010, at 2:58 PM, Kenneth Russell wrote: OK, thanks, that appears to have fixed it. How about that commit queue? Would have caught the crashes before they were checked in. -Ken On Thu, Feb 25, 2010 at 2:53 PM, Oliver Hunt oli...@apple.com wrote: Update to r55258 or later :D --Oliver On Feb 25, 2010, at 2:46 PM, Kenneth Russell wrote: A change committed some time since yesterday evening has introduced many crashes in JSC's GC during testing. A representative stack trace is attached. If you have made changes in this area recently, can you please look into this? Thanks, -Ken crash.txt___ 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] The tree is on fire: a tragedy of the commons
On Fri, Feb 26, 2010 at 10: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. 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. I suspect most of our brokenness coming from committers skipping steps 6 and 7. LGTM. The only thing I'd add is that we REALLY need emails to start going out to webkit-dev (and ideally the suspected patch owners as well) when things do break. What is doing this blocked on? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Crashes during testing
Personally, I've found those kind of changes are responsible for a disproportionate percentage of build errors and bugs. :-) On Fri, Feb 26, 2010 at 5:16 PM, Darin Adler da...@apple.com wrote: On Feb 26, 2010, at 1:42 AM, Jeremy Orlow wrote: Did you run the layout tests at all? Oliver already said that he did, but before he made the small last minute change that caused the crash. -- Darin ___ 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 6:47 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Fri, Feb 26, 2010 at 9:44 AM, Eric Seidel e...@webkit.org wrote: The bots take 15 minutes to cycle. The moment the build is broken, thats FIX_TIME + BOT_CYCLE_TIME until their green again. I think we should cap the fix grace period at something like 15 minutes, that means no more than 30 minutes of tree redness per break. That might be too aggressive to start with for WebKit, but I think we should move towards that. I would re-write rule one as something like this: 1. Comment in the bugzilla bug when the build breaks. If there is no bugzilla bug, comment in #webkit. 2. 15 minutes after the break or 10 minutes after the comment, with no reply from the breaker, roll out the patch. Sounds great. Is this going to be a new page on webkit.org? Agree it sounds like a good plan. Re the emails: who knows how to do that? Can someone own this process to completion and do it as soon as possible? It'd be much appreciated! :DG -eric On Fri, Feb 26, 2010 at 9:32 AM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 26.02.2010 um 18:17 schrieb Dimitri Glazkov: To summarize the thread: 1) We're adopting when in doubt, roll it out approach to patches that turn tree red. 2) Need to find a way to run Mac-EWS for non-committers. 3) Enable build-break emails to webkit-dev or another opt-in mailing list What else? I'm a bit scared of rule 1. How about we define a minimum delay when to roll-out patches, after they break something? Let's say, if a commit breaks the tree, give the commiter a time frame of 30 minutes to fix it - otherwhise roll-out (we could even automate that.) Example: When landing a SVG patch, that worked fine on Leopard, but broke Snow Leopard, I'd like to have some time to identify wheter it's the fault of my patch, or a platform specific problem. If it's the fault of my patch, I have no problem with reverting. But if I can't immediately fix the problem, because it's a platform specific issue, which can not be fixed (in terms of WebKit), then adding to the Skipped list, and filing a new bug just takes 5 minutes. Reverting the whole patch, just to reland it with a Skipped list addition is a bit too much work for me. What do others think? Cheers, Niko ___ 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] The tree is on fire: a tragedy of the commons
On Fri, Feb 26, 2010 at 7:06 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 26, 2010, at 9:56 AM, Alexey Proskuryakov wrote: On 26.02.2010, at 9:29, Maciej Stachowiak wrote: I'd like it if we had an IRC bot that announced build breakage on #webkit. Perhaps better yet, on #webkit-build, as buildbot used to do. In the past, no one ever joined #webkit-build so this was not an effective means of notification. I didn't even know it existed until now. Was there ever an email sent out on this? If so, I missed it. ___ 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 8:53 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 26, 2010, at 11:43 AM, Simon Fraser wrote: Mozilla has (or at least had when I worked there) two additional tree rules that helped keep the tree green: 1. A sheriff was appointed at all times, and had the authority to close the tree if there was significant build or test breakage. Closing the tree meant that it was blocked to new commits other than those intended to fix problems. Closing the tree also sends a strong message that something is broken, please pitch in and fix it if you can. Sheriff duties were shared around between responsible committers, so as not to overly burden one person. I think the build sheriff idea is a good one. Maybe what we want is to have a sheriff responsible for each build train that has an active buildbot. (It could be the same person responsible for several build trains, the main qualification would be having reasonable familiarity with a port and access to its build environment.) However, I am not so sure close the tree is necessarily the best focus for sheriff actions. What I'd prefer to see is that the sheriff the person primarily responsible for reverting broken patches if not fixed in a timely manner. Then we could have some human judgment in the process and specific people with clear responsibility. I agree close to the tree is not necessary for the reasons you listed. And I think most people from the Chromium would welcome this change (sheriff + ability to close). We've been advocating it for some time now. :-) 2. The Mozilla tinderbox page (their buildbot waterfall) had a way for people to leave comments, by adding a star to a particular build with a comment. This is used as a way to communicate that someone has noticed the breakage, and is working on it. Sounds like a good idea. Wondering if that fits better in the console view or the extensions view. In general, I think the waterfall page could be improved in order to make breakage archeology easier. Entries in the Changes column should be direct links to trac changesets, for example. That sounds good too. Another thing that would help is adding next page links to the console view, like we have on the waterfall. The console link often makes it easier to quickly identify the patch that went bad, but only if the badness is recent enough to show up. Regards, Maciej ___ 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 9:00 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Feb 26, 2010 at 8:53 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 26, 2010, at 11:43 AM, Simon Fraser wrote: Mozilla has (or at least had when I worked there) two additional tree rules that helped keep the tree green: 1. A sheriff was appointed at all times, and had the authority to close the tree if there was significant build or test breakage. Closing the tree meant that it was blocked to new commits other than those intended to fix problems. Closing the tree also sends a strong message that something is broken, please pitch in and fix it if you can. Sheriff duties were shared around between responsible committers, so as not to overly burden one person. I think the build sheriff idea is a good one. Maybe what we want is to have a sheriff responsible for each build train that has an active buildbot. (It could be the same person responsible for several build trains, the main qualification would be having reasonable familiarity with a port and access to its build environment.) However, I am not so sure close the tree is necessarily the best focus for sheriff actions. What I'd prefer to see is that the sheriff the person primarily responsible for reverting broken patches if not fixed in a timely manner. Then we could have some human judgment in the process and specific people with clear responsibility. I agree close to the tree is not necessary for the reasons you listed. And I think most people from the Chromium would welcome this change (sheriff + ability to close). We've been advocating it for some time now. :-) OopsI completely misread what you said. The reason why being able to close the tree is important is because sometimes it can take a while to sort out what caused what failures. And it's important not to allow more breakage in the mean time. In Chromium, we often have a good deal of redness, but as long as the sheriffs feel as though they're on top of it, the tree stays open. Now, I'll admit that we have many more long running bots (like memory leak bots) and so these kinds of train wrecks that require sorting happen way less in WebKit, but it still might be nice to have the ability when necessary. The suggestion below (2) about notes on the waterfall sounds great, but we do OK by abusing the tree is closed/open string to keep track of other state (like who's working on what fix). We've found this works good enough. And maybe some informal banner like this would be good enough for the first rev, unless we thought per CL annotations would be easy to implement. I'll note that in the Chromium project, we've had a very strong keep the tree green ethic for some time now. And we have a good deal of experience related to it. Certainly there are multiple ways to solve various problems, but it might be worth taking a look at how we do things to see if there are other parts of how we do things that might be of interest. 2. The Mozilla tinderbox page (their buildbot waterfall) had a way for people to leave comments, by adding a star to a particular build with a comment. This is used as a way to communicate that someone has noticed the breakage, and is working on it. Sounds like a good idea. Wondering if that fits better in the console view or the extensions view. In general, I think the waterfall page could be improved in order to make breakage archeology easier. Entries in the Changes column should be direct links to trac changesets, for example. That sounds good too. Another thing that would help is adding next page links to the console view, like we have on the waterfall. The console link often makes it easier to quickly identify the patch that went bad, but only if the badness is recent enough to show up. Regards, Maciej ___ 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] Commit queue blocked because of failing tests
The only time I've ever had an issue with committing is when I forgot to add the file myself. The bot uses the same scripts that committers do. I think it'd be worth your time to become comfortable with them. If nothing else, so you can land fixes for when you break the build. It also frees up the queue for those who need it. I'd take another shot at landing yourself if I were you. On Thu, Feb 25, 2010 at 1:17 AM, Kenneth Russell k...@google.com wrote: On Wed, Feb 24, 2010 at 3:48 PM, David Levin le...@chromium.org wrote: 1. It looks like you are a committer, so you don't need to wait for the commit queue to do this for you :) Understood -- but I prefer to use the bots where possible. I've seen multiple instances where the commit scripts failed to add new files for some reason, but the bots have always been 100% reliable. -Ken 2. But it still would be good to have this fixed. If you'd like to help move this along, you can go to http://build.webkit.org/waterfall and find which patch caused the test to start failing. Then ping the relevant person. On Wed, Feb 24, 2010 at 3:41 PM, Kenneth Russell k...@google.com wrote: On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov a...@webkit.org wrote: On 24.02.2010, at 11:47, David Levin wrote: Actually, it doesn't appear to be do to recent changes in this area. They started failing after r55177 (http://build.webkit.org/waterfall?last_time=1266975298), but that change is unrelated to these test as far as I can tell. It looks unrelated, but it somehow broke these editing tests nonetheless. I'm investigating now. Thanks. Our patch (from https://bugs.webkit.org/show_bug.cgi?id=34459) was about to be landed by the bot when the tree went red again. The test now failing is: fast/dom/prototype-inheritance-2.html - failed Could someone please look? Thanks, -Ken ___ 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] Commit queue blocked because of failing tests
The only time I've ever had an issue with committing is when I forgot to add the file myself. The bot uses the same scripts that committers do. I think it'd be worth your time to become comfortable with them. If nothing else, so you can land fixes for when you break the build. It also frees up the queue for those who need it. I'd take another shot at landing yourself if I were you. On Thu, Feb 25, 2010 at 3:29 AM, Dan Bernstein m...@apple.com wrote: On Feb 24, 2010, at 3:50 PM, Eric Seidel wrote: I find http://build.webkit.org/console more useful. In this case, looks like mitz's patch changed the test: http://trac.webkit.org/changeset/55203 Sorry about the inconvenience. I will try to fix this shortly. I'm glad to see more folks are watching the bots! -eric On Wed, Feb 24, 2010 at 3:48 PM, David Levin le...@chromium.org wrote: 1. It looks like you are a committer, so you don't need to wait for the commit queue to do this for you :) 2. But it still would be good to have this fixed. If you'd like to help move this along, you can go to http://build.webkit.org/waterfall and find which patch caused the test to start failing. Then ping the relevant person. On Wed, Feb 24, 2010 at 3:41 PM, Kenneth Russell k...@google.com wrote: On Wed, Feb 24, 2010 at 12:02 PM, Alexey Proskuryakov a...@webkit.org wrote: On 24.02.2010, at 11:47, David Levin wrote: Actually, it doesn't appear to be do to recent changes in this area. They started failing after r55177 (http://build.webkit.org/waterfall?last_time=1266975298), but that change is unrelated to these test as far as I can tell. It looks unrelated, but it somehow broke these editing tests nonetheless. I'm investigating now. Thanks. Our patch (from https://bugs.webkit.org/show_bug.cgi?id=34459) was about to be landed by the bot when the tree went red again. The test now failing is: fast/dom/prototype-inheritance-2.html - failed Could someone please look? Thanks, -Ken ___ 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] [webkit-changes] [55234] trunk/JavaScriptCore
Done. On Thu, Feb 25, 2010 at 7:18 PM, Jeremy Orlow jor...@chromium.org wrote: I already started the process of doing a revert and submitting it with a better change log. J On Thu, Feb 25, 2010 at 7:11 PM, Alexey Proskuryakov a...@webkit.orgwrote: On 25.02.2010, at 10:00, David Levin wrote: All the information being provided now explains the why. Unfortunately, this thread doesn't fix the problem that the ChangeLog as checked in only explains *what* as opposed to *why* (even fixing the ChangeLog will leave it disconnected from the code change, but simply rolling it out and then checking it again with a good changelog would fix this). That's the best thing to do, although it may be a bit of overkill. But please at least put this information in Bugzilla - that way, one could still retrieve it, if really interested. - WBR, Alexey Proskuryakov ___ 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] Odd binding problems
On Mon, Feb 22, 2010 at 11:22 PM, Alexey Proskuryakov a...@webkit.org wrote: On 22.02.2010, at 15:16, Eric Uhrhane wrote: My bet is I've failed to add something critical to the bindings, some override for the idl-generated code that wasn't needed in the DOM bindings but is for the Worker bindings. Did you add a NoStaticTables property? I be that's it. Btw, if you're wondering what that means, check out https://trac.webkit.org/wiki/IdlAttributes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Features supported in Android's Webkit borwser
This mailing list is not the proper place for such a question. This is for WebKit development related email only. On Wed, Feb 10, 2010 at 5:49 PM, Vishwesh Jirgale vishwesh.gro...@gmail.com wrote: Hello All, Is there a page/blog where all the features of Android's webkit browser are listed ? I am particularly interested in - 1. XMLHttpRequest support (AJAX Support) 2. Plugins (what can and cant I do) 3. HTML5 Support, if so to what level, what is included and not 4. What version of WebKit is Android using and finally 5. Javascript - what level of functionality Thanks in advance, Vishwesh ___ 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] IndexedDB API
Hm. Now that I look closer, I think the only actual conflict is in the Database interface. It still seemed worth the webapps email though. On Thu, Jan 21, 2010 at 11:40 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Jan 21, 2010 at 11:14 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 21, 2010, at 9:53 PM, Jeremy Orlow wrote: A couple of us at Google are starting to look at implementing the IndexedDB API [1] in WebKit. We thought a good first step would be to create the IDL files. The first thing I noticed is that it and the Web SQL Database API [2] have quite a few conflicts in terms of their interface names. I'm wondering how we can work around this. It seems like this is something that should be fixed in the IndexedDB spec. One idea I had was to just add a prefix to every IndexedDB interface. Maybe something like IDB? I'd probably go ahead and give all the indexed database API files a IDB prefix just to make it clear which files are connected to that API. Does this sound good? Even if you rename the files, having multiple interfaces with the same interface name will still cause problems. I don't think it will even compile. We could do some interim thing but we really need to get the spec fixed. I meant prefixing both the interfaces and the files with IDB which I believe would solve the problem. That said, I agree the correct solution is fixing one or both of the specs. I'll probably try the prefix solution tomorrow though to see if it'd even work. Like I said, we're _just_ getting started. Once we've got the basics down (like the IDL files) we'll probably be writing up a design doc to get feedback on an end-to-end design and/or soliciting more advice on webkit-dev. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] IndexedDB API
(I had forgotten that many of the sql interfaces are prefixed by SQL. So IndexedDB's Transaction interface doesn't actually conflict because SQL's is named SQLTransaction.) On Fri, Jan 22, 2010 at 12:04 AM, Jeremy Orlow jor...@chromium.org wrote: Hm. Now that I look closer, I think the only actual conflict is in the Database interface. It still seemed worth the webapps email though. On Thu, Jan 21, 2010 at 11:40 PM, Jeremy Orlow jor...@chromium.orgwrote: On Thu, Jan 21, 2010 at 11:14 PM, Maciej Stachowiak m...@apple.comwrote: On Jan 21, 2010, at 9:53 PM, Jeremy Orlow wrote: A couple of us at Google are starting to look at implementing the IndexedDB API [1] in WebKit. We thought a good first step would be to create the IDL files. The first thing I noticed is that it and the Web SQL Database API [2] have quite a few conflicts in terms of their interface names. I'm wondering how we can work around this. It seems like this is something that should be fixed in the IndexedDB spec. One idea I had was to just add a prefix to every IndexedDB interface. Maybe something like IDB? I'd probably go ahead and give all the indexed database API files a IDB prefix just to make it clear which files are connected to that API. Does this sound good? Even if you rename the files, having multiple interfaces with the same interface name will still cause problems. I don't think it will even compile. We could do some interim thing but we really need to get the spec fixed. I meant prefixing both the interfaces and the files with IDB which I believe would solve the problem. That said, I agree the correct solution is fixing one or both of the specs. I'll probably try the prefix solution tomorrow though to see if it'd even work. Like I said, we're _just_ getting started. Once we've got the basics down (like the IDL files) we'll probably be writing up a design doc to get feedback on an end-to-end design and/or soliciting more advice on webkit-dev. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] IndexedDB API
A couple of us at Google are starting to look at implementing the IndexedDB API [1] in WebKit. We thought a good first step would be to create the IDL files. The first thing I noticed is that it and the Web SQL Database API [2] have quite a few conflicts in terms of their interface names. I'm wondering how we can work around this. One idea I had was to just add a prefix to every IndexedDB interface. Maybe something like IDB? I'd probably go ahead and give all the indexed database API files a IDB prefix just to make it clear which files are connected to that API. Does this sound good? Like I said, we're _just_ getting started. Once we've got the basics down (like the IDL files) we'll probably be writing up a design doc to get feedback on an end-to-end design and/or soliciting more advice on webkit-dev. J [1] http://www.w3.org/TR/IndexedDB/ [2] http://dev.w3.org/html5/webdatabase/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MathML Patch - Current Code
On Thu, Jan 14, 2010 at 8:23 PM, Alex Milowski a...@milowski.org wrote: I've create a new patch that contains all the current code that I have on MathML at: https://bugs.webkit.org/show_bug.cgi?id=33703 I don't expect anyone to review this patch (unless they want to do so). Since I can't create a branch, I'm using this patch to store the current working copy of my MathML code. Have you considered using git and creating local branches for yourself? This patch handles stretchy operators and row layout fairly well. It also supports fractions, sub/superscripts, over/under, fencing, and tables. I'm working on a status table that I'll put on the wiki somewhere that will detail what works, partially works, or is not implemented. I'll update this patch as I make progress or get smaller patches committed. I plan on creating smaller patches that contain code from this patch and as that gets committed, I'll update this bug with a new patch against the trunk. This pretty much invalidates the previous bug [1] I had for MathML support as the code as change fairly significantly. [1] https://bugs.webkit.org/show_bug.cgi?id=29529 -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Running pixel tests on build.webkit.org
On Fri, Jan 8, 2010 at 9:52 AM, Jeremy Orlow jor...@chromium.org wrote: Plan 3 seems like the best (and simplest) one until the infrastructure for the others (and/or a champion for fixing currently failing tests) is available. What would it take to go with plan 3? I guess someone needs to rebaseline everything that's currently failing, check them in, and then someone (like bdash?) needs to flip a switch on the bots...? Did I miss anything? Are there instructions on how to do the rebaselining anywhere? I've only ever created pixel baselines for Chromium before (where we have a pretty neat tool that pretty much does it for you). Does anyone know? I'm happy to do the rebaselining if someone can tell me how and we agree to turn pixel tests on on the bots. On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene p...@chromium.org wrote: And one very quick, short-term solution: 3. Generate new pixel results to match the current behavior, and check them in as hypothetically correct. And of course if someone notices an existing problem and fixes it, they check in corrected images then. It doesn't help find current problems, but those are being missed now anyway. It does let the tests be run again approximately immediately, even faster than waiting for test expectations functionality, so we can catch regressions moving forward. - Pam On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler da...@apple.com wrote: On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes other tests to fail). SKIP : fast/forms/foo1.html = IMAGE ___ 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] Running pixel tests on build.webkit.org
Wow, much easier than I expected. :-) OK, then what about buy in on this approach? I'll even file bugs on everything I rebaseline so we can track getting things back to a correct state and/or verifying that the new baselines are correct. J On Mon, Jan 11, 2010 at 9:13 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: It's baiscally just run-webkit-tests --reset-results --pixel-tests. No magic :) See run-webkit-tests --help for more info. BTW, Victor is working to port the rebaselining tool to build.webkit.org. You may want to check with him -- maybe he's close to finishing the patch. :DG On Mon, Jan 11, 2010 at 9:06 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jan 8, 2010 at 9:52 AM, Jeremy Orlow jor...@chromium.org wrote: Plan 3 seems like the best (and simplest) one until the infrastructure for the others (and/or a champion for fixing currently failing tests) is available. What would it take to go with plan 3? I guess someone needs to rebaseline everything that's currently failing, check them in, and then someone (like bdash?) needs to flip a switch on the bots...? Did I miss anything? Are there instructions on how to do the rebaselining anywhere? I've only ever created pixel baselines for Chromium before (where we have a pretty neat tool that pretty much does it for you). Does anyone know? I'm happy to do the rebaselining if someone can tell me how and we agree to turn pixel tests on on the bots. On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene p...@chromium.org wrote: And one very quick, short-term solution: 3. Generate new pixel results to match the current behavior, and check them in as hypothetically correct. And of course if someone notices an existing problem and fixes it, they check in corrected images then. It doesn't help find current problems, but those are being missed now anyway. It does let the tests be run again approximately immediately, even faster than waiting for test expectations functionality, so we can catch regressions moving forward. - Pam On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler da...@apple.com wrote: On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes other tests to fail). SKIP : fast/forms/foo1.html = IMAGE ___ 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] Running pixel tests on build.webkit.org
Plan 3 seems like the best (and simplest) one until the infrastructure for the others (and/or a champion for fixing currently failing tests) is available. What would it take to go with plan 3? I guess someone needs to rebaseline everything that's currently failing, check them in, and then someone (like bdash?) needs to flip a switch on the bots...? Did I miss anything? Are there instructions on how to do the rebaselining anywhere? I've only ever created pixel baselines for Chromium before (where we have a pretty neat tool that pretty much does it for you). J On Fri, Jan 8, 2010 at 9:23 AM, Pam Greene p...@chromium.org wrote: And one very quick, short-term solution: 3. Generate new pixel results to match the current behavior, and check them in as hypothetically correct. And of course if someone notices an existing problem and fixes it, they check in corrected images then. It doesn't help find current problems, but those are being missed now anyway. It does let the tests be run again approximately immediately, even faster than waiting for test expectations functionality, so we can catch regressions moving forward. - Pam On Thu, Jan 7, 2010 at 5:01 PM, Ojan Vafai o...@chromium.org wrote: On Thu, Jan 7, 2010 at 10:22 AM, Darin Adler da...@apple.com wrote: On Jan 7, 2010, at 10:19 AM, Dimitri Glazkov wrote: Are we planning to run pixel tests on the build bots? If we can get them green, we should. It’s a lot of work. We need a volunteer to do that work. We’ve tried before. Two possible long-term solutions come to mind: 1. Turn the bots orange on pixel failures. They still need fixing, but are not as severe as text diff failures. I'm not a huge fan of this, but it's an option. 2. Add in a concept of expected failures and only turn the bots red for *unexpected* failurs. More details on this below. In chromium-land, there's an expectations file that lists expected failures and allows for distinguishing different types of failures (e.g. IMAGE vs. TEXT). It's like Skipped lists, but doesn't necessarily skip the test. Fixing the expected failures still needs doing of course, but can be done asynchronously. The primary advantage of this approach is that we can turn on pixel tests, keep the bots green and avoid further regressions. Would something like that make sense for WebKit as a whole? To be clear, we would be nearly as loathe to add tests to this file as we are about adding them to the Skipped lists. This just provides a way forward. While it's true that the bots used to be red more frequently with pixel tests turned on, for the most part, there weren't significant pixel regressions. Now, if you run the pixel tests on a clean build, there are a number of failures and a very large number of hash-mismatches that are within the failure tolerance level. -Ojan For reference, the format of the expectations file is something like this: // Fails the image diff but not the text diff. fast/forms/foo.html = IMAGE // Fails just the text diff. fast/forms/bar.html = TEXT // Fails both the image and text diffs. fast/forms/baz.html = IMAGE+TEXT // Skips this test (e.g. because it hangs run-webkit-tests or causes other tests to fail). SKIP : fast/forms/foo1.html = IMAGE ___ 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] Tech Talk on WebKit
(Oops, I meant to post this before the holidays but completely forgot. Better late than never I suppose?) A couple weeks ago, Eric Seidel gave a tech talk to a live studio audience of Googlers on the guts of webkit. Although there are a few bits that only apply to Chromium, the vast majority of it is simply about WebKit, and thus I thought it might be of interest to others here. The talk operates mostly at a 10,000 foot view and looks at how loading occurs and then steps through many of the various trees used to represent the DOM and handle rendering. http://www.youtube.com/watch?v=RVnARGhhs9w Btw, if anyone else is ever giving a talk on WebKit in the bay area and would like it recorded and put on YouTube, let me know. I'd be more than happy to make it happen. :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tech Talk on WebKit
Well, if there's enough errors, maybe it'll guilt Hyatt into giving a talk. O wait...was that out loud? :-) J On Mon, Jan 4, 2010 at 7:38 PM, Eric Seidel e...@webkit.org wrote: Thanks Jeremy. I did my best to tell the whole truth and nothing but the truth, but if there are factual errors in my talk, I'd love to know about them. -eric On Mon, Jan 4, 2010 at 6:25 PM, Jeremy Orlow jor...@chromium.org wrote: (Oops, I meant to post this before the holidays but completely forgot. Better late than never I suppose?) A couple weeks ago, Eric Seidel gave a tech talk to a live studio audience of Googlers on the guts of webkit. Although there are a few bits that only apply to Chromium, the vast majority of it is simply about WebKit, and thus I thought it might be of interest to others here. The talk operates mostly at a 10,000 foot view and looks at how loading occurs and then steps through many of the various trees used to represent the DOM and handle rendering. http://www.youtube.com/watch?v=RVnARGhhs9w Btw, if anyone else is ever giving a talk on WebKit in the bay area and would like it recorded and put on YouTube, let me know. I'd be more than happy to make it happen. :-) J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
