Re: [webkit-dev] Magic Iframe removal proposed
I actually do know of at least one WebKit-only application under development at Google that may be using this feature (I recently suggested it to them). Oh well. - a On Tue, Mar 20, 2012 at 8:07 AM, Adam Barth aba...@webkit.org wrote: Yeah, normally I would have waited longer, but the patch fixed a crash in WebKit2 that was making the bots red. There was a discussion in another bug (sorry, don't have the link handy) where folks graciously held off fixing the crash, and I didn't want them to wait any longer than necessary. Adam On Mar 20, 2012 1:31 AM, Maciej Stachowiak m...@apple.com wrote: I'm ok with removing this feature for the reasons you described. I concur with others who think we should update the spec. I am also skeptical of state sharing features that work via newer, less tested API surface instead of latching onto existing features. That seems like a more risky strategy since it may be harder to remove such a feature without compat breakage, and it's not clear how it makes the security problems even easier. As a side note, this probably should have had more discussion time before being actually committed. If a change is worthy of webkit-dev discussion in the first place, then 5 hours between initial webkit-dev post and committing the patch is cutting it a bit short. Especially when it is outside normal working hours in the time zones where most WebKit contributors live. I don't want to harp on this too much, since I don't personally disagree with the change, but if anyone does, then they may feel that they didn't really get a fair chance to comment. Regards, Maciej On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted for removal of the 'magic iframe' feature. This is the ability to move 'live' iframe from one page to another w/o unloading it. If you have interest or ideas about this feature, please reply. HISTORY This feature was added 2 years ago (bug here). It was intended as a shared app context for complex apps that span several pages. In case when random set of pages is closed, the surviving iframe could be passed between remaining pages and serve as 'app state'. This behavior is somewhat described in HTML5 spec: Removing an iframe from a Document does not cause its browsing context to be discarded. Indeed, an iframe's browsing context can survive its original parent Document if its iframe is moved to another Document. All non-WebKit browsers don't have this and always unload the iframe when it is disconnected form the document. PROBLEMS We did have quite a few issues with this mechanism. The root of the problem seems to be that traditionally, multiple 'permissions' and 'live objects' are associated with a top-level page, or a top frame of some kind, instead of being associated with each Frame. Even HTML specifications often formulate the scope of things like permissions in terms of a page - for example, geo permissions are computed based on the origin of the page. When an iframe is transferred from one page to another, it may enter a different set of permissions while already performing operations authorized before. Association with the top-level page is also used to determine which one should show modal UI for HTTP Auth, per-origin permissions, or certificate issues for example. As a result, we had quite a few bugs popping up (and fixed). WHY REMOVE This is somewhat obscure feature of the platform. Only a few apps that we knew used the feature. Most developers, both app and webkit kind, don't even know about it. When new mechanisms/APIs are implemented, a lot of objects get associated with Page (WebView) level and they are almost 'automatically' broken in case of live iframe transfer because once old page closes, it destroys the objects with lifetimes scoped by it. This makes it somewhat dangerous and difficult to support. The benefits that it gives to the big multi-page applications do not seem to warrant the actual complexity of maintaining this feature. Other browsers never implemented the feature, siting difficult design due to various thorny security issues as well. This is potentially a compatibility issue for sites that use document.adoptNode(iframe) to ensure live transfer of an iframe from one page to another. In the future, if there will be sufficient need, it is possible to design a 'shared module' feature that would explicitly deal with various security/lifetime boundaries. Please let us know what you think. 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 mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] Moving to Git?
I think it would look the same, except for instead of monotonically increasing decimal numbers in the revision column, you'd see random hexadecimal ones (typically 6-8 digits long). On Thu, Mar 8, 2012 at 4:20 PM, Lucas Forschler lforsch...@apple.com wrote: Could someone enlighten me on what this page would look like after a conversion to git? http://build.webkit.org/builders/Windows%20Debug%20%28Build%29?numbuilds=100 Lucas On Mar 8, 2012, at 3:22 PM, Dirk Pranke wrote: On Thu, Mar 8, 2012 at 2:37 PM, David Barr davidb...@google.com wrote: The monotonic labels that Ryosuke desires are known in git language as generation numbers. If we maintain a canonical linear history going forward, they would also be unique as with Subversion. This could be a good reason to resurrect the relevant thread on the git mailing list. slightly-offtopic, but I had not heard of generation numbers before. Based on a cursory web-learning pass (*), it sounds like they're not quite the same thing as SVN revisions, since SVN revision numers are unique to a repo, and two revisions on two different branches may have the same generation number. Since we do actually keep branches in the master repo, this wouldn't quite be the same (although it might possibly be acceptable). Please correct me if I'm wrong ... -- Dirk (*) http://stackoverflow.com/questions/6702821/git-commit-generation-numbers ___ 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] Removing HTML notifications from WebKit (Was: Web Notifications API)
Hello again, I'd like to revise my proposal on deprecating HTML notifications in Chrome extensions: I would like to make the feature runtime-enabled, and leave it enabled for Chrome extensions until there is a suitable replacement. Once we have a replacement, we can follow the deprecation plan I sketched earlier. It sounds like the Chrome web platform team is more OK with the idea of removing it from web content. Having the runtime switch would make it easy to implement both policies. I understand that having this code is a tax on the WebKit project, but it seems pretty small compared to other things that have been left in for other clients. - a On Mon, Feb 13, 2012 at 11:23 AM, Maciej Stachowiak m...@apple.com wrote: This plan sounds reasonable to me. No disruption of Chrome extensions in the short term, but we would better align with each other and with standards in the longer term. Jon? Regards, Maciej On Feb 9, 2012, at 2:48 PM, Aaron Boodman wrote: On Wed, Feb 8, 2012 at 7:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote: On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee jon...@apple.com wrote: 2. Remove HTML notifications. It has been removed from the spec, and we don't intend on ever supporting HTML notifications. I brought this issue up before; is there an update on this front from any other platforms? HTML notifications are a pretty popular feature in Chrome's extension system. As of a few months ago: * 614 extensions in our web store use createHTMLNotification * 72 have more than 10k users * 14 have more than 100k users * 3 have more than 500k users * 6.7M total actextension installs We can move developers off of this API, but not overnight. Is it possible to come up with a slower deprecation plan than immediately? Since HTML notifications are already under a separate feature flag, it's probably practical to keep them around for a while, and just not include them in the proposed updated API. Do you have a suggestion for what might be a reasonable deprecation timeline? Awesome. Here is a rough plan of how deprecation could work: 0 months: Add a new extension format version and remove HTML notifications support with that version. 2 months: Support for the new format version is in Chrome's stable channel. The documentation advises the new format version, and new features require it. 4 months: We start requiring the new manifest version for new extensions uploaded to the store. 8 months: We start requiring the new manifest version for updates to existing extensions in the store. 10 months: Remove support for the old manifest version from trunk of Chrome. I believe at this point, we can remove the code from WebKit. We've never actually done this before though, so there may be some hiccups. I'd plan on about a year. We have already started a new manifest format version for Chrome 18, hopefully I can squeeze this change into that release. On Wed, Feb 8, 2012 at 9:24 PM, Adam Barth aba...@webkit.org wrote: Unrelated to timeline, it might be worthwhile to make createHTMLNotification a runtime-enabled feature so that we can avoid offering it to the web at large and possibly restrict it to only a whitelisted set of extensions. This is a very good idea. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)
On Wed, Feb 8, 2012 at 7:50 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote: On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee jon...@apple.com wrote: 2. Remove HTML notifications. It has been removed from the spec, and we don't intend on ever supporting HTML notifications. I brought this issue up before; is there an update on this front from any other platforms? HTML notifications are a pretty popular feature in Chrome's extension system. As of a few months ago: * 614 extensions in our web store use createHTMLNotification * 72 have more than 10k users * 14 have more than 100k users * 3 have more than 500k users * 6.7M total actextension installs We can move developers off of this API, but not overnight. Is it possible to come up with a slower deprecation plan than immediately? Since HTML notifications are already under a separate feature flag, it's probably practical to keep them around for a while, and just not include them in the proposed updated API. Do you have a suggestion for what might be a reasonable deprecation timeline? Awesome. Here is a rough plan of how deprecation could work: 0 months: Add a new extension format version and remove HTML notifications support with that version. 2 months: Support for the new format version is in Chrome's stable channel. The documentation advises the new format version, and new features require it. 4 months: We start requiring the new manifest version for new extensions uploaded to the store. 8 months: We start requiring the new manifest version for updates to existing extensions in the store. 10 months: Remove support for the old manifest version from trunk of Chrome. I believe at this point, we can remove the code from WebKit. We've never actually done this before though, so there may be some hiccups. I'd plan on about a year. We have already started a new manifest format version for Chrome 18, hopefully I can squeeze this change into that release. On Wed, Feb 8, 2012 at 9:24 PM, Adam Barth aba...@webkit.org wrote: Unrelated to timeline, it might be worthwhile to make createHTMLNotification a runtime-enabled feature so that we can avoid offering it to the web at large and possibly restrict it to only a whitelisted set of extensions. This is a very good idea. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)
On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee jon...@apple.com wrote: 2. Remove HTML notifications. It has been removed from the spec, and we don't intend on ever supporting HTML notifications. I brought this issue up before; is there an update on this front from any other platforms? HTML notifications are a pretty popular feature in Chrome's extension system. As of a few months ago: * 614 extensions in our web store use createHTMLNotification * 72 have more than 10k users * 14 have more than 100k users * 3 have more than 500k users * 6.7M total actextension installs We can move developers off of this API, but not overnight. Is it possible to come up with a slower deprecation plan than immediately? - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top 100 sites browsing tests proprosal
On Sun, Jan 22, 2012 at 12:00 PM, Peter Kasting pkast...@google.com wrote: On Sun, Jan 22, 2012 at 11:55 AM, Balazs Kelemen kbal...@webkit.org wrote: As the goal is to test real world use case I think it can be even better to simply load the sites from network. I see only two disadvantage of that but neither of them are blocker: 1. The sites changing over time. However, as this would be a smoke test (and not a regtest or a perf test) I don't think it's a big problem 2. Cannot test offline. Well, I don't think taking part in the development of WebKit is possible without being online anyway :) Do you see other disadvantages? Loading over a network connection is slower. Especially if you expect developers to run these tests locally, this could be a serious time sink. Loading real-world sites over a real network connection adds numerous possible flakiness/failure sources. I would never use something like this as part of an automated system. Arguably, it's not kind to site authors to constantly reload their real sites as part of an automated testing program. From experience using offline copies of popular sites for testing in both Firefox and Chrome, I strongly suggest you go the offline route. How would you capture and replay websites offline? This is non-trivial. In Chromium, we have --record-mode and --playback-mode flags for this use case. They put the cache, cookie jar, and some other components into a special mode where everything is aggressively captured and replayed without going to the net. In the case of Firefox, I believe someone at one time implemented a Firefox extension that rewrote pages to capture resources and use local references. Since most websites are not redistributable, it seems like you need some code like Chromium's or Firefox's in WebKit in order to make this proposal work with offline data. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: coding style and comments
On Mon, Jan 31, 2011 at 12:47 AM, Ryosuke Niwa rn...@webkit.org wrote: How can we ensure that all comments are up to do date? For example, suppose function A calls B, and B calls C. Then in the call site of A, I comment Because A does X, we do Y. Now suppose for the moment that the behavior X of A is implemented by C. We then come back and modify C, thereby modifying the behavior X of A to X'. We suddenly have a wrong comment in the call site of A and we need to fix it! But how do we know that if the patch only changed one line in C? It seems like the one line patch to C just broke A. It had a dependency on the behavior of C that was worth documenting. Now you have changed C and the behavior of A is probably wrong (or at least wasteful). If you had the comment, at least a grep of the source would have found the dependency and alerted you that it was worth looking at this call site. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: coding style and comments
On Mon, Jan 31, 2011 at 5:23 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jan 31, 2011 at 4:54 PM, Aaron Boodman a...@chromium.org wrote:
It seems like the one line patch to C just broke A. It had a
dependency on the behavior of C that was worth documenting. Now you
have changed C and the behavior of A is probably wrong (or at least
wasteful).
Not necessarily. X' might be better a behavior and Y might no longer be
needed because of that.
That is exactly my point. Either way the one line change leaves orphan
code. Having a comment just improves your chances of finding it
(assuming the comment references the depended-upon code).
If you had the comment, at least a grep of the source would have found the
dependency and alerted you that it was worth looking at this call site.
I don't think so. How do I know that modifying C would have changed the
behavior of A?
To be specific, I'm talking about this situation:
void doA() {
// We don't need to frobulate here because doC() already did that.
}
void doB() {
doC();
}
void doC() {
.. complicated stuff ...
}
Now if someone comes along and changes doC, they will probably grep
for the call sites to update them. That grep would find the comment in
doA() too, bringing attention to the tricky indirect relationship.
Without the comment, the relationship would be harder to find.
This was a very simple example with only one indirection,
namely, B. But in the example I posted earlier (moveParagraph), a function
calls hundreds of thousands of functions and it's virtually impossible even
to enumerate all functions depended by the function. Yet, we must worry
about the side-effects caused by the function in a call site.
And we have tons of functions like this in editing because of the nature of
what it does. So I insist on my point that keeping comments up-to-date is
really hard if not impossible.
I'm not suggesting there should be a rule that all side-effects are
commented, that is clearly ridiculous. It is a matter of judgement to
determine when something warrants explanation. Typically it would be
when something is working in a way that is surprising or unexpected.
For example, moveParagraph() ends up calling lots of functions that
have lots of side-effects. Yet those shouldn't be surprising to
someone familiar with how editing works at a high level (note: this is
where class-level comments are super useful), so they shouldn't
require a comment.
- a
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] coding style and comments
On Mon, Jan 31, 2011 at 7:18 PM, Peter Kasting pkast...@chromium.org wrote: P.S. I agree with you about assertions being better than comments to document pre- (and post-) conditions (where possible). Me too (where possible). - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] bugs.webkit.org autocomplete
Ojan could also autoupdate the extension to be a noop. - a On Tue, Sep 14, 2010 at 7:10 PM, Adam Barth aba...@webkit.org wrote: Hi webkit-dev, I just landed a change to bugs.webkit.org to autocomplete email address for committers and reviewers. If you've been using Ojan's awesome extension, it's the same code, just now natively part of bugs.webkit.org thanks to William Siegrist being awesome. (Note that if you have the extension installed, you'll probably want to uninstall it so that it doesn't fight with the native feature.) Let me know if you have feedback on the feature. If you notice that it's missing someone or has the wrong email address, please update http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/config/committers.py. The autocomplete list will update automagically instantly. 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] Name nitpick: layout tests
On Mon, Aug 2, 2010 at 9:40 AM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 2, 2010 at 7:33 AM, Dan Bernstein m...@apple.com wrote: On Aug 2, 2010, at 4:28 AM, Alexey Proskuryakov wrote: 29.07.2010, в 10:59, Darin Adler написал(а): The directory should be eventually be named Tests or WebKitTests or RegressionTests. Ideally, the directory will have a unique first letter for better tab completion - so WebKitTests is a poor option from that point of view. I like the other two. Tests collides with Tools (which is what WebKitTools should be renamed to). That sounds like a vote for RegressionTests I know I'm new around here, but my .02: This seems like a lot of busy work that will never really complete. We'll end up with LayoutTests in some places and RegressionTests in others, indefinitely. It will be even more messy than having the bad name consistently. Keep in mind that there are places that refer to WebKit's LayoutTests that aren't even under the WebKit project's control: http://www.google.com/search?q=webkit+layout+tests+-webkit.org It seems simpler and better to me to just have a note on the page on webkit.org that talks about LayoutTests describing the origins of the name and let sleeping dogs lie. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Name nitpick: layout tests
On Tue, Aug 3, 2010 at 1:27 PM, Darin Adler da...@apple.com wrote: I don’t buy in to this at all. We have done many successful renaming projects in the past. The future is bigger than the past and it’s worthwhile to do maintenance like this. Okie. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Mon, Apr 19, 2010 at 5:53 PM, Peter Kasting pkast...@google.com wrote: On Thu, Apr 15, 2010 at 3:41 PM, Aaron Boodman a...@chromium.org wrote: I'm not sure what the path is for fetching favicons today. Does WebCore just implicitly do it, or does it expose the information to the host, who later may or may not make the request? Answering this is complicated by the fact that Chromium mostly uses a different codepath for all of this stuff than, say, Safari -- e.g. it bypasses the IconDatabase and pretty much all other classes/files called IconXXX entirely. Yeah, I looked into this over the weekend, and -- shock! -- it turned out to be a bigger change than I initially imagined. Since Chromium has a different backend, that would mean implementing two sets of changes. Also, I think it would be wasteful to have WebKit download all linked icons, even if the hosting browser has no intention of every using some of them. So I'd want to add code to allow the browser to tell WebKit which sizes it is interested in. I still want to do this, but I'm going to have to reduce the priority a little bit for now. I may come back to it in a month or so. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Implementing the sizes attribute of the link tag from HTML5
I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Thu, Apr 15, 2010 at 3:09 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 15, 2010, at 2:22 PM, Aaron Boodman wrote: I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? Seems like a good idea in general. More specifically, what would the implementation do? The bug explains the syntax, but not how it would affect WebKit's behavior. (It would be fine, perhaps preferable, to put that info in the bug). I'm not sure. I haven't looked at the existing implementation at all. I wanted to make sure there was general consensus before diving in. Once I have a proposed plan of attack, I will put it in the bug. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Thu, Apr 15, 2010 at 3:25 PM, Maciej Stachowiak m...@apple.com wrote: Well, it's hard to truly have consensus on adding feature without knowing what it is. That being said, I at least would love to see a more specific proposal for what we could do with link size. I want to support bigger icons for the tabs in Chromium. I'm not sure what the path is for fetching favicons today. Does WebCore just implicitly do it, or does it expose the information to the host, who later may or may not make the request? I would like Chromium to be able to decide which icon to use from the list on a per-document basis, so if WebCore currently assumes that any favicon present should be loaded (or if that is configuration that is set at a pretty high level), I would want to change that as well. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Opinion requested on change to FrameView::adjustSize()
I'm not sure who else besides dhyatt is good to opine on this. I'd like to change FrameView::adjustSize() to use slightly different logic so that it works better for applications that want a WebView to atomically size to the content height. I'd like feedback on whether this is a good approach, or whether something else would be better. https://bugs.webkit.org/show_bug.cgi?id=32807 Thanks, - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [V8] It's time for V8Proxy to come to Jesus
+1: Hooray for any attempts to tame V8Proxy. - a On Fri, Jul 3, 2009 at 12:23 PM, Adam Barthaba...@webkit.org wrote: If you're uninterested in the V8 bindings, you can skip this email. Clocking in at 3255 lines (plus a 682-line header file), V8Proxy is out of control. Historically a bridge from the V8 bindings to the V8 engine, V8Proxy is responsible for a number of tasks including: 1) Creating new contexts 2) Implementing security checks 3) Supervising garbage collection 4) Caching event listeners 5) Executing scripts 6) Converting between frames, contexts, and global objects 7) Manging DOM wrappers 8) etc, etc, etc I propose we separate these concerns into a number of distinct classes that have clear, understandable purposes before things get worse. Please let me know if you have any in-progress patches to V8Proxy. I'd like to lock that file sometime next week while I rip it apart and put it back together. Thanks, Adam P.S., FrameLoader: you've escaped for now, but don't think I'm not watching you. ___ 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] browser extensions
Hey Patrick, 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. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Allowing webkit clients to extend XHR security policy
Ok, just to close the loop here, it looks like the preference is to do the refactor of permission checking from XHR to DocumentThreadableLoader, and then put the methods I proposed for SecurityOriginClient on FrameLoaderClient instead. I'm not sure who will get to the refactor first -- David, Alexey, or me -- but once that happens, I'll revisit the feature request using FrameLoaderClient instead. Thanks, - a On Sun, Apr 12, 2009 at 11:50 PM, Alexey Proskuryakov a...@webkit.org wrote: Yes, making changes as discussed in bugzilla, plus removing registerURLSchemeAsLocal would be a fine direction. - WBR, Alexey Proskuryakov On 12.04.2009, at 22:58, Aaron Boodman wrote: It sounds to me like our current patch is the best fit because it fits our needs, will work with Chromium's out-of-process workers, plus it allows us to remove FrameLoader::registerURLSchemeAsLocal() as Alexey requested. It has the downside that the client will get called on multiple threads, but this will automatically be fixed when the DocumentThreadableLoader refactor work is done. Can I get a yay or nay (from Alexey or other interested people) on moving forward with that patch? We're happy to do the work to remove registerURLSchemeAsLocal() while we're in there. Alternatively, can I get an idea for a different approach that would be accepted? Thanks, - a On Fri, Apr 10, 2009 at 10:23 AM, Aaron Boodman a...@chromium.org wrote: On Thu, Apr 9, 2009 at 9:50 PM, David Levin le...@google.com wrote: On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov a...@webkit.org wrote: On 09.04.2009, at 22:38, Aaron Boodman wrote: The local scheme feature is actually more powerful than just XHR If you only need extensions to do XHR, why not just make them use cross-origin XHR? That way, the extension won't even need to declare the origins it's going to access - all checks will be server-side, as with normal cross-origin XHR. I think the idea is that a user could install an extension and the user could trust the extension to do the cross-origin xhr (without the server for the x-origin doing anything special). For example, I used to have the book burro FF extension (http://www.bookburro.org/) which displayed prices for books from several book stores when you visit another online book store. Exactly. Sorry for not making this clear in the original mail. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Allowing webkit clients to extend XHR security policy
It sounds to me like our current patch is the best fit because it fits our needs, will work with Chromium's out-of-process workers, plus it allows us to remove FrameLoader::registerURLSchemeAsLocal() as Alexey requested. It has the downside that the client will get called on multiple threads, but this will automatically be fixed when the DocumentThreadableLoader refactor work is done. Can I get a yay or nay (from Alexey or other interested people) on moving forward with that patch? We're happy to do the work to remove registerURLSchemeAsLocal() while we're in there. Alternatively, can I get an idea for a different approach that would be accepted? Thanks, - a On Fri, Apr 10, 2009 at 10:23 AM, Aaron Boodman a...@chromium.org wrote: On Thu, Apr 9, 2009 at 9:50 PM, David Levin le...@google.com wrote: On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov a...@webkit.org wrote: On 09.04.2009, at 22:38, Aaron Boodman wrote: The local scheme feature is actually more powerful than just XHR If you only need extensions to do XHR, why not just make them use cross-origin XHR? That way, the extension won't even need to declare the origins it's going to access - all checks will be server-side, as with normal cross-origin XHR. I think the idea is that a user could install an extension and the user could trust the extension to do the cross-origin xhr (without the server for the x-origin doing anything special). For example, I used to have the book burro FF extension (http://www.bookburro.org/) which displayed prices for books from several book stores when you visit another online book store. Exactly. Sorry for not making this clear in the original mail. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Allowing webkit clients to extend XHR security policy
On Thu, Apr 9, 2009 at 9:50 PM, David Levin le...@google.com wrote: On Thu, Apr 9, 2009 at 9:03 PM, Alexey Proskuryakov a...@webkit.org wrote: On 09.04.2009, at 22:38, Aaron Boodman wrote: The local scheme feature is actually more powerful than just XHR If you only need extensions to do XHR, why not just make them use cross-origin XHR? That way, the extension won't even need to declare the origins it's going to access - all checks will be server-side, as with normal cross-origin XHR. I think the idea is that a user could install an extension and the user could trust the extension to do the cross-origin xhr (without the server for the x-origin doing anything special). For example, I used to have the book burro FF extension (http://www.bookburro.org/) which displayed prices for books from several book stores when you visit another online book store. Exactly. Sorry for not making this clear in the original mail. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Allowing webkit clients to extend XHR security policy
On Wed, Apr 8, 2009 at 11:53 PM, Alexey Proskuryakov a...@webkit.org wrote: On 09.04.2009, at 1:23, Aaron Boodman wrote: Rafael Weinstein, who is working with me, consulted with Adam Barth and submitted a patch based on his ideas https://bugs.webkit.org/show_bug.cgi?id=24853 for this a few weeks back. It has met with resistance though, and we're not really sure where to go next. I discussed this with Rafael over IRC a few days ago, and it seems that the biggest issue is entirely Chrome-specific. As all extensions share the same URL scheme, it is not safe to give them different privileges. As a comment in SecurityOrigin says, // ... Granting privileges to some, but not all, documents // in a SecurityOrigin is a security hazard because the documents without // the privilege can obtain the privilege by injecting script into the // documents that have been granted the privilege. Is there a solution for this issue already, or is it something the Chrome team is willing to ignore as a low risk threat? Chromium extensions run in the same scheme (chrome-extension://), but they do not run in the same origin. They all have unique origins of the form chrome-extension://extension-id/. Security origin is scheme + host + port. * Some people don't like the idea that the callback gets invoked on multiple threads. I don't like this idea, but as I said on IRC, it is acceptable to have this as a temporary solution. However, I wonder how this will work in Chromium for XMLHttpRequest calls made from workers, with the loader being in a different process, not a different thread. I see. It seems like a static call like in the current patch would be easy to make work. Things that rely on more of the loader infrastructure seem less likely. But I need to research this more, I'll reply tomorrow. * some people think it's ugly to have SecurityOrigin making calls out to static methods and think it should have a normal instance client. I mostly agree with that - I think that this should be done via FrameLoaderClient. I also think that the solution should obsolete and remove FrameLoader::registerURLSchemeAsLocal(). I don't mind doing it on FrameLoaderClient. Forgive the noob question, but I'm newish to webkit... How should this be plumbed? I don't see any direct access to FrameLoader or FrameLoaderClient from XHR, which makes sense since XHR is happening on multiple threads. I was hoping that I could add a method to FrameLoaderClient and call it from XHR, but I don't see a nice way to get to FrameLoaderClient from XHR. Same question - with FrameLoaderCleint being in a different process for XHR in workers, I don't see how this could possibly work. Am I perhaps misunderstanding the Chromium loader architecture? Yeah good point. I'll look into this. 4) Refactor all access checking (current same-origin checks, local scheme stuff, preflight stuff for AC) into DocumentThreadableLoader. Then add a new callback for what we want on FrameLoaderClient. One meta-question I have about this approach is whether it's really the right thing to do XHR-specific access checks in DocumentThreadableLoader and friends. In general, I'd rather not embark on a big refactor to get this done, but I'm still open to it if that's the only option. At least the preflight stuff for AC logically belongs to DocumentThreadableLoader - we need to move it there to reasonably implement redirects for cross-origin requests. The rest (which I think is just canLoadLocalResources checks for Dashboard) isn't relevant to this discussion, because these checks do not access static data. But how will DocumentThreadableLoader know what policy to apply? Some things are allowed to be loaded across origins (iframes) without AC, and some things aren't (XHR). Maybe I am misunderstanding and DocumentThreadableLoader is only used for XHR? Or maybe there is some context that will be available? I'm sure I'm just misunderstanding here, I'm just curious what you had in mind more than anything. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Allowing webkit clients to extend XHR security policy
Adding back webkit-dev... On Thu, Apr 9, 2009 at 11:36 AM, Aaron Boodman a...@chromium.org wrote: Ok, so if I may sum up the conversation so far: * A static call out to a client is ugly, but OK as a temporary measure * You would like to see this mechanism replace the local scheme thing that already exists The local scheme feature is actually more powerful than just XHR, it also affects cross-site scripting. So I don't think that the refactor of permission logic into DocumentThreadableLoader would help us get rid of that. The current patch would, because it happens at the SecurityOrigin layer. The host return yes, go for it! for any schemes it considers local. But that would make the static call out of SecurityOrigin permanent. We could make the client an instance member of SecurityOrigin, or some other object, but I don't really see how that makes it prettier; you'll still get calls on multiple threads. - a On Thu, Apr 9, 2009 at 1:14 AM, Alexey Proskuryakov a...@webkit.org wrote: On 09.04.2009, at 12:08, David Levin wrote: Regardless of how it plays out in the future, I think that moving access control implementation to loader thread/process is a clear win. And if any help is still needed on this, I may be able to help with this in a few weeks, but I need to finish other things right now. It's rather unlikely that I will be able to work on this soon, so help from you or other Chromium folks would be appreciated. This really looks like a significant architectural issue that we need to fix sooner rather than later - it affects both workers, and the ability to implement cross-origin redirects. I'm also on vacation next week. Cool, have a good time! - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Allowing webkit clients to extend XHR security policy
Hello all, I'm working on adding extensions (aka Add-Ons) to Chromium. One thing we want to enable these extensions to do is to make limited cross-origin XMLHttpRequests. Rafael Weinstein, who is working with me, consulted with Adam Barth and submitted a patch based on his ideas https://bugs.webkit.org/show_bug.cgi?id=24853 for this a few weeks back. It has met with resistance though, and we're not really sure where to go next. So I wanted to back up, explain what we're trying to do at a high level and get suggestions for the best way to implement this. The Goal: We want extension developers to be able to access multiple origins, but for them to have to declare those origins ahead of time. The origins would be declared using a pattern syntax, something like 'http://*.google.com'. Having to declare the origins ahead of time reduces the damage a compromised extension can do because it can only be used to access a subset of origins. Most use cases we envision really only need to access a few origins, so this would be a big win for us. This also seems like this is something that could be generally useful for other webkit clients. I can imagine browsers wanting to offer increased privilege modes to web apps, and then wanting to do similar restrictions on access to cross-origin XHR. Ideas: 1) A static call out of WebKit to a client from SecurityOrigin. This is the current patch. A few problems people have brought up with it: * Some people don't like the idea that the callback gets invoked on multiple threads. * some people think it's ugly to have SecurityOrigin making calls out to static methods and think it should have a normal instance client. 2) Non-static SecurityOriginClient. I suggested this in the last comment on the bug. The creator of a SecurityOrigin would have the option to set a client which it could retrieve from FrameLoaderClient (or some other client?). This doesn't solve the problem of getting callbacks on multiple threads, but we could skip implementing it for workers and when the refactor to move origin checking for workers to the UI thread happens, it will automatically start working. 3) Something more specific to XMLHttpRequest. Since we're really only interested in modifying the behavior of XMLHttpRequest, it might be nicer to do something more targetted than SecurityOrigin. I was hoping that I could add a method to FrameLoaderClient and call it from XHR, but I don't see a nice way to get to FrameLoaderClient from XHR. 4) Refactor all access checking (current same-origin checks, local scheme stuff, preflight stuff for AC) into DocumentThreadableLoader. Then add a new callback for what we want on FrameLoaderClient. One meta-question I have about this approach is whether it's really the right thing to do XHR-specific access checks in DocumentThreadableLoader and friends. In general, I'd rather not embark on a big refactor to get this done, but I'm still open to it if that's the only option. That's about all the ideas I've come up with. Are any of them appealing? Is there some other approach that would be better? I think we can also do this outside of WebCore with some hacking, but I'd rather avoid that and contribute some useful code to WebKit at the same time if possible. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] C++ callback at same-ish point as DOMContentLoaded javascript event?
Hello all, I'd like to run some C++ around the same point as the DOMContentLoaded event is fired. Importantly, I need this to happen *before* the window's onload event fires. FrameLoaderClient::dispatchDidFinishDocumentLoad is usually fired at the right point, but it can sometimes happen after window.onload. Would a patch to add something like dispatchDidHandleDOMContentLoadedEvents to FrameLoaderClient be accepted? Or is there some better way to do what I want? (FWIW, this is related to Chromium's fledgling Greasemonkey support. For maximal compatibility with the Firefox version of Greasemonkey, it's important that scripts be injected before window.onload). Thanks, - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] C++ callback at same-ish point as DOMContentLoaded javascript event?
On Sun, Nov 16, 2008 at 5:33 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Nov 16, 2008, at 5:16 PM, Maciej Stachowiak wrote: On Nov 16, 2008, at 2:53 PM, Aaron Boodman wrote: Hello all, I'd like to run some C++ around the same point as the DOMContentLoaded event is fired. Importantly, I need this to happen *before* the window's onload event fires. FrameLoaderClient::dispatchDidFinishDocumentLoad is usually fired at the right point, but it can sometimes happen after window.onload. Would a patch to add something like dispatchDidHandleDOMContentLoadedEvents to FrameLoaderClient be accepted? Or is there some better way to do what I want? I believe dispatchDidFinishDocumentLoad() will be called right after the DOMContentLoaded event is dispatched. So I don't think a new client interface is needed. Oops, I didn't read your email thoroughly enough before replying. I think if the load event gets dispatched first sometime, that is likely a bug. I think moving the dispatchDidFinishDocumentLoad() above the checkCompleted() may fix it. Yes, that's exactly the problem. Is it OK to move things around like this? I'm just not sure what the contract that embedders are expecting from this interface is. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] C++ callback at same-ish point as DOMContentLoaded javascript event?
On Sun, Nov 16, 2008 at 6:10 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: In conclusion, I would say it is ok to change it. If we find some third-party app that for some reason requires the old behavior, I think a one-off compatibility hack for such an app would be an acceptable solution. Cool, thanks. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I don't really like the overengineered version. I like the fairly minimalist version best, but is there anything from the overengineered version that should be added to it? I like the fairly minimalist version best as well. The stop() method does seem a little lonely on the Timer interface all by itself. If others think any other members from the overengineered version are important I would welcome them to keep stop() company. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: - Starts a timer that will call function callback after delayInSeconds, which may be a fractional number of seconds. It seems safe to assume that a large number of timers are going to be on the order of 1-10ms. Because of this I think that millisecond units (which can also be fractional) would be best. It also is nice because it is consistent with the current API. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Thu, Oct 2, 2008 at 5:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
Timer startTimer(double delayInSeconds, bool repeating, Function
callback);
interface Timer {
void stop();
}
One other random idea. What about mixing up the param order for
parallelism with the existing timer APIs:
Timer startTimer(Function callback, double delay, bool repeating);
That would make a call look like this:
var timer = startTimer(function() { ... }, 42, true);
Which feels more familiar, but at the same timer better. Less new
things to remember. Also, I think this argues for the unit to continue
being milliseconds, again, for familiarity.
- a
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] High Resolution Timer API proposal(s)
On Thu, Oct 2, 2008 at 7:08 PM, Alex Iskander [EMAIL PROTECTED] wrote: I agree. Repeating, it seems to me, should be an optional argument; the callback and time, on the other hand, are completely necessary. Good point. The default value for repeating is probably up for debate. Would more web developers use it for repitition, or for single-use? For high resolution purposes (the original purpose of the proposed API), it seems more likely to be one use only. I think it usually makes sense to have optional boolean params default to false, since undefined coerces to false in JS. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
