Re: [webkit-dev] Proposal: Add a region-selectable timeline in Web Inspector CPU profile panel.
On 3/5/13 6:41 AM, Deng, Pan wrote: ... For JS CPU-profile panel, I think a selectable region that allow exploring any part of aggregated data is a helpful, that is a different view from breakdown details. And it is also common used among profilers, ... It seems like profiling is an area that would benefit from additional experimentation from users. For instance, see my experiments with rsprofiler: http://pmuellr.github.com/rsprofiler/ Interesting that I was able to build this just from console.profile(), console.profileEnd(), and then accessing console.profiles for the profiling data. This only works for Safari though. I never seem to get more than the head node from Chrome. I suspect the data in console.profiles would also be a different format between Safari and Chrome, as Safari seems to be making use of dtrace for their data collection, and presumably Chrome wouldn't (at least, say, on Windows). So it would be nice to have that data standardized. Or at least the head node from the profile data could indicate the style/format of the remainder of the profile data (eg, counts vs samples - or maybe safari-2.3 vs chrome-1.7). The last bit is making it easier for developers to be able to visualize their profiling data however they want to. For Chrome, I think the easy story there is to make the data available via the Chrome Dev Tools extensions points. I don't think Safari has extensions for Web Inspector (like Chrome does for Dev Tools). So, everyone but Chrome users would be stuck doing the nasty bits I did for rsprofiler. But someone could write a Chrome extension to create a new panel to start/stop profiling, and then render the visualization of the data how they want. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Any objections to switching to Xcode 3.2.4 or newer?
On 10/6/10 8:00 PM, Darin Adler wrote: For those working on Mac OS X: Any objection to upgrading to Xcode 3.2.4? It’s now showing up in Apple’s Software Update for all Xcode users, I believe. I opened https://bugs.webkit.org/show_bug.cgi?id=62011 to get the web site updated to indicate = 3.2.4 is now required. Also noted that there should be an indication of whether XCode 4.x can be used for daily development. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
On 5/20/11 1:51 PM, Maciej Stachowiak wrote: Presumably the embedding application would need to require explicit user consent to enable the feature. I understand that we have to keep a balance, and statistical fingerprinting is already dismayingly effective without any new features. However, enable[d]-by-default with a hidden pref to disable sounds like an extremely weak approach to protecting user privacy. I can't speak to the security or insecurity of enabling the Resource Timing APIs. However, I'll note that I see this API as part of the diagnostic side of WebKit, just like the Web Inspector debugger. In the case of the Web Inspector today, it requires explicit user consent to enable the feature - you need to perform a UI gesture to open the debugger (hot key, menu item, etc). Besides Resource Timing and Navigation Timing, hopefully in the near future, all our WebKits will have remote debugging enabled: http://www.webkit.org/blog/1620/webkit-remote-debugging/ So there's another case where we will need some kind of explicit user consent to enable the feature. I wonder if we could lump all this stuff together into a single diagnostic mode run-time guard. Turn it on, all the diagnostic, perhaps dangerous, API and capability is available. Turn it off - and it's off by default - and dangerous API and capability is not available. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New Feature - Resource Timing
On 5/20/11 12:46 PM, Alexey Proskuryakov wrote: What incentive will users have to enable it? For other privacy sensitive features (be it cookies or geolocation), there is a clear benefit to gain from them. This is a developer-mode feature. There is no direct incentive for end users to enable something like Resource Timing. However, it's not hard to imagine a site suggesting that people could enable Resource Timing, and have that timing information sent back to the site for analysis, much the same way many programs today allow users to opt-in to sending diagnostic information back to a server somewhere. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit Inspector - Working with Breakpoints
On 3/2/11 4:25 PM, Charles Pritchard wrote: By enriched I mean: I'd like to be able to save and/or load breakpoints. So, you'd like to be able to save some set of breakpoints (all the ones currently enabled?) into a file, and be able to reload it later? This seems like a good candidate for a debugger extension, whenever that facility comes on line. Doesn't seem like it would be useful enough function to build into the base. And I'd like to be able to inject code into a breakpoint. Have you looked at the existing conditional breakpoint support? Right click over a breakpoint. I think this facility can be abused to do what you want. BTW, feel free to open bugs on these, of course: http://webkit.org/new-inspector-bug -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Remote debugger
On 2/18/11 1:31 PM, Joseph Pecoraro wrote: ... In addition to everything Joe mentioned, there's also a project to reuse Web Inspector for node.js debugging: https://github.com/dannycoates/node-inspector -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Getting CC-ed on webkit.org/new-inspector-bug
Anything like this, PLEASE! The worst part, for me, is having to find that web inspector URL, and then giving it out to people. I just posted it on Twitter today, in fact. I cringe whenever I do. Eclipse also uses something like what Darin suggested, worked great for me, back in the day. On 2/9/11 12:53 PM, Darin Fisher wrote: You can also introduce a dummy email address, and then interested folks can use bugzilla's email preferences to watch that email address. This is perhaps a more lightweight version of using a mailing list as there is no mailing list. It was very common to use this approach on bugzilla.mozilla.org, with each component in the system having its own dummy email address auto-added. This allows developers to subscribe / unsubscribe from receiving email for various components in the bug system. -Darin On Wed, Feb 9, 2011 at 9:32 AM, Pavel Feldmanpfeld...@chromium.org wrote: Hi WebKit, As you might know, we have a shortcut to the inspector bug entry form: webkit.org/new-inspector-bug. We use it all over the place, our users like simplicity it introduces. However, we ended up with 10 (and counting) people on the CC list. Fixed CC list has obvious drawbacks: - each time we want to add / remove a person from the template, we need to make explicit request - new guys don't get updates when old bugs change - old guys get updates even though they are not interested anymore. Can we migrate to a more flexible approach (such as introducing webkit-inspec...@lists.webkit.org) where we would be able to subscribe / unsubscribe? _wms suggested that we discuss it here first. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Web Inspector blog post draft
I'm logged in (as near as I can tell - link at the bottom says Log out), and still get the error. I don't have posting rights to the blog, nor do I want them. On 2/9/11 2:20 PM, Adele Peterson wrote: You have to be logged into the blog to read drafts. -- Patrick Mueller - http://muellerware.org ___ 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 6/5/10 5:24 AM, Mikhail Naganov wrote: Can you please provide more info on how native APIs can be used for reporting memory usage data? That is, how a web app can signal that a measurement is needed to be taken at a certain point in its code? For a specific example, today, you can use console.markTimeline(message) to have an entry added to the debug time line. May not be the measurement you were looking for ... :-) But this raises a distinction - it's probably ok to allow functions like console.markTimeline(message) (and any other sort of diagnostic related function) as long as they don't actually do anything unless you are debugging. It's not clear to me that's the case today for markTimeline(), nor whether it's a problem if it actually does do something if you aren't debugging - all of the console APIs probably need to be looked at. On Fri, Jun 4, 2010 at 23:26, Sam Weinigsam.wei...@gmail.com wrote: On Fri, Jun 4, 2010 at 12:02 PM, Ojan Vafaio...@chromium.org wrote: On Fri, Jun 4, 2010 at 11:27 AM, Sam Weinigsam.wei...@gmail.com wrote: 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. I talked to a developer a few months ago that was building a system to collect profiling information in an 'as automated fashion as possible'. He wanted to collect the information over time for analysis. Makes sense to me. I believe he was using console.profiles() for this - across FireBug and WebKit. This was all user-land code; they were collecting the information and uploading it back to their site for later analysis. Use Case! You could argue this can be solved by tools, but as someone who has been in the tools vendor business for a long time, I can tell you if your answer is you just need tools, you're not going far enough. Smart developers prefer APIs so they can build their own tools. I agree we need to secure this stuff, it is obviously not of interest to 99.99% of the end users of WebKit, but it's invaluable to the 0.01% out there. If we found a way to secure this, could we use a pattern of adding APIs like console.profiles() secured by that mechanism? As for the use case above, the app collecting the information was a specially built application used only by developers. I suspect they'd be willing to deal with any extra overhead or ickiness in allowing this secured use, assuming it could eventually be automated. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Need more diagnostic information for ApplicationCache events
After some frustrating experiences using AppicationCache for some private, but field-tested apps, I'd like to see some additional information provided in the ApplicationCache events. I posted down some thoughts here: http://bit.ly/9Bfjeh [whatwg ml] Seems like these would be a good candidate for an experimental feature. Did anything ever happen regarding formalizing or just organizing thoughts around experimental features, after the Contributor's Meeting last month? -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
Alexander Limi wrote: Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. I happened to open a bug on this, early this morning: https://bugs.webkit.org/show_bug.cgi?id=31621 WebKit already supports something similiar - webarchive's. Main difference being that webarchives contain the main resource as well as the sub-resources. Perhaps some of the same machinery can be reused there though. Though ... makes me wonder ... why not have a mode of supporting the main resource as well? Go from two downloads down to one. You'd just need a convention for specifying the main resource in the .zip file ... -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit on the server side
Sergiy Temnikov wrote: Hi, We are working on a new application server that uses WebKit for server-side JavaScript execution (and remote JavaScript debugging too). ... For example, the first thing we had to deal with is the JS debugger. Debugger interface is defined in JavaScriptCore but its implementation lives in WebCore. Most of the debugger's implementation is abstract except for the part which sends event notifications to pages and frames objects which are GUI dependent and so can not be used in a faceless server application. So we basically copied the source of the existing debugger, commented out GUI related calls and added some stuff to transform it into a debugger which can be controlled remotely over the network. I would be happy to contribute to the WebKit project to add a layer of abstraction to the existing debugger implementation to cut its dependence on GUI and move it to JavaScriptCore from WebCore's inspector. It would be interesting to see this. Open a bug and contribute a patch. There's two reasons I think this is interesting: - would be useful for embedded clients. For instance, if this is the current state-of-the-art for debugging Palm's WebOS apps, which are (in my understanding) running in WebKit - http://is.gd/4RKuh - then a remote debug interface would be incredibly useful, assuming you had a nice client. - just cleaning up the interfaces between the debugger and debugging clients to begin with would probably be useful. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSON.stringify(Date) losts the milliseconds information
白石俊平 wrote: I tried to use the JSON.stringify() for Date object on Safari4 and WebKit nightly build(48096), so I got result as follows. JSON.stringify(new Date()); 2009-09-07T04:49:43Z This result seems that milliseconds information of date is lost. For some applications, millis info is important and this behavior may be problem. On the other hand, a while back I remember looking at a number of date parsing libraries that clearly weren't going to be able to handle milliseconds in RFC 3339 / ISO 8601 formatted dates. At the time, I recommended for the project I worked on that we never generate such dates with the millisecond format. It wasn't critical that we used them, so it was an easy decision for us to discard them. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] unwritten rules of webkit style
Darin Adler wrote: On Sep 2, 2009, at 5:00 PM, Cameron McCormack wrote: I’ve noticed a couple of different ways of writing subsequent copyright lines, e.g.: Copyright (C) 2005 Somebody email 2006, 2007 Somebody Else email — http://trac.webkit.org/browser/trunk/WebCore/svg/SVGSVGElement.cpp and: Copyright (C) 2005 Somebody email Copyright (C) 2006, 2007 Somebody Else email — http://trac.webkit.org/browser/trunk/WebCore/svg/SVGFilterElement.cpp I think the second format is the one we should use. IBM actually has rules about what the copyright statements should look like (surprise surprise) for our own copywritten material, and so I applied it for a recent set of changes to WebCore/inspector/front-end/ResourceView.js: * Copyright (C) 2007, 2008 Apple Inc. All rights reserved. * Copyright (C) IBM Corp. 2009 All rights reserved. I'll be first to say ... ick ... And I'll also note that it's unlikely anything horrible will happen to me if I was forced to use some other format instead (like what everyone else is using, for instance). But other folks may not be so flexible. I'm thinking we probably be need to be flexible about the format of the line, perhaps strongly suggest the current format as the format to use. And I certainly agree that the second form is better. I can imagine a lawyer getting upset if they don't see the Copyright (C) on a line where they expect it (OMG - YOU DIDN'T COPYRIGHT IT!!!) -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Maciej Stachowiak wrote: - New media elements: audio, video We love these and have them implemented. We don't see any implementation issues in the current spec. I played with the audio support about a month ago, and was unpleasantly surprised to find that if you loop audio there is a noticeable delay (sub-second, but very noticeable) between when the audio clip ended and then started again, in WebKit nightlies on the Mac. I posted a Q on the whatwg ml as to whether there was an intention that looped audio (and video, for that matter) should be seamless. Got various responses. AnneK responded that the intention was for it to be seamless. Ian responded that large clips couldn't be guaranteed to be buffered enough to make seamless audio a requirement. So there's some wiggle room in the spec. And of course, since the implementation of the audio support is a platform issue, not much we can do about this to magically make audio seamless for every platform. Still, seamless looping seems like something webkit ports should strive for. As an example, paste this into the snippet editor audio src=http://is.gd/2zHIy; autoplay=true loop=true You'll hear 4-5 seconds of static, then it pauses before it restarts. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementation thoughts on HTML5 elements
Simon Fraser wrote: On Aug 26, 2009, at 6:11 AM, Patrick Mueller wrote: As an example, paste this into the snippet editor audio src=http://is.gd/2zHIy; autoplay=true loop=true You'll hear 4-5 seconds of static, then it pauses before it restarts. Did you file the two bugs necessary here (hearing static, and non-seamless looping)? Ryan is correct; you are SUPPOSED to hear static. That was the first clip I found on the web this morning that would demonstrate the issue. Maciej has also suggested filing a bug, so I'll do that. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Reporting exceptions from worker context to users
Drew Wilson wrote: OK, I really wanted to gloss over this, but now Jeremy's going to make me elaborate :) There are a few things I think we will eventually need to support worker development: 1) Some way to print out the values of things in a worker's global scope. 2) Similar debugging support for workers that we have for page script (breakpoints, etc). 3) When the user is selecting a worker for #1/#2, it might be useful to indicate what the parent(s) of the worker are to help developers select the right worker (in case there are nested workers). Or maybe it's not very useful - perhaps just having the URL of the worker base script is sufficient. We don't know yet. What immediately comes to mind here is the Eclipse Java debugger. Single window that shows a list of connected VMs. Each VM contains a list of threads. In the Web Browser World, thread might correspond to worker, and perhaps would be a tree of workers instead of list of threads, to indicate nesting. The current story with Web Inspector is that a Web Inspector is associated with a window object. So the concept of supporting muliple windows like Eclipse supports multiple processes wouldn't make sense. Doesn't rule out supporting it in the future though - a single Web Inspector window instead of multiple. And someone might want to make a stand-alone JS debugger with the inspector code, that could somehow connect to multiple running JS engines simultaneously. Then the rest of the Web Inspector story, as far as the Scripts panel, works the same. Instead of just selecting a frame to operate on, you will also have a worker (or the main thread) to select on. Selecting a new worker changes. Presumably we'd change the Call Stack section, or add a new section above Call Stack called Worker (not a great name, but you know what I mean). I suppose we should open an enhancement bug ... -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Some new mailing lists
Maciej Stachowiak wrote: Based on popular demand, we have created two new mailing lists to handle some content that's off-topic for webkit-dev. The new lists are: webkit-help -- requests for help with building webkit, using WebKit's APIs, embedding WebKit, porting WebKit, and so forth I suggest that anyone who would like to help others with WebKit topics that aren't about the development of WebKit itself, or people interested in asking such questions, should subscribe. We will gradually migrate this kind of material off of webkit-dev. webkit-jobs -- post about WebKit-related jobs. I suggest that anyone who would like to post or hear about WebKit-related employment opportunities should subscribe. Excellent. Can we get these added to gmane as well? -- Patrick Mueller ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should we put the webkit.org mailing lists on Gmane?
Adam Roben wrote: Given the single vote in favor and no one opposed, I'm going to work on this today. -Adam On Jun 15, 2009, at 4:52 PM, Gustavo Noronha wrote: On Sat, 2009-06-13 at 09:00 -0400, Adam Roben wrote: Gmane (http://gmane.org) provides a few features that could be useful for thewebkit.org mailing lists, including: * a nicer web interface than Mailman's * indexed search (maybe better than Mailman's, certainly at least as good, and with a better interface) Belated +1. I'm already following one list on gmane.os.opendarwin.webkit.devel . Not sure which list that maps to. I guess you want to get that one renamed to the new standardized names. I imagine you will have to make some kind of special request for that. My experience has been that it can take a while for gmane to pick up new requests, so, be patient. -- Patrick Mueller ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] when can I treat a JSValueRef as a JSObjectRef?
Since JSValueRef and JSObjectRef are typedef's to the same OpaqueJSValue structure (pointer), it appears you could almost use them in the same contexts. And if fact, it appears you can use a JSObjectRef wherever a JSValueRef is defined in the API. And you can sometimes use a JSValueRef wherever a JSObjectRef is defined. It would be nice to see this documented a little better. My current guess is that if JSValueGetType() returns kJSTypeObject for a JSValueRef, you can safely treat it as a JSObjectRef. If it doesn't, then you can't. Guess is based on looking at the code, seeing the pointer dereferenced in the JSObjectRef cases, but knowing that those pointers are actually sometimes tagged pointers for literal values, in which case the dereference won't work. -- Patrick Mueller ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] when can I treat a JSValueRef as a JSObjectRef?
Darin Adler wrote: What documentation were you reading? Since WebKit is an open source project, if you have improvements to, say, the comments in the header, you can submit them as a patch. Most of the mechanics are covered at http://webkit.org/coding/contributing.html, although some of the steps don’t apply for changes that are entirely in comments. If this was some Apple documentation you were reading, not generated directly from the header file, then you could instead file a bug at http://bugreport.apple.com suggesting improvements. Thanks for the quick reply. The docs I was reading were in fact the Apple docs, which AFAIK are the only docs for JavaScriptCore. When working at the API level, I try to stick to docs instead of code, but sometimes I cheat :-) Actually, I learned a lot by printing out pointer values, without even looking at the impl. Maybe it would make sense for webkit.org to host something similar to the apple docs, located here, http://developer.apple.com/documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/ so that mortals could contribute back to that level of documentation. At the minimum, I suspect the turn around time in getting changes to such doc would be quicker than going through official Apple support. I'll file a report at the apple site in the meantime though. -- Patrick Mueller ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] browser extensions
Now that the Chrome folks have talked about extensions, I thought I'd ask what the story/plan is for WebKit. http://www.aaronboodman.com/2009/04/content-scripts-in-chromium.html So ... I guess the first question is, are extensions considered out-of-scope for WebKit? As in, more of a browser thing than a toolkit thing? It's easy to see this going either way; 'portable' extensions will be hard, especially given any browser specific things you might want extensions to do; on the other hand, having all the WebKit consumers out there having a common extension story would obviously be very useful. As an alternative to a full-on extension story, or maybe in addition to, you could look at the way inspector is implemented as a form of extension, perhaps just applicable for use by folks actively developing products with WebKit, as opposed to consumers of those products. I haven't looked deep enough into inspector to see if it's built on some extensibility story or not. I perused the wiki and web site in general, didn't notice any discussion on this, but of course, just point me to it if it's already there. -- Patrick Mueller ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] browser extensions
Yup, it's easy to draw the line of what goes into WebKit for things like browser extensions. It does kind of raise the question whether there should be some other layer between (alongside?) WebKit and user agents, where things like extensions, debuggers, etc, might live. Aaron Boodman wrote: Extensions logically fall outside the boundary of the rendering engine, and that is the way we've approached in Chromium, too. But since Chromium extensions are basically just web pages with a few extra APIs added, there is a relatively obvious path to compatibility and even sharing code if other browsers ever wanted to adopt them. - a On Wed, Apr 15, 2009 at 9:06 AM, Patrick Mueller pmue...@muellerware.org wrote: Now that the Chrome folks have talked about extensions, I thought I'd ask what the story/plan is for WebKit. http://www.aaronboodman.com/2009/04/content-scripts-in-chromium.html So ... I guess the first question is, are extensions considered out-of-scope for WebKit? As in, more of a browser thing than a toolkit thing? It's easy to see this going either way; 'portable' extensions will be hard, especially given any browser specific things you might want extensions to do; on the other hand, having all the WebKit consumers out there having a common extension story would obviously be very useful. ... -- Patrick Mueller ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JSxxxRelease/Retain - some guidance?
Darin Adler wrote: Here’s a little more beyond what Maciej said: ... JSClass, JSContextGroup, JSGlobalContext, JSPropertyNameArray, and JSString are all reference counted, not garbage collected. The functions that return these objects follow the The Create Rule, borrowed from CoreFoundation http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html. Perfect. I was looking for a link like that. I posted a feedback note in ADC that the JSC doc should include that link. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
