Re: [webkit-dev] Unused variable shouldDumpSubframesAsText in DumpRenderTree.m
Good catch. It would be really helpful if you would file a bug and post a patch to remove it. See http://webkit.org/coding/contributing.html for information about how to do this. Thanks again. -Sam On 8/21/07, Anyang Ren [EMAIL PROTECTED] wrote: r24862 added an unused variable shouldDumpSubframesAsText to DumpRenderTree.m: Index: DumpRenderTree.m === --- DumpRenderTree.m(revision 24862) +++ DumpRenderTree.m(revision 24863) @@ -91,6 +91,7 @@ BOOL windowIsKey = YES; WebFrame *mainFrame = 0; +BOOL shouldDumpSubframesAsText; BOOL shouldDumpEditingCallbacks; BOOL shouldDumpResourceLoadCallbacks; BOOL shouldDumpFrameLoadCallbacks;ZZ -- Anyang Ren Open source developer ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] JavaScriptCore directory rearrangement proposal
It has always bugged me that WTF was in JavaScriptCore at all. Perhaps now is a good time to move it to its own project. I am not sure what the concerns in the past were about separating WTF from JavaScriptCore. Were they performance related? -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore cleanup
like JSCore or JSC. I prefer JSCore. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 1, 2008 at 1:46 AM, Geoffrey Garen [EMAIL PROTECTED] wrote: In the Chrome tree, every object inheriting from RefCounted incurs an extra pointer in size, but this is clearly more than necessary since many RefCounted objects do not have bindings. If we believe that JS wrappers are relatively uncommon, we can store them in a Node's rare data structure, and bloat only those uncommon nodes that have JS wrappers. If we believe that JS wrappers are relatively common, we can store them directly in a Node, since putting them in a hashtable is net more memory use. This does not have to be an all or nothing strategy. One idea we have discussed was to use different strategies for different classes based on how likely we believe they are to need a binding. For instance, if (since?) HTMLElement is more likely than Text nodes to need bindings, we could store a pointer for HTMLElements and fallback to the HashMap or RareData for Text. Regardless, I think the real blocker here is hard data. We would love to see what the V8 team has found and how they tested those findings. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Enum naming style?
On Wed, Oct 1, 2008 at 4:01 PM, Eric Seidel [EMAIL PROTECTED] wrote:
enum SVGStitchOptions {
SVG_STITCHTYPE_UNKNOWN = 0,
SVG_STITCHTYPE_STITCH = 1,
SVG_STITCHTYPE_NOSTITCH = 2
};
This style is usually used to stay consistent with the DOM IDLs. I don't
think we should change them in those cases as the consistency with the API
is nice.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Thu, Oct 2, 2008 at 8:31 AM, Peter Kasting [EMAIL PROTECTED] wrote: On Wed, Oct 1, 2008 at 10:41 PM, Mike Hommey [EMAIL PROTECTED][EMAIL PROTECTED] wrote: On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: Total size Potential savings www.cnn.com: 43M 410Kwww.facebook.com: 43M 408K www.slashdot.org: 36M 208K m.ext.google.com: 45M 475K docs (normal doc): 42M 341K docs (big spreadsheet):55M 905K maps: 38M 159K It would be interesting to have the figures on 64-bit systems. Why would it be different, since WebKit is (AFAIK) always compiled in 32-bit mode? Or is it 64-bit compat now? WebKit compiles just fine in 64-bit. We even shiped it 32/64 fat on Leopard. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bindings layer should have a consistent way of getting at named items in collections
On Tue, Oct 14, 2008 at 3:15 PM, Ojan Vafai [EMAIL PROTECTED] wrote: I currently see nameGetter, namedItem and getNamedItem in a number of different files that all currently have custom bindings that normalize to a nameGetter function. Can we just have all the collection types normalize on a single name for this function? It would mean that much of this custom binding could be avoided. I'm running into this with Chromium as I am trying to replace our PluginArray and MimeTypeArray with WebKit's. This is messing with our templates that currently just use namedItem (although could just as easily use nameGetter if that's preferred). The big differences with our MimeTypeArray implementation is that it kept a Vector of MimeTypes, returned raw pointers and used namedItem instead of nameGetter. It would be great if we could unify these. I support this idea. Unification of this concept would indeed be nice. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timer callback and 'this' object
Hi Dmitry,
The first example using a closure executes in the parent scope because
functions execute in lexical scope regardless of where they are called from,
capturing variables as required. The string version is simply executed as a
program by the caller and has no knowledge of the scope in which it was
declared. This is a bit strange, but follows the conventions of the
language. As for the test, tests are always welcomed, especially for odd
edges like this.
-Sam
On Mon, Dec 1, 2008 at 8:08 PM, Dmitry Titov [EMAIL PROTECTED] wrote:
Hi webkit-dev,
I'm looking at JS timeout code and found a callback behavior that seems
strange. Not sure if it is intentional.
If timeout is set on a 'window' object from another frame and timeout
callback is specified as a JS string, it is executed inside the frame...
So the context of execution is different depending how the callback is
specified.
Here is html (also attached) that loads an empty IFRAME and sets 2 timeouts
on that iframe's window - as a JS closure and as JS string. In former case,
the callback runs in the main page (expected, since the JS closure
'captures' the context in which it is defined), in the latter- inside iframe
(a bit weird?). So the text goes in both body elements.
Is there a reason why JS string is evaluated in the inner context of the
iframe? Would a test verifying this behavior be a good thing? Curiously, IE
and FF behave the same way.
html
script
function test() {
// Get the iframe's window.
var iframeWindow = window.frames[testIframe];
// setTimeout with a closure as callback.
iframeWindow.setTimeout(
function() {
if (!document.body)
document.write('body/body');
document.body.appendChild(document.createTextNode('Timer 1
fired.'));}, 1);
// setTimeout with a JS string containing similar code.
iframeWindow.setTimeout(
if (!document.body) +
document.write('body/body'); +
document.body.appendChild(document.createTextNode('Timer 2
fired.'));, 1);
}
/script
body onLoad=test();
iframe src=about:blank id=testIframe/iframe
/body
/html
Thanks,
Dmitry
___
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] Licenses for WebKit contributions
I just noticed several patches have put up for review that contain new files using the Apache license. Current WebKit policy is that code should be licensed under either a BSD license or GNU Lesser General Public License v.2.1 (mentioned explicitly when submitting patches on bugs.webkit.org). In order to change this policy, we would need to have a larger discussion as this is not a decision that can be made by any one person. If you have submitted a patch recently that is under another license, please consider re-submitting it with either of the two allowed licenses as we cannot land them as they are. I am sorry we did not notice this sooner. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek j...@google.com wrote: I agree that this approach is powerful. However there are (not too frequent) situations when a port like Chromium wants to use both the WebKit implementation and its own implementation, switching in runtime. For workers, this happened with WorkerContextProxy/WorkerObjectProxy which are the interfaces that a worker object implements/uses. Since workers run in a separate process from the renderer, we use our own implementations of these interfaces that know about IPC etc. However once we're in the worker process, we want to run nested workers in the same process, in which case we want to use the WebKit implementation of these interfaces directly without using Chromium's. This doesn't seem like a runtime choice, but rather a use-time choice. In the main context, you want use one implementation and in the worker context, another one. This to me implies two different objects with different names. In non-multiprocess implementations of WebKit, these two objects could be the same object, and in multiprocess implementations (such as Chromium), they could be backed by different objects. This would not incur a runtime cost (and would be, subjectively of course, clearer). -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.com wrote: To give the list some insight into the discussions we've had with the Chrome UX folks: 1) We want to associate some set of enhanced permissions with a given origin (e.g. https://mail.yahoo.com), and we want the user to be presented with a single do you want to grant permissions to https://mail.yahoo.com; dialog, rather peppering the user with a bunch of individual permission dialogs for each feature (Yes, please allow mail.yahoo.com to use 100MB of local storage, Yes, allow mail.yahoo.com to display notifications, Yes, allow mail.yahoo.com to run in the background). It seems like a bad idea to give all or nothing trust, and not along the lines of how APIs have managed choices in the past (quotas are increased when the limit is hit). I am not even sure how a UA would present such a choice to a user in a meaningful manner. I think a workflow such as the one quoted above by Maciej is a good direction, that gives a user a better chance of understanding the choice they are making. 2) We want the timing of the permission grant UI to be under application control (as part of some kind of application user flow). So just visiting mail.yahoo.com would not suddenly popup an unexpected dialog - instead the application would have some UI along the lines of Turn on desktop notifications which would drive some app-specific UI flow, a part of which would involve the permission grant. Can you please elaborate on this, perhaps with a concrete example. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
On Tue, May 26, 2009 at 5:04 PM, Drew Wilson atwil...@google.com wrote: On Tue, May 26, 2009 at 4:43 PM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.com wrote: To give the list some insight into the discussions we've had with the Chrome UX folks: 1) We want to associate some set of enhanced permissions with a given origin (e.g. https://mail.yahoo.com), and we want the user to be presented with a single do you want to grant permissions to https://mail.yahoo.com; dialog, rather peppering the user with a bunch of individual permission dialogs for each feature (Yes, please allow mail.yahoo.com to use 100MB of local storage, Yes, allow mail.yahoo.com to display notifications, Yes, allow mail.yahoo.com to run in the background). It seems like a bad idea to give all or nothing trust, and not along the lines of how APIs have managed choices in the past (quotas are increased when the limit is hit). I am not even sure how a UA would present such a choice to a user in a meaningful manner. I think a workflow such as the one quoted above by Maciej is a good direction, that gives a user a better chance of understanding the choice they are making. I thought that maciej suggested the same thing we suggested - an explicit javascript API to request permissions. In our case, we want to ask for permissions in bulk up front, rather than peppering the user with permissions on an ad-hoc basis - in your example (prompting for more quota when the quota is hit) will break things like background sync in persistent workers, as the user may not be around when that background sync occurs. It is similar, but I am concerned with how to present a dialog to a user that states that by clicking grant they are completely trusting you. 2) We want the timing of the permission grant UI to be under application control (as part of some kind of application user flow). So just visiting mail.yahoo.com would not suddenly popup an unexpected dialog - instead the application would have some UI along the lines of Turn on desktop notifications which would drive some app-specific UI flow, a part of which would involve the permission grant. Can you please elaborate on this, perhaps with a concrete example. One example of a similar flow is Gmail Offline feature, where the user clicks on a Offline link, which drives the user through some app-controlled UI, culminating in a Gears permission-grant dialog. Here's another example: Remember The Milk rolls out a new feature: desktop reminder notifications. This is implemented by having a persistent worker which tracks changes on the server, determines when it's appropriate to display a reminder for a task, and displays a desktop notification. When a user logs into Remember The Milk, he sees a link: New feature: desktop reminders!. He clicks on this link, and is taken to an HTML page in Remember The Milk which describes what the feature is and asks the user if he wants to turn on these reminders. The application invokes getTrusted() to see if the domain is already trusted - if it isn't, then the UI may include some language to prepare the user for the upcoming permission grant dialog by telling him what to expect. When the user clicks yes, turn on this feature, the application calls requestTrust() - this brings up the UserAgent-specific permission grant dialog. When the user clicks the appropriate UI to grant this permission, then the application has the ability to create persistent workers and notifications (if we don't allow this kind of bulk permission grant, then the user is subjected to multiple dialogs for each feature - persistent workers and notifications - which is a crummy user experience). I would argue it is much more confusing to a user to have to grant complete trust (for some undetermined list of things to trust a origin with). Should that include geolocation data? I don't really want Remember The Milk to know where I am, does that mean I can't have notifications? How can a user make an informed decision? -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Notifications API
On Tue, May 26, 2009 at 9:18 PM, David Levin le...@chromium.org wrote: On Tue, May 26, 2009 at 8:57 PM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, May 26, 2009 at 5:04 PM, Drew Wilson atwil...@google.com wrote: On Tue, May 26, 2009 at 4:43 PM, Sam Weinig sam.wei...@gmail.comwrote: On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.comwrote: To give the list some insight into the discussions we've had with the Chrome UX folks: 1) We want to associate some set of enhanced permissions with a given origin (e.g. https://mail.yahoo.com), and we want the user to be presented with a single do you want to grant permissions to https://mail.yahoo.com; dialog, rather peppering the user with a bunch of individual permission dialogs for each feature (Yes, please allow mail.yahoo.com to use 100MB of local storage, Yes, allow mail.yahoo.com to display notifications, Yes, allow mail.yahoo.comto run in the background). It seems like a bad idea to give all or nothing trust, and not along the lines of how APIs have managed choices in the past (quotas are increased when the limit is hit). I am not even sure how a UA would present such a choice to a user in a meaningful manner. I think a workflow such as the one quoted above by Maciej is a good direction, that gives a user a better chance of understanding the choice they are making. I thought that maciej suggested the same thing we suggested - an explicit javascript API to request permissions. In our case, we want to ask for permissions in bulk up front, rather than peppering the user with permissions on an ad-hoc basis - in your example (prompting for more quota when the quota is hit) will break things like background sync in persistent workers, as the user may not be around when that background sync occurs. It is similar, but I am concerned with how to present a dialog to a user that states that by clicking grant they are completely trusting you. 2) We want the timing of the permission grant UI to be under application control (as part of some kind of application user flow). So just visiting mail.yahoo.com would not suddenly popup an unexpected dialog - instead the application would have some UI along the lines of Turn on desktop notifications which would drive some app-specific UI flow, a part of which would involve the permission grant. Can you please elaborate on this, perhaps with a concrete example. One example of a similar flow is Gmail Offline feature, where the user clicks on a Offline link, which drives the user through some app-controlled UI, culminating in a Gears permission-grant dialog. Here's another example: Remember The Milk rolls out a new feature: desktop reminder notifications. This is implemented by having a persistent worker which tracks changes on the server, determines when it's appropriate to display a reminder for a task, and displays a desktop notification. When a user logs into Remember The Milk, he sees a link: New feature: desktop reminders!. He clicks on this link, and is taken to an HTML page in Remember The Milk which describes what the feature is and asks the user if he wants to turn on these reminders. The application invokes getTrusted() to see if the domain is already trusted - if it isn't, then the UI may include some language to prepare the user for the upcoming permission grant dialog by telling him what to expect. When the user clicks yes, turn on this feature, the application calls requestTrust() - this brings up the UserAgent-specific permission grant dialog. When the user clicks the appropriate UI to grant this permission, then the application has the ability to create persistent workers and notifications (if we don't allow this kind of bulk permission grant, then the user is subjected to multiple dialogs for each feature - persistent workers and notifications - which is a crummy user experience). I would argue it is much more confusing to a user to have to grant complete trust (for some undetermined list of things to trust a origin with). Should that include geolocation data? I don't really want Remember The Milk to know where I am, does that mean I can't have notifications? How can a user make an informed decision? I'm not in the chrome ux discussion... but I'll add my 2 cents. If you think of the clients of webkit that expose it as a browser to third parties. Here's a few that come to mind. - Safari on OSX - Dashboard on OSX - Safari on iPhone - The browser on Andriod - Google Chrome When I think of Andriod, I know that installing apps gives me a list of permissions being requested. I would expect that any web item that wanted permissions would have to be similar on that platform. For iPhone, I don't know what the install looks like (sorry). For dashboard, it just asks if you want to install it. For chrome, it is tbd. It looks like there is a mix of models in this small
Re: [webkit-dev] Notifications API
I would prefer we limit the scope to notifications, since this is an experimental feature at the moment. Perhaps something along the lines of window.notifications.requestTrust(), or window.notifications.requestUse() (I am not a huge fan of either of those function names, but you get the general idea). We can always revisit this if this type of explicit privilege escalation becomes something other apis need as well. -Sam On Wed, May 27, 2009 at 9:22 AM, Drew Wilson atwil...@google.com wrote: Sam, I think you are right here. I'm convinced that applications should be specific about what permissions they are asking for. I also believe that from a UX standpoint, we will probably want to provide the user with a single dialog that enumerates the permissions being granted, although a given user-agent may want to do this differently. We certainly want to enable both models. So I'd like to propose an API like the following (cribbed from the Android permissions manifest): int getTrusted(permissionName) - returns 0 if the application is blocked/unsupported (user said no or user-agent does not support it), 1 if it is untrusted (no permissions grant yet), 2 if it is trusted void requestTrust(permissionArray, callback) This provides a couple of important things: 1) granularity, so an application can specify exactly what permissions it wants 2) flexibility for the user agent - the application asks for a block of permissions at once (for example, a given feature like background notifications may require two permissions: persistent workers and notifications). The user agent has the flexibility to decide whether to display this as one dialog enumerating permissions, two separate dialogs, a dialog which allows the user to pick and choose which permissions it wants to grant, etc. What do you think? -atw On Tue, May 26, 2009 at 9:49 PM, Sam Weinig sam.wei...@gmail.com wrote: On Tue, May 26, 2009 at 9:18 PM, David Levin le...@chromium.org wrote: On Tue, May 26, 2009 at 8:57 PM, Sam Weinig sam.wei...@gmail.comwrote: On Tue, May 26, 2009 at 5:04 PM, Drew Wilson atwil...@google.comwrote: On Tue, May 26, 2009 at 4:43 PM, Sam Weinig sam.wei...@gmail.comwrote: On Tue, May 26, 2009 at 4:20 PM, Drew Wilson atwil...@google.comwrote: To give the list some insight into the discussions we've had with the Chrome UX folks: 1) We want to associate some set of enhanced permissions with a given origin (e.g. https://mail.yahoo.com), and we want the user to be presented with a single do you want to grant permissions to https://mail.yahoo.com; dialog, rather peppering the user with a bunch of individual permission dialogs for each feature (Yes, please allow mail.yahoo.com to use 100MB of local storage, Yes, allow mail.yahoo.com to display notifications, Yes, allow mail.yahoo.comto run in the background). It seems like a bad idea to give all or nothing trust, and not along the lines of how APIs have managed choices in the past (quotas are increased when the limit is hit). I am not even sure how a UA would present such a choice to a user in a meaningful manner. I think a workflow such as the one quoted above by Maciej is a good direction, that gives a user a better chance of understanding the choice they are making. I thought that maciej suggested the same thing we suggested - an explicit javascript API to request permissions. In our case, we want to ask for permissions in bulk up front, rather than peppering the user with permissions on an ad-hoc basis - in your example (prompting for more quota when the quota is hit) will break things like background sync in persistent workers, as the user may not be around when that background sync occurs. It is similar, but I am concerned with how to present a dialog to a user that states that by clicking grant they are completely trusting you. 2) We want the timing of the permission grant UI to be under application control (as part of some kind of application user flow). So just visiting mail.yahoo.com would not suddenly popup an unexpected dialog - instead the application would have some UI along the lines of Turn on desktop notifications which would drive some app-specific UI flow, a part of which would involve the permission grant. Can you please elaborate on this, perhaps with a concrete example. One example of a similar flow is Gmail Offline feature, where the user clicks on a Offline link, which drives the user through some app-controlled UI, culminating in a Gears permission-grant dialog. Here's another example: Remember The Milk rolls out a new feature: desktop reminder notifications. This is implemented by having a persistent worker which tracks changes on the server, determines when it's appropriate to display a reminder for a task, and displays a desktop notification. When a user logs into Remember The Milk, he sees a link: New feature: desktop reminders!. He
Re: [webkit-dev] Security Origins
On Mon, Jun 1, 2009 at 3:50 PM, Jeremy Orlow jor...@chromium.org wrote: I have 2 questions about SecurityOrigins. First of all, in SecurityOrigin::databaseIdentifier() (in http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.h) the following comment appears: Serialize the security origin for storage in the database. This format is deprecated and should be used only for compatibility with old databases; use toString() and createFromString() instead. This was done in http://trac.webkit.org/changeset/32597 Despite the comments in the change log, I don't fully understand what the intention here is. DatabaseTracker and LocalStorage still use databaseIdentifier() which makes sense since, unless I'm totally missing something, the toString() format produces file names that are invalid on most file systems. At the same time, databaseIdentifier omits some of the logic found in toString (which might be the cause of bugs like https://bugs.webkit.org/show_bug.cgi?id=20701 ...I haven't confirmed yet). So, maybe instead of databaseIdentifier() being deprecated, it should be updated to be more like a toString that uses file system safe characters? It is deprecated in the sense that only Database code should use it. We can't make Database code use toString() because there are existing clients that depend on the identifier to remain the same. In addition, the creation of SecurityOrigin objects doesn't quite seem right. There are many places (like in DatabaseTracker) where security origins are created based on the file, port, and protocol. This is fine when all you're doing is .equals (which the HashMap's HashArg=SecurityOriginHash prarmeter does for you), but it seems like it could be inefficient (many SecurityOrigin objects describing the same origin) and could potentially lead to bugs (since not all of the properties are serialized during toString()/databaseIdentifier()). It's surprising to me that there isn't one central store of SecurityOrigin objects (maybe with weak references?) to eliminate the possibility of 2 SecurityOrigin objects describing the same origin. I suspect SecurityOrigins can be optimized, but as of yet they have not appeared on profiles. I would like to improve SecurityOrigins to better represent the concepts of effective script origin and origins representing resources more effectively. In general, I suppose I'm just trying to understand the thought behind SecurityOrigin objects and how they're used in the source code...because it doesn't seem very natural to me. SecurityOrigin was created to cleanup the way we do same-origin checks in the JavaScript bindings, and as such, carry some of that baggage (eg. domain relaxing). The main design constraint then was that it was a cheap compare for two origins representing the same document (pointer compare) as that is common case. The code evolved from there. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Changes to prepare-ChangeLog
While clearly a personal preference, I don't like the default prepare-changelog default text and would much rather we revert to the old one. I don't think the new text adds anything and will likely be ignored by most. Can we leave the --bug= option and revert to the old template? -Sam On Wed, Jul 1, 2009 at 10:44 PM, Eric Seidel e...@webkit.org wrote: Background: Reviewers spend too much time correcting errors which should be caught by tools. This is frustrating both to contributers and reviewers. One such class of errors are missing or incorrect information in ChangeLogs. I'm trying to fix that. As part of: http://trac.webkit.org/changeset/45464 prepare-ChangeLog now takes an optional --bug= argument and is able to fill in more than before: % prepare-ChangeLog --bug=26383 Running status to find changed, added, or removed files. Reviewing diff to determine which lines changed. Change author: Eric Seidel e...@webkit.org. Description from bug 26383: prepare-ChangeLog should have a --bug= argument and use it for url autofill. Editing the ../WebCore/ChangeLog file. Results in: 2009-07-01 Eric Seidel e...@webkit.org Reviewed by NOBODY (OOPS!). prepare-ChangeLog should have a --bug= argument and use it for url autofill https://bugs.webkit.org/show_bug.cgi?id=26383 DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE: http://webkit.org/coding/contributing.html FOR MORE INFORMATION Tests: fast/foo.html * foo.cpp: Added. Running prepare-ChangeLog by default will however output more boiler-plate: 2009-07-01 Eric Seidel e...@webkit.org Reviewed by NOBODY (OOPS!). SHORT DESCRIPTION/BUG TITLE GOES HERE (OOPS!) BUG URL GOES HERE (pass --bug= to autofill) DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE: http://webkit.org/coding/contributing.html FOR MORE INFORMATION LIST OF TESTS, OR EXPLANATION WHY TESTING IS IMPOSSIBLE GOES HERE (OOPS!) * foo.cpp: Added. However, hopefully the boilerplate is more helpful than before. Unfortunately everyone will now see: DETAILED DESCRIPTION OF THE CHANGES GOES HERE. (OOPS!) SEE: http://webkit.org/coding/contributing.html FOR MORE INFORMATION in their initial ChangeLogs. This may be annoying to seasoned contributers (and I'm open to removing it). But hopefully it will lead to better ChangeLogs overall. Looking forward to your comments! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Inheritance in IDL files/JS bindings
On Fri, Jul 3, 2009 at 2:42 PM, Drew Wilson atwil...@google.com wrote:
I'm working on refactoring some code out of WebCore::Worker into a common
base class to be shared between SharedWorker and Worker.
So I've defined a new AbstractWorker.idl and its associated JS bindings.
AbstractWorker is not intended to be instantiable, so I don't have a
constructor generated for it.
interface [CustomMarkFunction, Conditional=WORKERS] AbstractWorker {
...
}
GenerateConstructor is a slight misnomer unfortunately. Event
non-instatiatable interfaces should have one so that they can be exposed on
the global object for use with instanceof and accessing the prototype.
I then changed Worker.idl to make the Worker interface derive from the base
AbstractWorker interface, like so:
interface [CustomMarkFunction, Conditional=WORKERS] Worker :
AbstractWorker {
...
}
Everything compiles just fine, except that at runtime when I instantiate a
Worker object from Javascript, I seem to get an instance of AbstractWorker
instead, and referencing things that should be defined on the Worker
prototype (like Worker::postMessage) yields undefined. I thought at first
that perhaps I was doing something wrong with the prototype (setup in
JSWorkerConstructor.cpp) so I wrote some JS tests, which produced the
expected results:
log(Worker.toString()); = [object WorkerConstructor]
log(Worker.prototype.toString());= [object WorkerPrototype]
log(Worker.prototype.postMessage.toString()); = function
postMessage() { [native code] }
And yet when I actually instantiate a Worker object:
var worker = new Worker(resources/worker-common.js);
log (worker.toString());= [object *AbstractWorker*]
log (typeof worker.postMessage);= *undefined*
Is there anything special I need to do when implementing inheritance in IDL
files and JS bindings? I *think* I'm correctly following the example of
other places where we use inheritance (example HTMLElement - Element -
Node), although there are some options defined in the .idl file like
GenerateNativeConverter and GenerateToJS that might be relevant but
which I couldn't find any documentation for.
Anyhow, I'm digging into this further, but I figured people might be able
to shed some light on possible causes of this behavior.
It is hard to say without a full diff. Nothing you have described seems too
far off.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ExecState::thisObject()
On Mon, Jul 13, 2009 at 1:57 PM, Eric Seidel e...@webkit.org wrote:
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garengga...@apple.com wrote:
I'm not sure what you guys have been meaning by the phrase correct
heap.
Barring workers, all WebCore objects are allocated from the same heap.
We had wrongly assumed that each window got its own. OK. This
invalidates using heaps as a way to get back to a global object, thank
you.
If you want to pass an argument indicating where something should be
allocated, I don't think ExecState is the right place to do it. ExecState
is
a read-only pointer into the calling function's stack. It can answer
questions about the calling function's state, but that's it.
It's important for objects to be allocated with the right prototype
chain, otherwise we will have bugs, some of them security related. :)
Example:
A.html:
iframe name=B href=B.html
scriptB.doSomething();/script
B.html:
iframe name=C href=C.html
scriptfunction doSomething() { return C.contentDocument.body; }/script
C.html:
body
In this example:
A is the dynamicGlobalObject
B is the lexicalGlobalObject
but C is the current global object (the one that the
JSHTMLBodyElement) should be allocated in and from which the
JSHTMLBodyElement prototype chain should come from. All browsers get
variants of this idiom wrong in different places.
There are two was I can see to fix this:
1. Pass a current global object through to all toJS calls (lots of
callsites changed)
2. Store a current global object off of the ExecState (set by the
JS engine before leaving into custom native code for property lookup
or function execution).
I tried #1 this morning, and now think #2 is the cleaner way to go.
I'm very interested in your thoughts.
I discussed this a bit with Darin and Geoff, and we came to the conclusion
that the correct fix is to have each JS DOMObject store a JSGlobalObject
pointer and augment the toJS methods to pass a global object instead of an
ExecState (close to you #1). I would not advocate storing more data on the
ExecState.
The tricky part will be getting cases the edge cases such as events and
callbacks correct.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Coding Style: Clarify some cases with spacing
I believe it is quite well established that a space should not be allowed before a ; or , in such circumstances. (I have r-ed for it even ;) ). I think we should definitely explicitly call this out in the guidelines if it is not already. -Sam On Tue, Jul 21, 2009 at 4:05 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Hi there, In bug 27499 (https://bugs.webkit.org/show_bug.cgi?id=27499) it was pointed out that the coding style guide doesn't clarify whether it is allowed to place a space before a comma or semicolon in a control condition or in functions. Thus asking the question whether the three following code snippets are should be discouraged by the coding style guide or not: for (int i = 0 ; i 10 ; i++) doSomething(); // Qt's foreach foreach (QString item , items) doSomething(); f(a , b); Personally I would opt for discouraging this, which David Levin points out to be more or less the current project style. If we can agree on this, I can patch the coding style guide. Cheers, Kenneth ___ 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 Array types in IDL files?
Making this JS only for now seems fine. If we want to enable MessagePorts for other binding languages we can define the mapping ourselves. For example, for a sequence, the clear mapping for ObjC would be to NSArray*. -Sam On Wed, Aug 26, 2009 at 5:03 PM, Drew Wilson atwil...@google.com wrote: To be more precise, the HTML5 IDL defines the following: typedef sequenceMessagePort MessagePortArray; The types above are all MessagePortArray in the spec, not Array. So it seems like the intent is that they should indeed get mapped to a vanilla JS Array. I could make these attributes JS-only - that shouldn't be a huge issue since MessagePorts are currently only enabled for JS anyway (MessagePort is an empty interface for ObjC). Is that acceptable? Sam? -atw On Wed, Aug 26, 2009 at 12:34 AM, Cameron McCormack c...@mcc.id.au wrote: Maciej Stachowiak: We probably need special support for Web IDL array types in the bindings generator. Sam can probably comment n more detail. As a stopgap, we could make the relevant IDL attributes be JS only. I would check out what Web IDL says about Array - I don't think it's supposed to be reflected as just a vanilla JS Array. Currently Web IDL says that when getting an attribute of type sequenceT, a new JS Array object is returned. For array types, T[], a host object with particular [[Get]] and [[Put]] behaviour is meant to be used, which makes it similar to a native Array. Both of these things are pretty speculative, and could do with review. -- Cameron McCormack ≝ http://mcc.id.au/ ___ 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 Array types in IDL files?
On Wed, Aug 26, 2009 at 8:27 PM, Maciej Stachowiak m...@apple.com wrote: On Aug 26, 2009, at 9:26 AM, Sam Weinig wrote: Making this JS only for now seems fine. If we want to enable MessagePorts for other binding languages we can define the mapping ourselves. For example, for a sequence, the clear mapping for ObjC would be to NSArray*. I think ultimately we should support the sequence syntax in the bindings generator. Definitely. But like with most of these things, it is nice to see it mocked up first with custom code. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Passing data structures through postMessage()
On Thu, Sep 10, 2009 at 3:12 PM, Chris Campbell campb...@flock.com wrote:
Hi All,
I had it in mind to implement support for passing data structures
through postMessage() using the structured clone algorithm laid out
in the HTML5 spec:
http://dev.w3.org/html5/spec/Overview.html#posting-messages
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data
I've had some brief discussion with Dave Levin and Drew Wilson on
#chromium IRC about this, and have an approach in mind that follows
and elaborates on their suggestions, but there are still some holes in
it and I'd very much like input from people familiar with this area.
Currently, there are several postMessage() handlers (in
MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and
Worker.idl), and they all take a DOMString for the message parameter.
The general idea is to change that message parameter from a DOMString
to a new AttributeIterator type that allows walking of any sort of JS
structure/type. AttributeIterator would essentially be an adapter to
translate native V8 or JSC JavaScript objects to an agnostic interface
suitable for walking the structure and serializing it. I'm thinking
it would look something like this:
interface AttributeIterator {
bool isUndefined();
bool isNull();
bool isFalse();
bool isTrue();
bool isNumber();
String getNumber();
bool isString();
// ... cover the other types including Date, RegExp, ImageData,
// File, FileData, and FileList ...
// Retrieve the key for the next property (for Objects and Arrays)
String nextEnumerableProperty();
AttributeIterator getPropertyValue(key);
}
I'm also thinking that depending on compile-time flags, the
contstructor for AttributeIterator would either take a
v8::Handlev8::Value or JSC::JSvalue value.
Then in each implementation of postMessage() the AttributeIterator
instance could be passed to the structured clone serializer, which
would return a string. Thereafter, no changes would be required to
WebCore internals since they already pass strings around... until on
the receiving end we get to MessageEvent.data where we would do the
deserialization in a custom getter.
Open questions:
(1) Is passing an AttributeIterator type into postMessage() really the
best way to go? Drew mentioned that this might incur a bunch of ObjC
binding work on the JSC side...
(2) Where should AttributeIterator live in the source tree?
(3) Where should the serialization and deserialization routines live
in the source tree?
(3) I haven't addressed the specifics of the serialized string format.
Plain JSON is not quite sufficient since it doesn't retain type
information for Date, RegExp, etc.. However, I'm not too worried
about coming up with a suitable format for this.
Comments, advice, admonitions welcome! :)
Regards,
--Chris
It should not be necessary to serialize to a string just to pass the
structured clones across thread boundaries. This would be an especially bad
idea for things like CanvasPixelArray. I am also not sure I understand the
name AttributeIterator.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Passing data structures through postMessage()
On Thu, Sep 10, 2009 at 3:55 PM, Drew Wilson atwil...@google.com wrote: The other approach we discussed was leaving the postMessage() APIs in WebCore as they are (taking a DOMString parameter) and doing the serialization/de-serialization in the JS bindings instead. My one concern about building the serialization into the WebCore postMessage impls is I didn't quite understand how that would map to ObjC (although for ObjC we could just continue exposing only postMessage(DOMString) and have the ObjC bindings wrap the string in an attributeIterator). For the time being, ObjC can be ignored as basic concepts like RegExp are not defined in that context. ObjC can continue living with the old style postMessage and be happy doing so :). -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Point 3 of the WebKit Style Guidelines (indenting code inside namespaces in headers)
I also think this change is the right way to go. r=me. On Tue, Sep 22, 2009 at 1:20 PM, Brady Eidson beid...@apple.com wrote: I've always hated the indentation in header files. I have no objections. ~Brady On Sep 22, 2009, at 1:06 PM, David Hyatt wrote: I had thought that we resolved ages ago that we would no longer be indenting code inside namespaces in header files, since that just results in the entire class declaration being pointlessly indented. This is point 3 on the page: http://webkit.org/coding/coding-style.html I'd like to reverse the Right and Wrong examples to fix this. Are there any objections to this change? I know a few months ago, people agreed (notably Maciej) that there was no longer any point to essentially indenting the entire file's contents (when we already don't do this in .cpp files). dave (hy...@apple.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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScript question: how to find out the position of a tooltip relative to the document body in a zoomed and scrolled page
This is a question that is better suited for webkit-help. This list is for the discussion of the development of webkit. -Sam On Mon, Oct 5, 2009 at 4:37 PM, Xiaomei Ji x...@chromium.org wrote: I am trying to display a tooltip under the mouse when mouse stays at a position long enough. I am using absolute positioning, set the tooltip as the child of the document.body, and set the style.left and style.top as event.clientX + document.body.scrollLeft and event.clientY + documentbody.scrollTop. Following is the related code: tooltip.style.position = absolute; var x = event.clientX + document.body.scrollLeft; var y = event.clientY + document.body.scrollTop; tooltip.style.left = x + px; tooltip.style.top = y + px; document.body.appendChild(tooltip); But it does not work in a scrolled and zoomed page. (works fine in a scrolled page without zooming or zoomed page without scrolling). I think the (x, y) need to be adjusted by pageZoomFactor. But I did not find pageZoomFactor is exposed through JS. I tried to change the position to be fixed and hide the tooltip onMouseWheel/onMouseDown/onKeyDown event to comprise fixed element does not scroll with the rest of the document, but I still could not find the right position value for the tooltip in case of scolled and zoomed page. Anyone has any idea how should I position the tooltip correctly in JS? Does pageZoomFactor has to be exposed in JS to make it work? Thanks, Xiaomei ___ 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] Runtime setting for incomplete features
Hi Folks, I am not happy with the way these runtime settings have been implemented so far as they break runtime detection using the technique we evangelize to developers, specifically, using the (property in window) method. A feature that is turned off at runtime should not be detectable at all, using any method (including Object.keys(), object.hasOwnProperty(), object.propertyIsEnumerable(), for-in enumeration, etc). I filed https://bugs.webkit.org/show_bug.cgi?id=29896 when the WebSocket runtime switching code went in and was disappointed to see similarly buggy code go in for SharedWorkers with out this being fixed. Leaving this in the tree is likely to introduce compatibility issues so I would recommend that we roll out these changes if they cannot be fixed in a timely manner. -Sam On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisher da...@chromium.org wrote: As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for the Chromium project, we like to make incomplete features available behind a command line flag to help facilitate testing. I understand that the norm for WebKit is to only have compile time options for new / incomplete features. In some cases, runtime settings are defined, but these generally correspond to end user preferences or the needs of specific embedders. At any rate, I just wanted to make sure that folks were aware that some settings may only exist to help facilitate Chromium's goal of shipping incomplete features, disabled by default. Alexey asked if there are any guidelines for when these settings may be removed. I think the main thing is that the feature has to be reasonably complete and enabled by default by embedders (e.g., Chromium) that are compiling the feature. Regards, -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] Runtime setting for incomplete features
I don't think I wrote the Audio code, (I think I probably just moved it), but I also don't believe it is intended as a general purpose runtime switch (but rather fallback when there are no installed codecs). It is also not something people are going to ship as far as I can tell, and is therefore a much smaller compatibility risk. -Sam On Mon, Oct 5, 2009 at 5:54 PM, Drew Wilson atwil...@google.com wrote: BTW, I modeled my SharedWorker disabling after the code in JSDOMWindowCustom::audio() that disables the audio constructor on platforms that don't have MediaPlayer support. I think the runtime behavior of window.audio and window.SharedWorker should be identical in practice. Sam, it looks like you wrote JSDOMWindowCustom::audio() - do you see its behavior as unacceptable as well, or do you have some other code to prevent enumeration of window.audio that I can generalize for use for SharedWorkers too? -atw On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote: So, two weeks ago I sent an email on this thread stating exactly what I was planning to do, To whit: I do think that we ought to be returning undefined instead of null in those cases, though, just to catch people who are accidentally using isUndefined() utility functions from common libraries. It would not be hard to define some kind of [mapNullToUndefined] custom attribute for the code generator. Maciej and AP both chimed in saying that disabling enumeration (i.e. SharedWorker in window) would be prohibitively hard, and giving a tacit OK to my approach (my emphasis below): It would be pretty complicated to do that [disabling [LocalStorage in window] based on a runtime setting. You would need a custom getter for any object that has properties which may appear or disappear based on settings. This is *probably too complicated to be worth it*. Or at least, if we added that level of code complexity I would begin to doubt the merits of supporting runtime enabling of Web platform features. I'm surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. That said, I agree that in an ideal world, we'd hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn't a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway. Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets - if we feel strongly that this needs to be addressed, we can update all of those features accordingly. If people with knowledge of the internals of V8 and JSC can chime in, we can discuss how best to approach this. -atw On Mon, Oct 5, 2009 at 5:04 PM, Sam Weinig sam.wei...@gmail.com wrote: Hi Folks, I am not happy with the way these runtime settings have been implemented so far as they break runtime detection using the technique we evangelize to developers, specifically, using the (property in window) method. A feature that is turned off at runtime should not be detectable at all, using any method (including Object.keys(), object.hasOwnProperty(), object.propertyIsEnumerable(), for-in enumeration, etc). I filed https://bugs.webkit.org/show_bug.cgi?id=29896 when the WebSocket runtime switching code went in and was disappointed to see similarly buggy code go in for SharedWorkers with out this being fixed. Leaving this in the tree is likely to introduce compatibility issues so I would recommend that we roll out these changes if they cannot be fixed in a timely manner. -Sam On Tue, Sep 8, 2009 at 11:47 PM, Darin Fisher da...@chromium.orgwrote: As is described in https://bugs.webkit.org/show_bug.cgi?id=28941, for the Chromium project, we like to make incomplete features available behind a command line flag to help facilitate testing. I understand that the norm for WebKit is to only have compile time options for new / incomplete features. In some cases, runtime settings are defined, but these generally correspond to end user preferences or the needs of specific embedders. At any rate, I just wanted to make sure that folks were aware that some settings may only exist to help facilitate Chromium's goal of shipping incomplete features, disabled by default. Alexey asked if there are any guidelines for when these settings may be removed. I think the main thing is that the feature has to be reasonably complete and enabled by default by embedders (e.g., Chromium) that are compiling the feature. Regards, -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote: I'm surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. Sorry, I seemed to have missed that thread. I did however file a bug as soon as the first runtime switch went in. That said, I agree that in an ideal world, we'd hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn't a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway. I obviously disagree with Maciej on this. I think it is bad to break developers expectations for feature detection. Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets I don't mean to single out SharedWorkers or WebSockets, but I don't see any others using the same technique (barring window.Audio, which I don't think is the same thing, but should non-the less be fixed). But, as we have many developers using the nightlies, I think this should be handled with some speed. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
On Mon, Oct 5, 2009 at 6:33 PM, Drew Wilson atwil...@google.com wrote: On Mon, Oct 5, 2009 at 6:20 PM, Sam Weinig sam.wei...@gmail.com wrote: On Mon, Oct 5, 2009 at 5:46 PM, Drew Wilson atwil...@google.com wrote: I'm surprised to see these objections coming up now, weeks after the original discussion, and only after my patch has landed in the tree. Sorry, I seemed to have missed that thread. I did however file a bug as soon as the first runtime switch went in. That said, I agree that in an ideal world, we'd hide window.audio, shared workers, notifications, local storage, databases, session storage and any other runtime/platform-disabled API from enumerations - I just agree with Maciej that this isn't a hugely important issue, since these features are only runtime-disabled while under development and so not widely available anyway. I obviously disagree with Maciej on this. I think it is bad to break developers expectations for feature detection. OK, it's good to get consensus, even if it comes after I already thought we had achieved it :) From a purist's perspective, I see where you're coming from. Pragmatically, though, these runtime flags are only available on the Chrome dev channel (and go away before the features are ever shipped to the beta/stable channels) so the compatibility issues are somewhat moot. We've discussed removing these feature flags (and the ability to disable the features at runtime) once the features become stable - I don't know if that's a good idea or not, but that might impact this discussion as well. That is not true, they are also available in nightly builds at http://nightly.webkit.org/. Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets I don't mean to single out SharedWorkers or WebSockets, but I don't see any others using the same technique (barring window.Audio, which I don't think is the same thing, but should non-the less be fixed). But, as we have many developers using the nightlies, I think this should be handled with some speed. Take a look at DOMWindow.cpp - there's quite a bit of code that does something like look at settings to see if feature is enabled, return null if not (DOMWindow::openDatabase(), for an example). This is indeed unfortunate, but also is a step removed, since it does not really effect feature detection, it is also not a shipping configuration. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
On Mon, Oct 5, 2009 at 7:50 PM, Drew Wilson atwil...@google.com wrote: Ooops, meant to reply to all. On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson atwil...@google.com wrote: On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig sam.wei...@gmail.com wrote: That is not true, they are also available in nightly builds at http://nightly.webkit.org/. I'm not sure what you mean, exactly - the nightly webkit builds all have SharedWorkers turned on, with no way to turn them off short of editing the source code and recompiling (since the only existing implementation of SharedWorkerRepository.isAvailable() returns true). I suspect I'm missing something obvious, though - can you elaborate? My expectation was that only when I write the Chromium implementation of SharedWorkerRepository will isAvailable() ever return false - so this only affects Chromium deployments. Ok, but this is not the case for WebSockets. Regardless, I don't think we should rush out to roll all of those features out of the tree, and I certainly don't think we should be singling out SharedWorkers or WebSockets I don't mean to single out SharedWorkers or WebSockets, but I don't see any others using the same technique (barring window.Audio, which I don't think is the same thing, but should non-the less be fixed). But, as we have many developers using the nightlies, I think this should be handled with some speed. Take a look at DOMWindow.cpp - there's quite a bit of code that does something like look at settings to see if feature is enabled, return null if not (DOMWindow::openDatabase(), for an example). This is indeed unfortunate, but also is a step removed, since it does not really effect feature detection, it is also not a shipping configuration. Why doesn't it affect feature detection? Someone can do if localStorage in window, yet have their code fail when window.localStorage is null? I only looked at window.openDatabase(), since that is what you called out. Again, this is unfortunate and should be rectified, but it does not represent a real concern in my mind, since I don't know of any shipping webkit based browsers that ship with this configuration on or an accessible preference to get this way. The good news is that it looks like we can fix this for nightlies by enabling the WebSocket runtime switch. I would still very much like a good solution to runtime enabling/disabling features in the bindings as I think this would be a useful addition to the webkit arsenal and I am curious why it is thought that doing it right will be prohibitively expensive (it may very well be, I just don't know why that is). -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: Point 3 of the WebKit Style Guidelines (indenting code inside namespaces in headers)
On Wed, Oct 7, 2009 at 10:02 PM, Eric Seidel e...@webkit.org wrote: Now from the right email address... -- Forwarded message -- From: Eric Seidel esei...@google.com Date: Thu, Oct 8, 2009 at 1:02 AM Subject: Re: [webkit-dev] Point 3 of the WebKit Style Guidelines (indenting code inside namespaces in headers) To: David Levin le...@google.com Cc: Maciej Stachowiak m...@apple.com, webkit-dev Development webkit-dev@lists.webkit.org Did we ever come to resolve about this issue? Can we turn it into bugs if that's the case? Or do we need a vote? :) No need to vote (we don't vote on such things). Someone just needs to put the change up for review. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Landing your own patches
Hi WebKit Developers, As nice as it may be to have a bot landing your patches, I think developers who have a commit bit should try and make the effort to land their own patches. Mainly I think this is a good idea since the creator of the patch has a much better chance of fixing the issue or quickly rolling it out if they have to consciously commit and watch the bots. It also, and perhaps more importantly, places a lesser burden on the community who ends up doing this job for them. I understand the concern of those working on Windows who don't necessarily have access to a Mac and I applaud your fear of breaking the build, but I think in the end you are using the wrong tool (admittedly due to a lack of trybots, but the commit bot will not run Qt or Gtk) and you are using it too much (most patches probably won't break a build, unless you are named Dave Hyatt). Thanks, -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
Hi Dmitry, As I have noted to others on the Chrome team, I do not think this is good idea and I don't think we should have it in WebKit. It adds extra complexity to WebKit and gives little beyond what is possible using inter-window communication and SharedWorkers. I think we need to give more time for large applications to adopt designs around workers before we reverse course, at which point, we should again discuss this in the standards community. -Sam On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov dim...@chromium.org wrote: Hi webkit! I'm starting to work on actual implementation of GlobalScript experimental API http://docs.google.com/View?id=dxv3cth_2rnj9wffz and started to post patches (hopefully in reviewable portions). There is an uber-bughttps://bugs.webkit.org/show_bug.cgi?id=31317which has plan of implementation. The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC and v8 bindings (first with JSC because at the moment JSC bindings are easier to work with and I'd wish WebKit not to have 1-engine-only features ever). I'd be glad to know if there are suggestions, ideas or concerns of any kind... For example, if there is no interest in JSC bindings, it can be hard to get them reviewed by someone who knows them well. It'd be better to know that earlier. Thanks! Dmitry ___ 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] Proposing style guide change regarding braces on conditional arms
On Wed, Dec 2, 2009 at 9:57 PM, Dan Bernstein m...@apple.com wrote: On Dec 2, 2009, at 9:46 PM, Peter Kasting wrote: On Wed, Dec 2, 2009 at 9:19 PM, Mark Rowe mr...@apple.com wrote: On 2009-12-02, at 21:00, Peter Kasting wrote: I find this tricky to read and error-prone. I propose that the rule be modified to be: * When all arms of a conditional or loop are one physical line, do not use braces. If any arms are more than one physical line (even if they are one logical line), use braces on all arms. I do not agree that this would be an improvement. Are you satisfied with the existing rule, then? If so, you would be the first developer I have asked who is. I am satisfied with the existing rule. Me too. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SVG Filters
Generally, we don't run fuzz testing suites with the rest of the regression tests due to the length of time they take to run, but rather run them periodically (for instance, before releases), fixing any issues they that show up. Fuzz tests tend to cover much more ground at the cost of a longer run time. -Sam On Sun, Dec 6, 2009 at 3:00 PM, Dirk Schulze vb...@gmx.de wrote: Hi Maciej and Darin, you both suggested to add fuzz tests for SVG Filters. I looked at the fuzz test LayoutTest/svg/dom/fuzz-path-parser.html. As an analogy to this test, I would suggest an array with the effects to test, it's number of inputs and attributes, that can't be randomly set. But the basic question is, what should the fuzz test test? The combination of different effects? Should every filter effect have it's own fuzz test with a default input? Different sizes of effects? We need to keep in mind, that LayoutTests will slow down, as more comlpex the fuzz tests get. Regards, Dirk Am Freitag, den 04.12.2009, 11:06 -0800 schrieb Maciej Stachowiak: On Dec 4, 2009, at 11:02 AM, Dirk Schulze wrote: What kinds of tests do we have for the code already? Do we have code that tries to exercise edge cases? Do we have a fuzzer of some sort? -- Darin Every effect that was implemented has at least one test. They are mostly simple test cases that just test one effect at once but there are also more complex tests, to see the behavior on combining different effects. I try to address the different edge cases of every filter effect and add more tests if necessary. Mainly effects with pixel manipulation already have more than one test to target different edge cases. I think the feature is ready to be enabled by default. One thing that would strongly increase my confidence in actually shipping it would be some form of fuzz testing. Design review by security experts would also help, but that is hard to arrange. Whereas anyone can write a fuzz tester. 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] test scripts
I would prefer we stick with the run prefix. I am also not sure why we would have separate testing scripts based by language. I think it would make a lot more sense to base the scripts on what they were testing as is currently done (run-webkit-tests tests webkit, run-javascriptcore-tests tests javascriptcore), so a script to bugzilla tool would be called run-bugzillatool-tests. If the number of these scripts got out of hand, we could always add a run-all-tests scripts which ran them all. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Calling JavaScript function from within DumpRenderTree
On Fri, Jan 1, 2010 at 7:13 PM, Chris Fleizach cfleiz...@apple.com wrote:
I need to have a layout test register a callback with DRT, then have that
callback be called at the appropriate time (in order to test accessibility
notifications)
I can't figure out the right incantations to do so.
I'd like to do something like this in the LayoutTest
var addedNotification = liveRegion.addNotificationListener(ariaCallback);
then have a function in the test like
function ariaCallback(notification) {
// do stuff with notification
}
DRT knows when to call this method, but I'm not sure how.. This is what I
have so far, which does not work.
// The JavaScript callback we'll use when we get a notification
static JSStringRef AXNotificationFunctionCallback = 0;
static void _accessibilityNotificationCallback(id element, NSString*
notification)
{
if (!AXNotificationFunctionCallback)
return;
JSObjectRef function = JSObjectMakeFunction([mainFrame globalContext],
NULL, 0, NULL, AXNotificationFunctionCallback, NULL, 1, NULL);
JSValueRef argument = JSValueMakeString([mainFrame globalContext],
JSStringCreateWithCFString((CFStringRef)notification));
JSObjectCallAsFunction([mainFrame globalContext], function, NULL, 1,
argument, NULL);
}
What you need to do is lookup the function object on the global object. Your
function would look more like:
static void _accessibilityNotificationCallback(id element, NSString*
notification)
{
if (!AXNotificationFunctionCallback)
return;
JSValueRef functionValue = JSObjectGetProperty([mainFrame
globalContext], JSContextGetGlobalObject([mainFrame globalContext]),
AXNotificationFunctionCallback, NULL);
if (!JSValueIsObject(functionValue))
return;
JSObjectRef functionObject = static_castJSObjectRef(functionValue);
JSValueRef argument = JSValueMakeString([mainFrame globalContext],
JSStringCreateWithCFString((CFStringRef)notification));
JSObjectCallAsFunction([mainFrame globalContext], function, NULL, 1,
argument, NULL);
}
(You probably would want to add some more exception checks).
That said, a more javascripty way to do this would be to pass the function
object to liveRegion.addNotificationListener itself. That way, in the test
file, you would have,
liveRegion.addNotificationListener(function(notification) {
// do stuff with notification
});
In the implementation of addNotificationListener, you would save the
function object off instead of saving off the string, and then call it in
_accessibilityNotificationCallback.
-Sam
___
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, Feb 23, 2010 at 12:58 PM, Dirk Schulze vb...@gmx.de wrote: Am Dienstag, den 23.02.2010, 08:34 -0800 schrieb Simon Fraser: It could be an image, or it could be a configuration of div elements, or a table, or something else that can be configured to look exactly the same as the CSS border property being tested. Simon I like the idea of reftests. But how do we write tests for box-shadows, gradients or patterns on a text (like in SVG)? All basic graphical elements would still need pixel-tests, or do you have another idea? 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. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] minimum python version to support
I am not sure why we would make a distinction between development tools and and supported platforms. Any scripts checked in need to run on Tiger. If we need to fix a Tiger bug, we boot up Tiger and develop there. -Sam On Wed, Mar 3, 2010 at 3:47 PM, David Levin le...@chromium.org wrote: I think it depends on the tool. Since tiger is still supported by webkit (it is in the buildbot), then any script that run during the build or running layout tests would need to run on python 2.3.5. (The version that shipped with Tiger.) Some development still happens on Leopard (I think), so it seems like general development tools should support python 2.5.1. dave On Wed, Mar 3, 2010 at 3:27 PM, Chris Jerdonek cjerdo...@webkit.orgwrote: Recently, there has been some off-list discussion about the minimum Python version WebKit should support (i.e. for the Python scripts in WebKitTools/Scripts). Up to this point, we haven't been explicit about it. This ambiguity has occasionally caused things to break for people using versions before Python 2.6. It seems pretty clear that we at least want to support Python 2.5. The question that still remains is how many people are using Python 2.4, and whether Python 2.4 is worth supporting. This thread collects a lot of the discussion: https://bugs.webkit.org/show_bug.cgi?id=35584 Does anyone want us to support Python 2.4, or are people okay with Python 2.5? 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] WebKit Icon license?
And our own http://planet.webkit.org/. -Sam On Mon, Mar 22, 2010 at 3:11 PM, Chris Jerdonek cjerdo...@webkit.orgwrote: 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
Re: [webkit-dev] upgrading sqlite library
The version in the OpenSource tree does not match what we ship on Mac OS X or Windows as part of Safari. We are going to update it to the same version that is used by Snow Leopard (version 3.6.12) shortly. Thanks for bringing this to our attention. - Sam On Thu, Mar 25, 2010 at 5:34 PM, Dumitru Daniliuc d...@chromium.org wrote: hi, i have a few questions about the sqlite library that webkit uses: 1. what version is it? 2. is there any reason why we cannot upgrade it? 3. what would it take to upgrade it? is there a standard process that i could go through? it seems to me that webkit's sqlite library has some bugs that were fixed in a later version (a HTML5 DB test fails 100% of the time in safari and DRT, but passes 100% of the time in chromium and as a standalone program linked directly to sqlite 3.4.2), so i would like to build a newer library and see if that fixes the problem in safari and DRT; and if it does, push it to webkit. thanks, dumi ___ 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] upgrading sqlite library
We are now updated to version 3.6.12 as of http://trac.webkit.org/changeset/56607. -Sam On Thu, Mar 25, 2010 at 6:39 PM, Sam Weinig sam.wei...@gmail.com wrote: The version in the OpenSource tree does not match what we ship on Mac OS X or Windows as part of Safari. We are going to update it to the same version that is used by Snow Leopard (version 3.6.12) shortly. Thanks for bringing this to our attention. - Sam On Thu, Mar 25, 2010 at 5:34 PM, Dumitru Daniliuc d...@chromium.orgwrote: hi, i have a few questions about the sqlite library that webkit uses: 1. what version is it? 2. is there any reason why we cannot upgrade it? 3. what would it take to upgrade it? is there a standard process that i could go through? it seems to me that webkit's sqlite library has some bugs that were fixed in a later version (a HTML5 DB test fails 100% of the time in safari and DRT, but passes 100% of the time in chromium and as a standalone program linked directly to sqlite 3.4.2), so i would like to build a newer library and see if that fixes the problem in safari and DRT; and if it does, push it to webkit. thanks, dumi ___ 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] upgrading sqlite library
In fairness to Mark Rowe, he did the work. On Fri, Mar 26, 2010 at 12:32 PM, Dumitru Daniliuc d...@chromium.orgwrote: it's a new test that i haven't submitted yet. sam: thanks for upgrading sqlite. i'm running that test right now. dumi On Fri, Mar 26, 2010 at 9:43 AM, Brady Eidson beid...@apple.com wrote: On Mar 25, 2010, at 5:34 PM, Dumitru Daniliuc wrote: (a HTML5 DB test fails 100% of the time in safari and DRT, but passes 100% of the time in chromium and as a standalone program linked directly to sqlite 3.4.2) What is the bugzilla for this? A test that should pass but fails 100% of the time in mainline WebKit is something we should be tracking to fix. ~Brady ___ 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] Determining platform in LayoutTests
I am not sure which tests you are referring to that use the user-agent to change behavior, but that is not the way it is supposed to be done. Instead, tests that test a platform specific behavior should go in the LayoutTest/YOURPLATFORM directory. If it is just a platform specific result, the results should go in LayoutTest/YOURPLATFORM. -Sam On Sun, Mar 28, 2010 at 1:11 PM, Martin Robinson mrobin...@webkit.orgwrote: Apologies in advance if this has been hashed out before, but a cursory search of the list history didn't turn anything up. It seems that in LayoutTests platform specific behavior is generally handled by examining the user agent. I'm currently in the process of fixing editing/selection/extend-selection-after-double-click.html for GTK+. This test will have different results for GTK+ and Qt (it's currently skipped on both) because the selection behavior is different between the toolkits. This will become even more of an issue as we try to bring selection behavior in line with standard GTK+ behavior (see bug https://bugs.webkit.org/show_bug.cgi?id=36627 ). I'm not sure that you can tell Qt and GTK+ apart via the user agent, so does it make sense for LayoutTestController to expose this information somehow or just fix the user agent? Is there an alternative? Martin ___ 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] Determining platform in LayoutTests
On Sun, Mar 28, 2010 at 7:14 PM, Dan Bernstein m...@apple.com wrote: On Mar 28, 2010, at 7:08 PM, Sam Weinig wrote: I am not sure which tests you are referring to that use the user-agent to change behavior, but that is not the way it is supposed to be done. Instead, tests that test a platform specific behavior should go in the LayoutTest/YOURPLATFORM directory. If it is just a platform specific result, the results should go in LayoutTest/YOURPLATFORM. This works for some tests, but is not ideal for tests that encode expected behavior (in particular, “script tests”) and output some sort of PASS/FAIL result. In such cases, unless the test has a way to adapt to platform conventions, FAIL could end up being the platform-specific result for some platforms, which isn’t so great. In these case, we should do the first option I gave, and have different tests. This is not an ideal solution, for sure, but I think it is better and adding branches to the tests themselves. One alternative, where applicable, is to make the behavior a runtime setting, and thus enable testing it on all platforms. Performance could get in the way of this. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Thu, Apr 8, 2010 at 4:25 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Apr 8, 2010 at 3:01 PM, Anders Carlsson ander...@apple.com wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Please, please consider making every call non-block, particularly those that requires interaction with user, avoiding nested main loops and bugs that come from these[1]. For instance, these could call user that is later responsible to call another function, providing the continuation based on some shared token/context. As noted in the linked Wiki document, the intent is to create a completely non-blocking API. That is one of our biggest motivations in pursuing this project. - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Wed, Apr 28, 2010 at 7:10 AM, Nayan naya...@gmail.com wrote: Hi, What's the status of Webkit2? I've built the latest webkit version on Windows with --webkit2 option and I see that there is only one process shown in Task Manager irrespective of the number of Windows that I open. Reagrds, Nayan. On Windows, the only way to build it right now is from within WebKit2.sln. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Python on the Tiger build bot
This was my understanding as well. -Sam On Thu, May 6, 2010 at 9:54 PM, Alexey Proskuryakov a...@webkit.org wrote: I thought the agreement was that essential tools shouldn't add more requirements on the installed tools. Is it not the case? - WBR, Alexey Proskuryakov 06.05.2010, в 21:30, Eric Seidel написал(а): WebKitTools/Scripts/webkitpy python requires 2.5+. We'd like to be able to use python 2.5 on the Tiger build bot (for websocket tests among other things). Would someone be able to install a newer Tiger on that machine? Here is python 2.6.5 for the mac: http://www.python.org/ftp/python/2.6.5/python-2.6.5-macosx10.3-2010-03-24.dmg Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Directory upload experimental feature
I think this is only true for Mac OS X style bundles, not all folders. On Wed, Jun 2, 2010 at 3:44 AM, David Kilzer ddkil...@webkit.org wrote: Other alternatives? I believe Safari will zip a folder and send it as a single file for you if you attach a folder to a file upload element instead of an individual file. Dave -- *From:* John Gregg john...@google.com *To:* Sam Weinig sam.wei...@gmail.com *Cc:* webkit-dev@lists.webkit.org *Sent:* Tue, June 1, 2010 3:09:00 PM *Subject:* Re: [webkit-dev] Directory upload experimental feature My proposal for that is that all the files would be listed in the form submission the same way as if it were a input type=file multiple, but in the Content-Disposition header, the filename component would contain the path information. One alternative idea would be add a path component to the Content-Disposition header alongside the filename which remains unchanged, but I think that would be a much more difficult approach. Other alternatives? Example follows. -John If you are have these files /home/John/photos/vacation/1.jpeg /home/John/photos/vacation/2.jpeg /home/John/photos/conference/1.jpeg and choose photos from the directory picker, you'd end up with input.files[0].name = 1.jpeg input.files[0].path = photos/vacation/1.jpeg input.files[1].name = 2.jpeg input.files[1].path = photos/vacation/2.jpeg input.files[2].name = 1.jpeg input.files[2].path = photos/conference/1.jpeg Your POST would look like Content-type: multipart/form-data; boundary=WebKitFormBoundaryFoo WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/vacation/1.jpeg Content-Type: image/jpeg contents WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/vacation/2.jpeg Content-Type: image/jpeg contents WebKitFormBoundaryFoo Content-Disposition: form-data; name=input; filename=photos/conference/1.jpeg Content-Type: image/jpeg contents On Sat, May 29, 2010 at 10:22 AM, Sam Weinig sam.wei...@gmail.com wrote: How will the directory structure and all the files therein be represented in the form submission? -Sam On Fri, May 28, 2010 at 3:17 PM, John Gregg john...@google.com wrote: Hi WebKit, I recently proposed adding directory upload support to HTML via a new input attribute to whatwg@, and the discussion arrived at try it out. Having written some code I think I have something that works pretty well, and I'd like to land it on an experimental basis in WebKit, but want to reach out early before trying to put any code in the tree. The plan that comes to mind is a new ENABLE_DIRECTORY_UPLOAD flag, but I'm completely open to other options. Background (cf. the whatwg thread http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-April/025764.html ): - The use case for this is a photo album or file manager web application, which wants the user to easily choose an entire directory to recursively upload, while preserving the sub-directory structure. - The reason for the new attribute is to signal the UA to show a native folder-picker rather than a file-picker, which on most OSs are two distinct dialogs. The approach I'm using has 2 parts and is a small amount of WebCore code (about 200 lines). - Extend HTMLInputElement to support the directory attribute, which is passed up via FileChooser allowing the UA to display a folder-picker. UA enumerates all the files and returns them in the normal way. - Extend File to have a File.path property, which contains the path information starting from the chosen directory as the root. HTMLInputElement is responsible for generating these values from the list of files when the directory attribute is set. Thoughts? Thanks, -John ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
Now that I have had a little time to think about it, I think my biggest concern with this type of API is the unintentional ability for an attacker to gain information from the engine consuming specifics amount of memory. Let's take the visited link history stealing attack as an example. Even though you can no longer use getComputedStyle() directly to gain information as to whether a link was visited or not, if the engine allocated subtly different amounts of memory depending on whether the link was visited or not, an attacker could detect this and gain that information. Adam (and other web security people), am I being overly paranoid about this? -Sam On Fri, May 28, 2010 at 10:56 AM, Mikhail Naganov mnaga...@chromium.orgwrote: Greetings, WebKit deveopers, As a response to requests from web apps developers, I was intended to add a simple API for accessing web app's memory consumption, see https://bugs.webkit.org/show_bug.cgi?id=39646 The scenario of using this API is as follows: - a builbot runs web app's common usage scenarios tests; - inside tests, memory usage is recorded via the API proposed; - the results are sent to a server (using XHR or a CGI request); - server plots nice graphs of memory usage status, bound to the changes made to the web app; - thus, if someone does a change that blows up memory usage, developers will notice. As Sam points out, this change may be fine, but he suggests to make it accessible only when a browser runs in a special developer mode. This can also be applied to the whole 'console' object. Please, share your thoughts on this. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
On Wed, Jun 2, 2010 at 2:45 PM, Mikhail Naganov mnaga...@chromium.orgwrote: Used memory count can be restricted to include only objects reachable from the caller execution context. In this case, an app could only see the amount of memory consumed by itself, not by the whole engine. I don't think this would change anything about my proposed problem. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
I should note, I don't think this is possible for JS objects, it certainly would not be possible for arbitrary WebCore/WebKit objects. I noticed the patch was re-landed, which surprises me since we are still discussing it, why was this? -Sam On Thu, Jun 3, 2010 at 5:02 PM, Timothy Hatcher timo...@apple.com wrote: Even if that wont prevent Sam's proposed information leak, I think this would be good to do. That way developers only see what they are affecting. Otherwise a developer might chase a red herring if they have Gmail or something open in the background and keep seeing spikes of memory are not caused by their page. On Jun 2, 2010, at 2:45 PM, Mikhail Naganov wrote: Used memory count can be restricted to include only objects reachable from the caller execution context. In this case, an app could only see the amount of memory consumed by itself, not by the whole engine. — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] On adding 'console.memory' API (and about the whole 'console' object.)
After talking it over with some folks here at Apple, I want to formally object to adding the Console.memory extension to the Console object and I think we should remove support for Console.profiles as soon as we can. They both provide information to users that are not generally useful (beyond the continuous integration/buildbot use-case which I think is of limited utility) and therefore should not be exposed to the web. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit2 build system
Hi. On Wed, Jul 7, 2010 at 7:02 AM, Balazs Kelemen k...@inf.u-szeged.hu wrote: Hi folks! While I worked on the Qt port of WebKit2, I faced with some build issues. To solve these problems it seems like common parts of WebKit2 should change, that is why I thought that discussing them in the list would be useful. There are two main problem I see: * Usage of precompiled header. Without using WebKitPrefix.h as a precompiled header it seems like includes are broken. The reason why I dislike precompiled header is that distcc does not support it. It should not be necessary to use WebKitPrefix.h as a precompiled header, it is only necessary for it to be used a prefix header. Does discc also not support prefix headers? * Include paths. The common files in WebKit2 includes headers in the form #include WebKit2/xyz.h while the real place of the file is for example WebKit2/UIProcess/API/C/xyz.h. We can workaround the problem by copying headers into the build dir and set the includepath to contain it, but I do not think it is a good practice. We should probably change the mac to have forwarding headers (as we do with WebCore for JavaScriptCore) to avoid this. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to properly create some element nodes within webcore?
On Wed, Jul 7, 2010 at 8:30 AM, Matt 'Murph' Finnicum mattf...@gmail.comwrote:
I know this sounds a bit silly, but it's a simplified version of what i'm
doing.
Let's say I decided to replace every webpage with hello world. I
decided to do this from finishedParsing() within dom/Document.cpp:
void Document::finishedParsing()
{
ExceptionCode ec = 0;
HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
setBody(body_node, ec);
RefPtrNode new_node = Text::create(this, Hello, World);
body_node - appendChild(new_node,ec);
-- rest of finishedParsing as usual --
That works fine.
Now lets say I want it to be blue:
void Document::finishedParsing()
{
ExceptionCode ec = 0;
HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
setBody(body_node, ec);
RefPtrNode new_font_node =
HTMLElementFactory::createHTMLElement(QualifiedName(nullAtom,
String(font),nullAtom), this, 0, false);
static_castElement*(new_font_node.get())-setAttribute(String(bolor),String(blue),ec);
RefPtrNode new_text_node = Text::create(this, Hello, World);
new_font_node - appendChild(new_text_node,ec);
body_node - appendChild(new_font_node,ec);
--rest of finshedParsing as usual --
Again, this works fine.
But blue is too flashy for my taste, and I now want it to just be bolded.
void Document::finishedParsing()
{
ExceptionCode ec = 0;
HTMLBodyElement* body_node = new HTMLBodyElement(bodyTag, this);
setBody(body_node, ec);
RefPtrNode new_bold_node =
HTMLElementFactory::createHTMLElement(QualifiedName(nullAtom,
String(b),nullAtom), this, 0, false);
RefPtrNode new_text_node = Text::create(this, Hello, World);
new_bold_node - appendChild(new_text_node,ec);
body_node - appendChild(new_bold_node,ec);
--rest of finishedParsing as usual --
... nothing is bold. Other, similar elements like 'strong' 'em' 'u'
'i' don't do anything.
What am I doing wrong?
This is probably not working because you are not creating an Element with
the HTML namespace.
One thing you could try is instead of using
QualifiedName(nullAtom, String(b),nullAtom), use HTMLNames::bTag.
-Sam
___
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 1:29 AM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
namespace WebCore {
...
} // namespace WebCore
2. ENABLE(FOO) #endif comments
#if ENABLE(FOO)
..
#endif // ENABLE(FOO)
I like these two forms of comments.
-Sam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
I am not sure this is true across the board, in many places we set the exception code to TYPE_MISMATCH_ERR on null input in the implementation (the first one I looked at was CanvasRenderingContext2D::drawImage). Can you go into more detail about why the WebGL bindings need to be more strict than the rest of the codebase? -Sam On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao zhen...@gmail.com wrote: Currently for a function's signature in WebKit, if an argument's type is a wrapper type (those JS objec ts that wrap c++ objects, for example, JSWebGLProgram, JSCSSRule, etc.) and if the input object's type does not match the signature, the input is casted to null and no TypeError is raised. Even though WebKit doesn't use Web IDL specially, I think we can look to the Web IDL spec for guidance on what the behavior should be. According to Web IDL spec (http://dev.w3.org/2006/webapi/WebIDL/), unless [AllowAny] is put in the signature, an TypeError should be raised if an argument type does not match its signature. The new automatic code generation for overloaded functions in WebKit DOES raise TypeError when it fails to determine which overloaded variant to call. We definitely need to do the strict type checking for WebGL functions. However, changing the default behavior of the IDL code generators might have a significant compatibility impact. It isn't clear to us whether the current behavior is intentional. If yes, please let us know and we will try to fix the WebGL part only. Otherwise we will modify the general rule instead. ___ 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] js binding: function argument type checking
For this specific case, it seems like you could easily check for a null WebGLProgram* in WebGLRenderingContext::useProgram and set the ExceptionCode. -Sam On Wed, Aug 11, 2010 at 8:54 PM, Mo, Zhenyao zhen...@gmail.com wrote: For example, webgl.useProgram(foo); This should throw an error. However, current behavior will execute webgl.useProgram(null) instead, which will run through without even generating an gl error. I saw a few TYPE_MISMATCH_ERROR in custom-binding. To me, whether it's TYPE_MISMATCH_ERROR or TypeError is less important, but generating an error is. On Wed, Aug 11, 2010 at 8:14 PM, Sam Weinig sam.wei...@gmail.com wrote: I am not sure this is true across the board, in many places we set the exception code to TYPE_MISMATCH_ERR on null input in the implementation (the first one I looked at was CanvasRenderingContext2D::drawImage). Can you go into more detail about why the WebGL bindings need to be more strict than the rest of the codebase? -Sam On Wed, Aug 11, 2010 at 7:06 PM, Mo, Zhenyao zhen...@gmail.com wrote: Currently for a function's signature in WebKit, if an argument's type is a wrapper type (those JS objec ts that wrap c++ objects, for example, JSWebGLProgram, JSCSSRule, etc.) and if the input object's type does not match the signature, the input is casted to null and no TypeError is raised. Even though WebKit doesn't use Web IDL specially, I think we can look to the Web IDL spec for guidance on what the behavior should be. According to Web IDL spec (http://dev.w3.org/2006/webapi/WebIDL/), unless [AllowAny] is put in the signature, an TypeError should be raised if an argument type does not match its signature. The new automatic code generation for overloaded functions in WebKit DOES raise TypeError when it fails to determine which overloaded variant to call. We definitely need to do the strict type checking for WebGL functions. However, changing the default behavior of the IDL code generators might have a significant compatibility impact. It isn't clear to us whether the current behavior is intentional. If yes, please let us know and we will try to fix the WebGL part only. Otherwise we will modify the general rule instead. ___ 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] js binding: function argument type checking
On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.com wrote: On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote: For this specific case, it seems like you could easily check for a null WebGLProgram* in WebGLRenderingContext::useProgram and set the ExceptionCode. Nope, null is a valid argument, it bounds to the initial program, which means nothing will be drawn with WebGL. Certainly not the expected behavior when one pass the wrong type to the argument like Zhenyao pointed out, therefore throwing TypeError really makes sense here (and elsewhere with WebGL API). Ok, in that case, it seems like you need to do it in the bindings for this. I would prefer not making a sweeping change at this time, and instead keeping the changes just to places where the extra checking is necessary due to ambiguity (as in this useProgram case). -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher da...@chromium.org wrote: On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.comwrote: On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote: For this specific case, it seems like you could easily check for a null WebGLProgram* in WebGLRenderingContext::useProgram and set the ExceptionCode. Nope, null is a valid argument, it bounds to the initial program, which means nothing will be drawn with WebGL. Certainly not the expected behavior when one pass the wrong type to the argument like Zhenyao pointed out, therefore throwing TypeError really makes sense here (and elsewhere with WebGL API). Ok, in that case, it seems like you need to do it in the bindings for this. I would prefer not making a sweeping change at this time, and instead keeping the changes just to places where the extra checking is necessary due to ambiguity (as in this useProgram case). -Sam Out of curiosity, if we have the ability for code to be auto generated from the IDL, why not use it universally? I'm trying to guess to understand your preference :) -Darin My concern with doing it universally is the performance cost of doing the check twice in many places (once in the bindings and once in the implementation with a null check). We could certainly re-evaluate the way we do these type checks, potentially even converting the existing null checks in the implementation to asserts, but I think that discussion shouldn't be conflated with this bug fix. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] js binding: function argument type checking
As I mentioned, I am not necessarily against ever changing the behavior, but if we do, we should make sure to remove all the existing checks, as they become an unnecessary branch. It just seems to me like that should be a separate change than a bug due to ambiguity. -Sam On Thu, Aug 12, 2010 at 4:21 PM, Kenneth Russell k...@google.com wrote: For what it's worth, I think this change should be made for all of the DOM bindings, not just those for WebGL. The IDL code generators' support for overloaded methods already generates TypeError when an incoming argument doesn't implement any of the interfaces required by the overloaded variants. The new behavior will be closer to the rules specified by Web IDL in http://dev.w3.org/2006/webapi/WebIDL/#es-interface and also, as I understand it, closer to what Firefox implements. It would be possible to add support for another extended attribute to the code generators and annotate all of the methods in WebGLRenderingContext.idl, but I really think the default behavior should be changed. -Ken On Thu, Aug 12, 2010 at 1:15 PM, Mo, Zhenyao zhen...@gmail.com wrote: Hardly. Right now we already do the type checking in the generated toType(argument) functions. Instead of casting to null, we throw a TypeError, which adds no extra cost if the type is correct. Besides, where I looked, after toType(argument) call, exception is checked. Only that currently toType(argument) is not generating exceptions. Mo On Thu, Aug 12, 2010 at 9:20 AM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher da...@chromium.org wrote: On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig sam.wei...@gmail.com wrote: On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.com wrote: On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote: For this specific case, it seems like you could easily check for a null WebGLProgram* in WebGLRenderingContext::useProgram and set the ExceptionCode. Nope, null is a valid argument, it bounds to the initial program, which means nothing will be drawn with WebGL. Certainly not the expected behavior when one pass the wrong type to the argument like Zhenyao pointed out, therefore throwing TypeError really makes sense here (and elsewhere with WebGL API). Ok, in that case, it seems like you need to do it in the bindings for this. I would prefer not making a sweeping change at this time, and instead keeping the changes just to places where the extra checking is necessary due to ambiguity (as in this useProgram case). -Sam Out of curiosity, if we have the ability for code to be auto generated from the IDL, why not use it universally? I'm trying to guess to understand your preference :) -Darin My concern with doing it universally is the performance cost of doing the check twice in many places (once in the bindings and once in the implementation with a null check). We could certainly re-evaluate the way we do these type checks, potentially even converting the existing null checks in the implementation to asserts, but I think that discussion shouldn't be conflated with this bug fix. -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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
I am not sure I agree. Does our behavior actually cause any real bugs in the places you have tracked down? The log spam really doesn't seem like an issue, we can remove it if we want to, but have found it useful in the past. I agree with Maciej that the current behavior is in many ways better, so I am not in a rush to change this just to be more spec compliant. -Sam On Mon, Aug 16, 2010 at 1:50 PM, Mihai Parparita mih...@chromium.orgwrote: I was wondering if there are any other thoughts on this. It seems like there's real-world need from this (based on the usages I tracked down, and log spam problem) and all other browsers (and the HTML5 spec) have the exception-throwing behavior. Thanks, Mihai On Fri, Aug 13, 2010 at 10:19 AM, Mihai Parparita mih...@chromium.orgwrote: On Fri, Aug 13, 2010 at 9:59 AM, Mihai Parparita mih...@chromium.org wrote: I've asked Joseph (the original reporter of http://crbug.com/17325) where he ran into this. Joseph replied and said While there is a proprietary web app that relies on this, but it is used at a small company I no longer work for and have no access to. However, I do remember it being a little frustrating developing around this since Firefox and IE both throw the exception. The other reason why throwing the exception might be preferable is to avoid console log spam. For example, http://www.nytimes.com/ has lots of iframes that (for whatever reason) reach into the parent (or vice-versa). In Safari and Chrome, the console has 6 unsafe JavaScript access messages, which the developer can't avoid, even if they're expecting possible errors (in Firefox there's only 1, so I assume at least some of their JS has try/catch blocks around cross-origin access). If we replace the printErrorMessageForFrame call with setDOMException(exec, SECURITY_ERR) then developers who catch the exception can avoid the log message. 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
Re: [webkit-dev] WebKit2 SharedSecondaryProcess model
Hi Balazs, Does it not work currently? If not, can you please file bugs on what is not working. We plan on making the shared process model the default model for the API, but it will probably have the caveat that it will not support InjectedBundles. -Sam On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen k...@inf.u-szeged.hu wrote: Hi all! I am wondering about do you plan for the mac and win to support the shared web process model? Actually, I have played around with that for Qt. I have a working, proof of concept implementation. The visited links and the back-forward list features are broken, but apart from that the browsers are working with the shared web process. I had to rework common parts of the code for achieving that, and I would like to contribute it in small parts. I think if we want to support that model in the future than we should start to implement it as soon as possible to assure that our design fits the needs of that. Cheers! Balazs Kelemen ___ 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] Script programming language: Perl, Python, or Ruby?
Sorry, I seemed to have missed this thread. Please do not rewrite scripts just to rewrite them in a language you like. WebKit's dependency on Ruby is here to stay. Just because python is common at Google does not make it universal. -Sam On Wed, Sep 1, 2010 at 4:48 PM, TAMURA, Kent tk...@chromium.org wrote: Thanks. So porting PrettyPatch to Python will make good benefit and should have no drawbacks. I should go ahead. On Wed, Sep 1, 2010 at 09:21, William Siegrist wsiegr...@apple.comwrote: On Aug 31, 2010, at 4:43 PM, TAMURA, Kent wrote: Can we run python scripts on bugs.webkit.org server? Yes. -Bill -- TAMURA Kent Software Engineer, Google ___ 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] WebKit2 SharedSecondaryProcess model
Hi,
Sorry for the tardy reply. We currently have no plan to support that model,
but it will be something we can keep in mind as we progress. I would like
us to concentrate on getting the simple two-process case
(SharedSecondaryProcessModel) working well, before we get more adventurous.
-Sam
On Fri, Sep 3, 2010 at 6:11 AM, Andras Becsi abe...@inf.u-szeged.hu wrote:
Hi!
Just to get things clear:
SecondaryProcessModel:
Web processes: {W} {W} {W}{W} {W}
| | | | |
UI processes: {t t t} {t t}
This should be the model Chrome uses, and the model which saves some memory
and is parallel should be the
SharedSecondaryProcessModel:
Web processes: {W} {W}
/ | \ / \
UI processes: {t t t} {t t}
where t means the tabs (or pages) and {t} represents a process with one
tab.
Balazs, the model you suggested, would look like:
SharedSecondaryServerProcessModel (maybe):
Web proces (server): {W}
/// \\
UI processes: {t t t} {t t}
Right? This means there would be only one WebProcess, which would work as a
server for UI client processes which connect to it. I see the benefits of
this in an embedded environment where widgets share one common WebProcess
and thus this model would use less memory, for example if the WebProcess is
used by multiple widgets.
I see that this model is not really parallel, but saves memory.
Is there a future plan to support this model too?
BR:
Andras
On 09/01/2010 01:09 PM, Balazs Kelemen wrote:
(Sorry for flooding the list but I need to repeat my reply to put it in
the right thread.)
Seems like I misunderstood the concept. I assumed that the shared
process model means that there could be multiply UI process instances
that uses the same web process, virtually when the second MiniBrowser is
launched it connects to the existing web process. By taking a deeper
look into the WebContext and WebProcessProxy classes, I have realized
that the shared process model is about using one web process for
multiply views (what is cool) and not for multiply processes (what would
be more cool from my point of view :) ).
What do you think about my idea? Primarily on embedded devices it would
be great to use the web engine as a server process because it could save
a lot of memory. I think the current design is not too far for
supporting that. Mainly we should find a correct way of connecting the
new UI process to the existing web process, and the Connection should be
per page instead of per process (or we should rework the WebProcess to
not be a singleton?).
Please provide some feedback on this because it is important for our
project to know which way should we go on with WebKit2. Thank you!
Balazs Kelemen
On 08/30/2010 08:22 PM, Sam Weinig wrote:
Hi Balazs,
Does it not work currently? If not, can you please file bugs on what
is not working. We plan on making the shared process model the default
model for the API, but it will probably have the caveat that it will
not support InjectedBundles.
-Sam
On Mon, Aug 30, 2010 at 6:08 AM, Balazs Kelemen k...@inf.u-szeged.hu
mailto:k...@inf.u-szeged.hu wrote:
Hi all!
I am wondering about do you plan for the mac and win to support the
shared web process model?
Actually, I have played around with that for Qt. I have a working,
proof
of concept implementation. The visited links and the back-forward list
features are broken, but apart from that the browsers are working with
the shared web process. I had to rework common parts of the code for
achieving that, and I would like to contribute it in small parts. I
think if we want to support that model in the future than we should
start to implement it as soon as possible to assure that our
design fits
the needs of that.
Cheers!
Balazs Kelemen
___
webkit-dev mailing list
webkit-dev@lists.webkit.org mailto: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] Why is the Windows WebKit2 bot slower than the SnowLeopard WebKit2 bot? (was: Re: Leopard Debug and Windows Debug test bots are too slow)
On Fri, Sep 10, 2010 at 5:15 AM, Adam Roben aro...@apple.com wrote: On Sep 10, 2010, at 8:11 AM, Adam Roben wrote: It's interesting that ~45 minutes elapse between builds for the Windows WebKit2 bot, but only ~18 minutes elapse between builds for the SnowLeopard WebKit2 bot. We should figure out where the extra time is being spent! Looking at http://build.webkit.org/builders/Windows%20Debug%20%28WebKit2%20Tests%29/builds/633 vs. http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/1624 : jscore-test took 267 seconds on Windows vs. 18 seconds on SnowLeopard layout-test took 1711 seconds on Windows vs. 601 seconds on SnowLeopard That adds up to an extra 22.5 minutes on Windows, which explains most of the difference between the two. Perhaps the biggest issue is that Windows is using Debug builds, while Mac is using Release? Maybe we should change the Windows WebKit2 bot to use Release builds. I think changing to use release would make sense. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Use of Frame by ResourceHandle
It seems the dependency on Frame is now gone (as of last night I guess?) with the advent of the NetworkingContext. -Sam On Sat, Sep 11, 2010 at 3:42 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 11, 2010, at 2:57 AM, Adam Barth wrote: I don't mean to spam this list with design questions, but I'm trying to wrap my mind around how the loader is put together today and how we'd like it to be put together in the future. There's a FIXME in ResourceHandle that says that ResourceHandle shouldn't depend on Frame. (For those who aren't familiar with the loader, ResourceHandle is the primary platform abstraction WebCore uses to communicate with the network.) This makes sense to me for two reasons: 1) ResourceHandle is in WebCore/platform/network and therefore isn't allowed to depend on parts of WebCore outside the platform directory. 2) There are a number of types of network requests that are not associated with frames (e.g., XMLHttpRequests from WebWorkers, PingLoader, etc). Do we still believe this FIXME is accurate? If so, I have some time next week to look at removing the dependency. There's a patch that either recently landed or is about to land that furthers the use of Frame by ResourceHandle, so I wanted to check with folks more broadly about whether this is the right direction. (Note that I haven't studied the code yet, so I'm not sure what would be required to remove the dependency.) I think this is the right way to go. I don't clearly understand the reasons this dependency was added, but I hope we can find an alternate design to meet those needs. 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] Why are the mock implementations in WebCore/platform?
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
Re: [webkit-dev] Why do both DOMWindow and Document objects hold SecurityOrigin objects?
It is for historical reasons that both have an origin. The idea was that we were going to move the DOMWindow to be owned by the Document, and when that was done, remove the DOMWindow's origin. I seem to remember there being a theoretical time when the two could differ, but looking at DocumentWriter::begin() now, it seems like we always set both to the same value. I still think the re-factor to make Document own DOMWindow would make this much clearer. -Sam On Tue, Dec 7, 2010 at 11:53 AM, Darin Adler da...@apple.com wrote: Why does both a DOMWindow and a Document hold a securityOrigin? Is there a way we can get rid of one or the other? Are the two equivalent, or is there a difference? Is there a time when it’s correct to do frame-domWindow()-securityOrigin() and incorrect to do frame-document()-securityOrigin(), or vice versa? -- 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] Page Cache for web-pages with plugin
No one (that I know of) is currently working on making plugins work with the PageCache. The most pressing road block to make it work is infrastructure to kill and restart plugins (or alternatively, and reliable way to pause them, perhaps using their current out of process nature, or perhaps proposing API on plugin-futures for it). -Sam On Mon, Dec 20, 2010 at 1:29 AM, Aneesh Bhasin contact.ane...@gmail.comwrote: Hi All, I will really appreciate if someone could help me with this.. regards, Aneesh On Fri, Dec 17, 2010 at 11:17 AM, Aneesh Bhasin contact.ane...@gmail.com wrote: Hi All, I was wondering as to what is the current status for maintaining a page cache for webpages which contain some plugin ( https://bugs.webkit.org/show_bug.cgi?id=13634) ? The last update on that bug report said that work is ongoing towards it. If someone could point me to the right direction here that it will be very helpful.. Thanks and regards, Aneesh ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Renaming directories
We also have WebKit2 API tests (or soon will if they aren't landed yet). The WebKit2 tests have been in the tree (under Tools/TestWebKitAPI) for bit now. The harness can also be used to test WTF data structures and has a sample test of basic testing of Vector. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More thoughts on cleaning up the root directory
On Mon, Dec 27, 2010 at 11:14 AM, Adam Barth aba...@webkit.org wrote: Is it really a good idea to move platform out of WebCore? Lots of stuff there seems quite WebCore related. There seem to be a couple people who aren't sold on moving platform out of WebCore. It sounds like we should hold off on doing that and discuss it separately down the road. On Mon, Dec 27, 2010 at 2:47 AM, Hajime Morita morr...@google.com wrote: Platform/ (was WebCore/platform) I'd like to keep platform directory under WebCore if there is no strong reason. Ok. I think different people have slightly different ideas about what should go into this folder. That sounds like a complex topic that we might need to discuss more later. I think moving Platform out from WebCore is great long term goal, but right now, there is simply too many layering violations for it to be feasible. For those curious, the intent is for nothing in Platform to be dependent on anything else in WebCore (eg. dom, html, rendering, loader), so something like platform/qt/RenderThemeQt.cpp would be considered a layering violation. There are bugs filed on many of these violations, but the work has not be completed. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Webkit handling of plug-ins out-of-process on the mac
WebKit has had the ability to run plugins out of process on the mac for quite some time. We recently reimplemented a bunch of that functionality to share infrastructure with WebKit's general out-of-process strategy, and that code can be found http://trac.webkit.org/browser/trunk/Source/WebKit2/PluginProcess. What specifics are you interested in? -Sam On Wed, Mar 9, 2011 at 1:50 PM, Rudi Sherry rshe...@adobe.com wrote: Sorry if this is the wrong forum. Is WebKit adding the capability to load plug-ins out-of-process on the mac? If so, would this forum be the right one for questions about how this is done, and technical specifics about it? If not, where? Thanks, Rudi ___ 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 unit test framework
I am really not an expert on testing frameworks, and just put together something that met my needs (as has been the tradition in this project). That said, the only features I like about TestWebKitAPI is that I know how it works and can hack it to do what I want, and that it has the ability to run each test in its own invocation (I also like the color output from the tests, because it's is in color!) So, my questions for people who have used gtest is, Is it hackable? What kind of changes have you had success making? Is a death test as scary as it sounds? -Sam On Apr 18, 2011, at 11:36 AM, David Levin wrote: Issue: There has been a long standing bug to add unit tests to WebKit (https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentioned on webkit-dev that it would be helpful in various cases. Landscape: Surveying WebKit, it is looks like there are at least three testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI has been used so far (as far as I can tell) for testing core WebKit items like WTF (though I was unaware of TestWebKitAPI until Friday). It seems like a good way to think about the issue of which to use in general in WebKit would be to decide on what would be desired in our framework and then see how each matches up. Here's my take on this. (It may be biased toward what I am familiar with but I welcome others to add their own criteria.) Criteria Musts: Compatible license with WebKit Builds/Can be built on the many platforms and build systems supported by WebKit (ideally without extra installs). Useful: Easy to write tests Hackable to suit our needs Well tested features (to support hackability/stability) Supports filtering of tests so you can run just the test you care about (and easily listing the tests). Supports writing out values when there is test failure. (For example, if the is verifying that A == B but that is not true, then the values of A and B should be printed.) Well documented thanks, 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-resource: referring to resources in User Agent stylesheet
Would we want this to be web facing? Or should we limit it to inside the
built-in stylesheets?
-Sam
On Apr 26, 2011, at 1:18 PM, Dimitri Glazkov wrote:
Hello,
SUMMARY: we would like to introduce a webkit-resource URL scheme for
CSS, which would refer to images baked into WebKit.
BACKGROUND: in order to style media controls today, we rely on the
ControlPart enum
(http://codesearch.google.com/codesearch/p#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/ThemeTypes.hl=48exact_package=chromium),
which is exposed as the -webkit-appearance CSS attribute. For
example:
video::-webkit-media-controls-play-button {
-webkit-appearance: media-play-button;
}
In addition, the state of the button is further adjusted by looking at
the runtime state or media characteristics of the element (is the user
currently hovering or clicking on the element? is it playing? is it
streaming? has an error occurred?). This happens at the port layer, in
RenderTheme implementation.
With impending introduction of media element pseudo-classes and the
patch in bug 58342 landing, we will be able to sense these extra
states at the CSS level:
video:playing::-webkit-media-controls-play-button:hover {
-webkit-appearance: media-play-button-playing-hover;
}
This would result in a lot less of mindless style-flipping
RenderTheme/MediaControlElement code and provide more flexibility for
each port to design their pretty things.
However, sticking with existing -webkit-appearance strategy will
result in ControlPart enum exploding as combinatorial math suggests.
Which is a ...
PROBLEM: We need a way to somehow in CSS associate an element state
with a relatively arbitrary key to avoid ControlPart from becoming the
tallest enum ever.
SOLUTION: Looking at the current media controls implementations, most
of the -webkit-appearance states are kind of like background images,
each reflecting appearance of an element at a particular state. Thus,
it seems we should be able to solve this by just using CSS
backgrounds:
video:playing::-webkit-media-controls-play-button:hover {
background: url(/media-controls/play-button-hover.png);
}
That is how the authors would style the media controls. However, at
the UA level, we shouldn't probably be loading resources from random
sites. Instead, we need a way to bake these images into the WebKit
runtime, and then a way to refer to them from the stylesheet.
This is where a vendor-specific URL scheme comes in:
video:playing::-webkit-media-controls-play-button:hover {
background: url(webkit-resource:/media-controls/play-button-hover.png);
}
A quick poll of smart people (abarth and smfr) seems to indicate it's
not a completely horrid idea.
WDYT? Thoughts? Comments?
:DG
___
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 get mimeType for decidePolicyForResponse ??
It doesn't look like they have have exposed API to do this yet. Please file an enhancement request at bugs.webkit.org. -Sam On May 24, 2011, at 8:33 PM, naren.me...@gmail.com wrote: Thanks for the response, Sam. On Tue, May 24, 2011 at 10:19 PM, Sam Weinig wei...@apple.com wrote: It depends what port you are using, I am using WebKit2-GTK port. Any idea, how it can be done in that ? -- Naren but the general idea is that you should be able to get a MIME type from the WKURLResponseRef. On the Mac for instance, we can get an NSURLReponse out of a WKURLResponseRef using WKURLResponseCopyNSURLResponse and copy the MIME type from that. -Sam On May 24, 2011, at 5:42 AM, naren.me...@gmail.com wrote: Hi, I am trying to implement the functionality for decidePolicyForResponse function. For that, I require the mimeType based on the WKURLResponseRef. In previous implementation of WebKit we used to pass the mimeType explicitly as one of the parameters of the callback function. But it has been changed, and so I am not able to find out a way to do that and got stuck. Can any of you tell me how it can be done or point me to a sample code where its done ?? Regards, Naren ___ 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] JS bindings: Adding EventTarget to the prototype chain
I don't think we should do this. EventTarget is really just an abstract
interface, and changing its implementation globally is of limited utility.
-Sam
On Jun 8, 2011, at 5:54 PM, Dominic Cooney wrote:
[If you don't care about JSC or V8 bindings you can safely ignore
this.]
TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?
Here is the prototype chain for a button today:
HTMLButtonElement-HTMLElement-Element-Node-Object
(add/removeEventListener and dispatchEvent are on Node.)
Here is how I think we should make it look:
HTMLButtonElement-HTMLElement-Element-Node-EventTarget-Object
(addEventListener etc. are on EventTarget.)
Here’s why I think we should do this:
- Specs are moving towards specifying EventTarget as living on the
prototype chain. DOM Core*, Notifications, Indexed DB, SVG and XHR
already do it this way. (* Editor’s draft.)
- Frameworks that want to hook add/removeEventListener will be able to
do it in one place: on EventTarget.prototype. In WebKit today they
have to hook the prototypes of window, Node, XMLHttpRequest, etc.
individually (Because WebKit implements EventTarget as a mixin
everywhere, there are 20+ different kinds of event targets to hook if
you want to be comprehensive.) If we make this change, it gets easier
to tell if a given object is an EventTarget; just do
EventTarget.prototype.isPrototypeOf(something).
- It will modestly simplify WebKit’s IDLs and bindings. Instead of
declaring addEventListener in two dozen places in IDLs, it will be in
one place; instead of calling visitJSEventListeners in dozens of
places for JSC GC, it will be called in one place; instead of assuming
that EventTarget parameters are all Node* under the covers for V8 code
generation, we can treat EventTargets uniformly; instead of
redundantly specifying EventTarget on Document and Node inheritance
will do what you want; etc.
Will doing this break the web? I don’t think so:
Anyone who calls or hooks addEventListener, etc. will continue to
work, just their foo.addEventListener might be resolved at one level
higher up the prototype chain than it is today. To really observe the
different placement of addEventListener, etc. minutely you need to
access __proto__ and hasOwnProperty. Other browsers are already differ
from WebKit in this regard, too: For example, Firefox reports
addEventListener is an own property on *every* step in the prototype
chain of DOM objects (until Object.)
Scripts that squirrel up the prototype chain themselves will see one
more link (EventTarget’s) but it is towards the top of the chain, past
most prototypes they care about (every prototype except Object.)
I tried changing half of the EventTargets in WebKit to put EventTarget
in the prototype chain, including Node and XHR (but not window) and
used it to surf the web for a few days. I didn’t notice anything break
:)
There is also the possibility that this could hurt performance,
because accessing addEventListener, etc. will have to search more
prototypes (usually just one more.) Accessing the properties of Object
on an event target via the prototype chain will have to squirrel
through one more prototype (EventTarget’s.) So I prototyped this
change in the JSC bindings and put EventTarget in the prototype chain
of a number of event targets in WebKit, including Node. Here are the
results for Dromaeo’s dom and jslib tests:
http://dromaeo.com/?id=141811,141813
(141811 on the left is the status quo.)
I expect the Prototype and jQuery events benchmarks are of particular
interest, and the result looks particularly bad for Prototype (~3%
slowdown). So I reran http://dromaeo.com/?event half a dozen times,
and couldn’t produce the poor result for Prototype; on average the
prototype was 1.0% slower for Prototype and 0.5% slower for jQuery. I
think Dromaeo is too noisy for measuring something as fine as this.
So I wrote three microbenchmarks:
1. Add/remove click listener on a button.
2. Add/remove progress listener on an XHR.
3. Test property presence with 'in':
if ('dispatchEvent' in target)
n++;
// return n outside of loop
where target is an XMLHttpRequest and n is a local var n = 0.
Here are the results. A brief note on methodology: release build
running in Mac Safari, JSC, averaging 500 samples with 1,000,000
iterations of the inner loop per sample.
1. Add/remove on button
Before (ms): min=409, median=434, mean=434.4, max=472
After (ms): min=410, median=453.5, mean=452.4, max=497 (mean is 1.04x)
2. Add/remove on XHR
Before (ms): min=286, median=298, mean=298.6, max=315
After (ms): min=287, median=300.5, mean=300.7, max=320 (mean is 1.01x)
3. 'dispatchEvent' in XHR
Before (ms): min=85, median=88, mean=87.7, max=91
After (ms): min=89, median=91, mean=91.0, max=95 (mean is 1.04x)
So this shows
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
Why should we implement this spec? We already have one flex box implementation that we can never remove (and corresponds closely to Firefox's) so it seems to me that we should work on standardizing that model. Adding a large bunch of code that duplicates existing functionality seems foolish. If the issue is the syntax for describing flexing, perhaps the spec should be written in a backwards compatible way, that supports both the new syntax and the old syntax, but the underlying implementation can remain. -Sam On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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] Adding ENABLE_FLEXBOX to WebCore
Since it is confusing to me (and may be to others), perhaps a different name than ENABLE_FLEXBOX should be used, given that we already have flexbox. Maybe, ENABLE_NEW_FLEXBOX? -Sam On Jun 10, 2011, at 2:42 PM, David Hyatt wrote: Just so people know, it was my recommendation that they just start with a new renderer and implementation. Some other recommendations I would make here (apologies if they have been implemented already): (1) Rename the current RenderFlexibleBox to put deprecated into the name, e.g., RenderDeprecatedFlexibleBox. (2) The old flexbox was never patched for vertical writing modes. Please make sure when you build the new renderer from the ground up that you take this into account. (3) Please consult with rendering experts for any changes you have to make to base classes, especially RenderBlock and RenderBox. We may be able to help simplify some of that code, especially compared to the old flexbox. (4) Use the old flexbox code as a rough guide, but be aware of its issues, e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I think some of the bugs you tried to fix already should inform this somewhat. Definitely keep rendering experts in the loop on this and have fun implementing! Dave On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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] Adding ENABLE_FLEXBOX to WebCore
Great! -Sam On Jun 13, 2011, at 9:37 AM, Tony Chang wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com wrote: Since it is confusing to me (and may be to others), perhaps a different name than ENABLE_FLEXBOX should be used, given that we already have flexbox. Maybe, ENABLE_NEW_FLEXBOX? -Sam On Jun 10, 2011, at 2:42 PM, David Hyatt wrote: Just so people know, it was my recommendation that they just start with a new renderer and implementation. Some other recommendations I would make here (apologies if they have been implemented already): (1) Rename the current RenderFlexibleBox to put deprecated into the name, e.g., RenderDeprecatedFlexibleBox. (2) The old flexbox was never patched for vertical writing modes. Please make sure when you build the new renderer from the ground up that you take this into account. (3) Please consult with rendering experts for any changes you have to make to base classes, especially RenderBlock and RenderBox. We may be able to help simplify some of that code, especially compared to the old flexbox. (4) Use the old flexbox code as a rough guide, but be aware of its issues, e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I think some of the bugs you tried to fix already should inform this somewhat. Definitely keep rendering experts in the loop on this and have fun implementing! Dave On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ 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] Adding ENABLE_FLEXBOX to WebCore
I think in this case it makes sense, since it is a temporary #define. But if you feel strongly, what would you propose? Is there a more distinctive name than FLEXBOX that identifies this as different from the existing code? -Sam On Jun 13, 2011, at 10:50 AM, Simon Fraser wrote: Using terms like 'new' in code is rarely a good idea. In a year, the context has gone, and 'new' no longer means anything. Simon On Jun 13, 2011, at 9:38 AM, Tony Chang wrote: Err, ENABLE_NEW_FLEXBOX. On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com wrote: Since it is confusing to me (and may be to others), perhaps a different name than ENABLE_FLEXBOX should be used, given that we already have flexbox. Maybe, ENABLE_NEW_FLEXBOX? -Sam On Jun 10, 2011, at 2:42 PM, David Hyatt wrote: Just so people know, it was my recommendation that they just start with a new renderer and implementation. Some other recommendations I would make here (apologies if they have been implemented already): (1) Rename the current RenderFlexibleBox to put deprecated into the name, e.g., RenderDeprecatedFlexibleBox. (2) The old flexbox was never patched for vertical writing modes. Please make sure when you build the new renderer from the ground up that you take this into account. (3) Please consult with rendering experts for any changes you have to make to base classes, especially RenderBlock and RenderBox. We may be able to help simplify some of that code, especially compared to the old flexbox. (4) Use the old flexbox code as a rough guide, but be aware of its issues, e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I think some of the bugs you tried to fix already should inform this somewhat. Definitely keep rendering experts in the loop on this and have fun implementing! Dave On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding ENABLE_FLEXBOX to WebCore
That totally works for me. -Sam On Jun 13, 2011, at 10:52 AM, Darin Fisher wrote: Good point! Maybe we can use a term that is derived from the name of the spec? ENABLE_CSS3_FLEXBOX? -Darin On Mon, Jun 13, 2011 at 10:50 AM, Simon Fraser simon.fra...@apple.com wrote: Using terms like 'new' in code is rarely a good idea. In a year, the context has gone, and 'new' no longer means anything. Simon On Jun 13, 2011, at 9:38 AM, Tony Chang wrote: Err, ENABLE_NEW_FLEXBOX. On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang t...@chromium.org wrote: Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX. On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wei...@apple.com wrote: Since it is confusing to me (and may be to others), perhaps a different name than ENABLE_FLEXBOX should be used, given that we already have flexbox. Maybe, ENABLE_NEW_FLEXBOX? -Sam On Jun 10, 2011, at 2:42 PM, David Hyatt wrote: Just so people know, it was my recommendation that they just start with a new renderer and implementation. Some other recommendations I would make here (apologies if they have been implemented already): (1) Rename the current RenderFlexibleBox to put deprecated into the name, e.g., RenderDeprecatedFlexibleBox. (2) The old flexbox was never patched for vertical writing modes. Please make sure when you build the new renderer from the ground up that you take this into account. (3) Please consult with rendering experts for any changes you have to make to base classes, especially RenderBlock and RenderBox. We may be able to help simplify some of that code, especially compared to the old flexbox. (4) Use the old flexbox code as a rough guide, but be aware of its issues, e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I think some of the bugs you tried to fix already should inform this somewhat. Definitely keep rendering experts in the loop on this and have fun implementing! Dave On Jun 8, 2011, at 10:57 AM, Tony Chang wrote: Hi webkit-dev, I wanted to let you know that Ojan and I plan to add flexbox layout support to WebCore. WebCore already supports an older flexbox implementation (display: box), but the new spec is designed to be easier for developers to understand and more powerful. The old flexbox will still remain in WebCore since none of the CSS properties overlap with the new flexbox spec. The spec can be found at: http://www.w3.org/TR/css3-flexbox/ (http://dev.w3.org/csswg/css3-flexbox/) This support will be behind the ENABLE_FLEXBOX feature define (https://bugs.webkit.org/show_bug.cgi?id=62049) and there is a meta bug tracking the feature's development (https://bugs.webkit.org/show_bug.cgi?id=62048). I expect this feature to eventually be enabled by all ports. I am ready to setup a buildbot for tracking the compile and flexbox related layout tests. Should I go ahead and get this added to build.webkit.org's waterfall? Thanks, Tony ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ 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] Shadow DOM API (first iteration) ready for landing
Hi Dimitri, First of all, nice work on getting to this point! It is not clear to me why we wouldn't stick with XBL2 for now, at least until there is more community consensus on going another way, and a spec and editor are available to take the API forward. I think it would help if you could explain what considerations you took into account when making this decision, and further, why this subset is a good starting place. What are the use cases of this subset? - Sam On Jun 28, 2011, at 7:42 PM, Dimitri Glazkov wrote: Dear WebKit, After nearly a year of building up the shadow DOM plumbing and converting WebKit to use it, we are finally at the point where we can expose this plumbing as public-facing API. The approach we take here is a very cautious one: we want to expose the minimum subset of the larger Web Component Model (some of you might remember is it as XBL2). The goal is to minimize the impact, but have something useful enough for Web developers to help us gather feedback. After careful consideration, we've come up with this subset for our first iteration: http://dglazkov.github.com/component-model/dom.html Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor We will also provide the ENABLE(COMPONENT_MODEL) flag to control availability of this API and its iterations, even though all of the C++ code will always compile, since it's used throughout WebKit. NOTE: This iteration of the API is not intended to ship in a release version of a browser (think nightlies and dev channel only). Be sure to disable it on your respective release branches. Please chime in if you have concerns. Wish us luck! :DG ___ 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] WebKit2 C API
Hi Carlos, Unfortunately, there is not much to report here. We have not made any decisions on whether we are going to migrate to a C++ API. If you are implementing a layer on top of the C API, that should continue to work for the foreseeable future. -Sam On Jul 14, 2011, at 12:10 AM, Carlos Garcia Campos wrote: In the contributors meeting notes about WebKit2[1] I've read that the C API might have been a bad idea, and I've heard that there are plans to remove, or replace it by a C++ API. What are the plans for the C API? In the GTK+ port we are using the C API to implement the MiniBrowser and we are planning to provide a high level GTK+ API on top of the C one (without exposing it), so can we rely on the C API to implement our GTK+ one? [1] http://trac.webkit.org/wiki/April 2011 Meeting/WebKit2 Thanks, -- Carlos Garcia Campos ___ 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] DOMCrypt
I think we should let the spec mature a bit before diving in. -Sam On Jul 26, 2011, at 10:53 PM, Adam Barth wrote: Hi webkit-dev, As some of you are probably aware, Mozilla is experimenting with exposing some basic cryptographic primitives to web applications: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest I wanted to get a sense from the WebKit community about how interested we are in implementing this feature. My sense is that this API is fairly early in it's lifecycle, so one perspective is that we should wait for Mozilla to experiment for a bit longer and revisit this question once the design is further along (e.g., submitted to the W3C standards process). Another perspective is that there are some simple parts of the API that we should implement now, and we can grow into the more involved parts of the API as they mature. For example, the CryptoHash interface can be implemented independently of the rest of the API and provides value by itself. Thoughts? 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] Current legacy argument refactoring -- behavior changes?
This list doesn't seem to include the changes in behavior to addEventListener and removeEventListerner (from patches like http://trac.webkit.org/changeset/92469 http://trac.webkit.org/changeset/92433). Are those intentionally left out? -Sam On Aug 5, 2011, at 12:44 PM, Mark Pilgrim wrote: Here is the complete list of intentional behavior changes in patches I've submitted in the past few months, along with bug URLs to show the discussion / rationale behind each change: https://bugs.webkit.org/show_bug.cgi?id=63065 IDBFactory.open() https://bugs.webkit.org/show_bug.cgi?id=63079 IDBIndex.get() IDBIndex.getKey() https://bugs.webkit.org/show_bug.cgi?id=63085 IDBKeyRange.only() IDBKeyRange.lowerBound() IDBKeyRange.upperBound() IDBKeyRange.bound() https://bugs.webkit.org/show_bug.cgi?id=63087 IDBObjectStore.put() IDBObjectStore.add() IDBObjectStore.delete() IDBObjectStore.get() IDBObjectStore.createIndex() IDBObjectStore.index() IDBObjectStore.deleteIndex() https://bugs.webkit.org/show_bug.cgi?id=63140 IDBDatabase.createObjectStore() IDBDatabase.deleteObjectStore() IDBDatabase.setVersion() IDBDatabase.transaction() https://bugs.webkit.org/show_bug.cgi?id=64539 all arguments in File API-related methods not already marked [Optional] https://bugs.webkit.org/show_bug.cgi?id=64549 all arguments in WebGL-related methods not already marked [Optional] https://bugs.webkit.org/show_bug.cgi?id=65338 DOMTokenList.item() DOMTokenList.contains() DOMTokenList.add() DOMTokenList.remove() DOMTokenList.toggle() DOMURL.createObjectURL() DOMURL.revokeObjectURL() HTMLAnchorElement.getParameter() HTMLButtonElement.setCustomValidity() HTMLFieldSetElement.setCustomValidity() HTMLInputElement.setCustomValidity() HTMLKeygenElement.setCustomValidity() HTMLMediaElement.canPlayType() TimeRanges.start() TimeRanges.end() HTMLAllCollection.namedItem() HTMLAllCollection.tags() https://bugs.webkit.org/show_bug.cgi?id=65353 DOMWindow.webkitRequestFileSystem() DOMWindow.webkitResolveLocalFileSystemURL() DOMWindow.webkitRequestAnimationFrame() (reverted in https://bugs.webkit.org/show_bug.cgi?id=65698 ) DOMWindow.webkitCancelRequestAnimationFrame() (reverted in https://bugs.webkit.org/show_bug.cgi?id=65698 ) https://bugs.webkit.org/show_bug.cgi?id=65355 Geolocation.clearWatch() PositionCallback.handleEvent() PositionErrorCallback.handleEvent() https://bugs.webkit.org/show_bug.cgi?id=65370 Navigator.registerProtocolHandler() https://bugs.webkit.org/show_bug.cgi?id=65570 SpeechInputResultList.item() https://bugs.webkit.org/show_bug.cgi?id=65571 WebKitAnimationList.item() https://bugs.webkit.org/show_bug.cgi?id=65715 MediaStreamList.item() MediaStreamTrackList.item() TouchList.item() https://bugs.webkit.org/show_bug.cgi?id=65750 AudioBufferSourceNode.noteOn() AudioBufferSourceNode.noteGrainOn() AudioBufferSourceNode.noteOff() ___ 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] Style: Vector::iterator vs indexed iteration
In general, we have preferred index style. -Sam On Oct 17, 2011, at 2:48 PM, Adam Klein wrote: A small style question came up in a review today, and I was curious if there's any consensus on this: when iterating over a WTF::Vector, does WebKit style prefer using a size_t vs a Vector::iterator, or vice-versa? Both show up in WebCore, but the indexed style is more common (by maybe a 5-1 ratio by my rough git grep estimation), which at least suggests that it may be preferred. - 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] ENABLE-removal summary
Hazzah! Great work Adam and friends! -Sam On Oct 18, 2011, at 10:37 AM, Adam Barth wrote: As discussed previously on webkit-dev, we've been cleaning up some of the ENABLE macros in WebKit: https://lists.webkit.org/pipermail/webkit-dev/2011-September/017988.html As part of this effort, we've removed 19 ENABLE macros. Of those, 5 were converted to USE macros, 6 were deleted along with their associated code, and 8 were removed and the associated code was always enabled. I'd like to thank everyone who helped with this project, both patch writers and reviewers. Hopefully everyone will find WebKit a little more hackable now. :) Enjoy, 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] Tightening up our include discipline
For the specific case of Event, we do need some sort of poor man's RTTI here for the sake of the bindings, but we could consider alternatives. Since you need to identify the subclasses, you need to either use many virtual functions, as we do currently for Event, or have some tagging mechanism, which we do for classes like Element and EventListener. If we use a tagging technique, we need someway to ensure that the tags are unique. In EventListener, we list the types up front in an enum, though this has same downside as the many virtual functions in that the tendrils of WebAudio reach into the base class. For Element, we rely on qualified names, which doesn't require the icky reach, but are slightly more costly. (You still end up with the tendrils in the JS base class). Of course, it might make sense to solve the issue of #ifdefs in Event by simply removing the #ifdefs in Event, since they are just base class implementations. The only downside of that is if we later remove the feature, it is harder to find all the places it touched. -Sam On Oct 18, 2011, at 4:37 PM, Adam Barth wrote: The other day, Sam chided me on a bug for including a header from WebCore proper in a file in WebCore/platform. Even though I know I'm not supposed to do that, it's an easy mistake to make. There's some work going on in https://bugs.webkit.org/show_bug.cgi?id=49192 to improve the style checker to flag these sorts of bad dependencies. This check isn't live yet, but don't be surprised if some robotic user complains about a bad include in one of your patches. (As always, if the bot complains incorrectly, please let me know so we can eliminate false positives.) Relatedly, as part of the recent ENABLE cleanup effort, I noticed that some files (e.g., http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Event.cpp) attract lots of ifdefs because many unrelated features need to register themselves. I was thinking it might be an improvement to restructure things a bit so that, for example, WebAudio wouldn't need to reach its fingers into Event.cpp and instead could be better contained in the WebCore/webaudio directory. I welcome any thoughts you have on either of these topics. 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] Tightening up our include discipline
I'd be interested in performance cost to that, especially on a test that creates a lot of JS wrapped Events. -Sam On Oct 18, 2011, at 6:42 PM, Adam Barth wrote: My thought on that is to use a single virtual function and return an atomic string, like we do for elements. Adam On Oct 18, 2011 6:10 PM, Sam Weinig wei...@apple.com wrote: For the specific case of Event, we do need some sort of poor man's RTTI here for the sake of the bindings, but we could consider alternatives. Since you need to identify the subclasses, you need to either use many virtual functions, as we do currently for Event, or have some tagging mechanism, which we do for classes like Element and EventListener. If we use a tagging technique, we need someway to ensure that the tags are unique. In EventListener, we list the types up front in an enum, though this has same downside as the many virtual functions in that the tendrils of WebAudio reach into the base class. For Element, we rely on qualified names, which doesn't require the icky reach, but are slightly more costly. (You still end up with the tendrils in the JS base class). Of course, it might make sense to solve the issue of #ifdefs in Event by simply removing the #ifdefs in Event, since they are just base class implementations. The only downside of that is if we later remove the feature, it is harder to find all the places it touched. -Sam On Oct 18, 2011, at 4:37 PM, Adam Barth wrote: The other day, Sam chided me on a bug for including a header from WebCore proper in a file in WebCore/platform. Even though I know I'm not supposed to do that, it's an easy mistake to make. There's some work going on in https://bugs.webkit.org/show_bug.cgi?id=49192 to improve the style checker to flag these sorts of bad dependencies. This check isn't live yet, but don't be surprised if some robotic user complains about a bad include in one of your patches. (As always, if the bot complains incorrectly, please let me know so we can eliminate false positives.) Relatedly, as part of the recent ENABLE cleanup effort, I noticed that some files (e.g., http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Event.cpp) attract lots of ifdefs because many unrelated features need to register themselves. I was thinking it might be an improvement to restructure things a bit so that, for example, WebAudio wouldn't need to reach its fingers into Event.cpp and instead could be better contained in the WebCore/webaudio directory. I welcome any thoughts you have on either of these topics. 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] Style guide should mention that we don't use anonymous namespace
Another benefit to using the static keyword is that you can tell at a glance that the function is internal to the translation unit, while you may not notice the anonymous namespace. -Sam On Oct 19, 2011, at 3:45 PM, Darin Adler wrote: The guideline is not to disallow anonymous namespaces. It’s to prefer “static” over anonymous namespaces when either one would work. Debugging tools on at least some of the platforms work better with functions that are given internal linkage by using the “static” keyword rather than functions that are inside anonymous namespaces. On the other hand, anonymous namespaces are a more powerful tool that can do more than the “static” keyword can. -- 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] EventConstructors.h
It should long term be generated from the EventInit dictionary IDLs, but it was handy to implement it in a macro based DSL initially. -Sam On Nov 2, 2011, at 11:02 AM, Adam Barth wrote: This file seems to be growing a list of ever feature in the project: Source/WebCore/bindings/generic/EventConstructors.h Can we generate this file from the event IDL files? 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] Should WebKit require SQLite?
It seems acceptable to me to require SQLite. -Sam On Dec 3, 2011, at 10:47 AM, Ryosuke Niwa wrote: Hi, Recent removal of OFFLINE_WEB_APPLICATIONS flag in http://trac.webkit.org/changeset/96123 made SQLite a new requirement to port WebKit. However, there are many operating systems and platforms (mostly embedding) into which SQLite hasn't been ported yet; e.g. http://www.monaos.org/. It seems undesirable to increase the number of dependencies since being able to port easily is one of the strengths of WebKit. On the other hand, reducing the number of flags will certainly reduce the build system complexity for people who are already shipping with SQLite. Do we want to require SQLite to port WebKit for the sake to reducing the complexity for major ports? Best, Ryosuke Niwa Software Engineer Google Inc. P.S. I have https://bugs.webkit.org/show_bug.cgi?id=73749 to reintroduce OFFLINE_WEB_APPLICATIONS. ___ 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] About BrowsingContext and WindowProxy spec
On Mar 7, 2012, at 9:25 PM, Darin Adler wrote: On Mar 7, 2012, at 9:34 AM, Adam Barth wrote: The WindowProxy is implemented in WebKit using the WindowShell class. Idle thought: We might want to consider renaming our WindowShell class WindowProxy, just to match the HTML specification concept, as I think we’ve done in a few other cases. -- Darin Yeah, we should do that. Filed https://bugs.webkit.org/show_bug.cgi?id=80733. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?
On Mar 7, 2012, at 4:41 PM, Ojan Vafai wrote: I just did a first pass a greening the Chromium Lion bot: http://trac.webkit.org/changeset/110096. Of these hundreds of tests, ~99% of them are perfect candidates for being reftests (e.g. they contain one line of text and a solid box or two under the text), but most of them are in the CSS imported test suites. Is it kosher to convert them to reftests or should we leave pixel tests from imported test suites alone? If we want to make these ref tests, it probably makes more sense to do that work with the CSS WG, so that they can be part of the standard test suite. Until then, I think we should keep them regular pixel tests. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] 2012 WebKit Contributors' meeting
Apple will once again be hosting a WebKit Contributors Meeting. It will be held at the Cypress Hotel in Cupertino, CA on April 19 and 20. This meeting is for contributors to the WebKit Open Source Project. As with the meeting last year, this event will have an unconference-like format, allowing plenty of time for impromptu sessions/discussions and hacking. The meeting will be free of charge. All WebKit contributors are encouraged to attend. However, space is limited, so registrations will be accepted on a first-come, first-served basis. Please register for the conference using the form at https://www.webkit.org/meeting/ by April 11. When you register, you will automatically be subscribed to webkit-meet...@lists.webkit.org, which will be used for general discussion and to communicate additional information about the meeting. If you have any questions about the meeting, or about whether this meeting is appropriate for you to attend, you may email me at wei...@apple.com. We hope to see you there! Thanks, Sam Weinig ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Throwing SECURITY_ERR on cross-origin window.location property accesses
Hey Dave, Can you describe the use case for this new property? When would an author use it? -Sam On Mar 22, 2012, at 4:16 PM, David Levin le...@chromium.org wrote: Resurrecting a really old thread so continue the conversation now that I'm hitting this issue :). On Mon, Aug 16, 2010 at 2:16 PM, Sam Weinig sam.wei...@gmail.com wrote: I am not sure I agree. Does our behavior actually cause any real bugs in the places you have tracked down? The log spam really doesn't seem like an issue, we can remove it if we want to, but have found it useful in the past. Speaking as someone who working on a web app, the log spam is a significant issue because: It clutters up the console output making it harder to find the real error. (It is hard to explain how much worse this makes the experience until you have to deal with a sophisticated web page. Image looking at the logs from your app and seeing lots of error messages -- many of which are this one and then a real one hidden among them -- from personal experience.) When more sophisticated end users see it, they think there is a problem in the app and report it (and it could be that they include this in their error report and ignore other more important things). I understand that that the console/log spam is useful to detect real issues as well (given that WebKit doesn't throw an exception in this case). Would people find it acceptable to have window.webkitCanAccess so that a web page can use that property first to detect the cross origin issue and avoid doing an access which would trigger the console spam? (I would also be fine with an exception instead of log spam.) Thanks, 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] CSS3 Selectors3 test suite
On Mar 22, 2012, at 6:41 PM, Ojan Vafai o...@chromium.org wrote: I've recently been greening Chromium's expectations for css3/selectors3. ~10% of these test need interaction (e.g. hovering over a link or selecting text). Given that this is an imported test suite does it make sense to add the appropriate layoutTestController hooks? As it is, the tests aren't really verifying correctness. I don't think it is a good idea to change imported suites unless we can do it a non-destructive way (e.g. all tests in this directory get this script added to them). If we want to split up the tests that require interaction from the others, we should do that upstream and see if we can make as many as we can not require explicit interaction. Also, this test suite is a great example of one that I think it would make more sense for us to check in reftest expected results instead of png+rendertreedump. These tests are explicitly testing selector matching only, so it would be easy to write reftests that have a high confidence of accurately verifying correctness. They'd only fail if we had some egregious bug such that we painted everything green as white. Presumably we'd notice such a bug through other means. Again, I think this should happen upstream in the CSS working group. -Sam 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
Re: [webkit-dev] webkit2 with v8
Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemen kbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ 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] webkit2 with v8
Without considerable more demand, I don't think we want this. -Sam On Apr 23, 2012, at 3:20 PM, Balazs Kelemen kbal...@webkit.org wrote: On 04/23/2012 11:53 PM, Sam Weinig wrote: Hi Balazs, This is something we don't want at this time. Dealing with V8 in WebCore is pretty big maintenance burden and one I would rather not have in WebKit2 unless there is considerable demand for it. Well, it's important for Qt. In your patch (attached to https://bugs.webkit.org/show_bug.cgi?id=84457), there are many intrusive changes to core WebKit2 code, making it harder to comprehend and refactor. Also, since a much bigger proportion of developers who develop WebKit2 don't ever compile V8, it seems more likely that the code will stop working. The WIP patch I uploaded is just a very first step to make it possible to build with v8 without breaking the most basic features. I have just overhacked every problematic part - instead of finding a proper solution to them - to see how many dependencies there are on JSC as quickly as possible. It should be way better before uploaded for review. -Sam On Apr 23, 2012, at 3:28 AM, Balazs Kelemenkbal...@webkit.org wrote: Hi everyone, I would like to inform you about the topic I am working on, since it is something that can affect WebKit2 architecturally. I would like to make WebKit2 work with v8. The motivation behind this is that the long term goal of the Qt port is to switch to v8. Qt already use v8 in it's Qml module, and it's better to have only one VM in the framework (less code size, less memory usage, easier maintenance). My goal is to achieve this with the minimal amount of changes made in WebKit2. My plan for WebKitTestRunner is to wrap v8 behind the JavaScriptCore API (or, in another point of view, implement the JSC API upon the v8 API). For the core of WebKit2 we will have to use some bindings for things like plugins or the injected bundle but it should be not too much of a maintenance burden. Inform me if you have any concerns or suggestion. Cheers! Balazs Kelemen ___ 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
