[chromium-dev] Re: Speed up linking
How many seperate so's do you build? And what code compiles to where? I might set up my chrome to build into shared libraries. Thanks, Leith Bade le...@leithalweapon.geek.nz 2009/5/6 Evan Martin e...@chromium.org I apologize for flogging this horse, but echo 'int extra_variable_to_cause_ccache_miss = 3;' chrome/browser/browser.cc followed by rebuilding chrome just took about 10 seconds on my old laptop, which is a 1.8ghz core duo with 2gb. The secret is linking using shared libraries, which means my rebuilt libbrowser.so is only 6.8mb and my relinked chrome executable 29kb. We've already paid some of the pain on Linux getting shared linking working (in the no more missing symbols sense), so someone who understands Windows/Mac just needs to pay the fix the build to match cost. I call not it. :P PS: just out of curiosity, I instrumented that build to print timing info. Cost breakdown: - 4.3s deciding what needs to be built (had a warm disk cache) - 4.6s rebuilding that one object (release build means -O2 is on) - 0.5s relinking libbrowser.so - 0.2s relinking chrome On Tue, May 5, 2009 at 6:49 PM, Mohamed Mansour m0.interact...@gmail.com wrote: 15 minutes on a clean build is pretty good ... For testing 1 -2 line change it needs to link, so expect a 3-6 minute linkage (depending if it depends another module) You can read the section Building Chromium http://dev.chromium.org/developers/how-tos/build-instructions-windows there is a subsection called Accellerating build if that fits. On Tue, May 5, 2009 at 9:37 PM, Leith Bade le...@leithalweapon.geek.nz wrote: Does anyone have any tips on how to speed up the linking of chrome.dll? It takes 15min on my 2GB Core 2 1.83GHz laptop, and gets anoying when I want to test a 1-2 line change in some file. Thanks, Leith Bade le...@leithalweapon.geek.nz --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Tue, May 5, 2009 at 9:49 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: On Tue, May 5, 2009 at 9:38 PM, Amanda Walker ama...@chromium.org wrote: Ah, I see. Hmm, going in that direction (from a GraphicsContext back up to the PlatformCanvas that wraps it) is an interesting question (the rest of our rendering code goes in the other direction). And as Brett can attest, this isn't the first time that PLATFORM(CG) has caused a headache--we just (so far) haven't been willing to duplicate/fork all of the Mac rendering code that currently lives in PLATFORM(CG), since there's a lot of it (especially text handling) that would end up the same. Brett's idea (change your paint routine to take a raw pixmap (an RGBA32Buffer), which we can easily draw into a GraphicsContext on any platform, is basically what the ImageDecoder subclasses do (including rudimentary multi-frame support for things like animated GIFs). If that will work, it's probably the easiest to integrate into all 3 platforms, since the dirty work has already been done. If that's too many frame copies for video, we can write a function that can create, say, an SkBitmap* pointing at the destination bits given a GraphicsContext and a rectangle. Would either of those approaches work? They both sound workable, and might be the best option at this point. We'll ping WebKit to find out the reasoning behind passing in a GraphicsContext. Probably for performance reasons and reducing extra blits/copies, but still worth investigating. For some background information... each platform implementation of MediaPlayerPrivate either stores video frames on a platform-dependent surface (cairo_surface_t, SkBitmap) or uses a platform-dependent context (HDC, NSGraphicsContext) to interact with an external library (QTKit on mac, QuickTime on Windows). I'm a bit confused at how the SkBitmap* creation would work (mostly how to deal with scaled elements, but I'm no Skia expert). The RGBA32Buffer sounds like a pretty reasonable first attempt. Upstreaming our media glue code might clean up some things as well. Thanks for the replies, Andrew We'd actually considered something similar, but didn't really like the idea of having the GraphicsContext draw call happen inside the webkit glue code; all our other glue code just delegates, so this would suddenly add behavior into the glue class. Another suggestion that Alpha brought up was to write some sort of simple wrapper for GraphicsContext that could allow us to call the draw lower down in the call chain without violating the typing abstraction. -Albert --Amanda On Tue, May 5, 2009 at 11:38 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: If there was a nice way to get a PlatformCanvas out of a PlatformGraphicsContext when PLATFORM(CG), that'd be awesome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
2009/5/6 Andrew Scherkus scher...@chromium.org: On Tue, May 5, 2009 at 9:49 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: On Tue, May 5, 2009 at 9:38 PM, Amanda Walker ama...@chromium.org wrote: Ah, I see. Hmm, going in that direction (from a GraphicsContext back up to the PlatformCanvas that wraps it) is an interesting question (the rest of our rendering code goes in the other direction). And as Brett can attest, this isn't the first time that PLATFORM(CG) has caused a headache--we just (so far) haven't been willing to duplicate/fork all of the Mac rendering code that currently lives in PLATFORM(CG), since there's a lot of it (especially text handling) that would end up the same. Brett's idea (change your paint routine to take a raw pixmap (an RGBA32Buffer), which we can easily draw into a GraphicsContext on any platform, is basically what the ImageDecoder subclasses do (including rudimentary multi-frame support for things like animated GIFs). If that will work, it's probably the easiest to integrate into all 3 platforms, since the dirty work has already been done. If that's too many frame copies for video, we can write a function that can create, say, an SkBitmap* pointing at the destination bits given a GraphicsContext and a rectangle. Would either of those approaches work? They both sound workable, and might be the best option at this point. We'll ping WebKit to find out the reasoning behind passing in a GraphicsContext. Probably for performance reasons and reducing extra blits/copies, but still worth investigating. For some background information... each platform implementation of MediaPlayerPrivate either stores video frames on a platform-dependent surface (cairo_surface_t, SkBitmap) or uses a platform-dependent context (HDC, NSGraphicsContext) to interact with an external library (QTKit on mac, QuickTime on Windows). I'm a bit confused at how the SkBitmap* creation would work (mostly how to deal with scaled elements, but I'm no Skia expert). The RGBA32Buffer sounds like a pretty reasonable first attempt. Upstreaming our media glue code might clean up some things as well. Any transforms will be lost when you do this, of course. But the only cross-platform way of representing that with the surface is through a GraphicsContext object. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
2009/5/6 Andrew Scherkus scher...@chromium.org: We'll ping WebKit to find out the reasoning behind passing in a GraphicsContext. Probably for performance reasons and reducing extra blits/copies, but still worth investigating. Probably that and preserving any active transforms, as Brett noted. For some background information... each platform implementation of MediaPlayerPrivate either stores video frames on a platform-dependent surface (cairo_surface_t, SkBitmap) or uses a platform-dependent context (HDC, NSGraphicsContext) to interact with an external library (QTKit on mac, QuickTime on Windows). Sure--the difficulty only comes up because some things that are normally per-platform in WebKit, we push down a layer, which works well in general but leads to some rough edges when PLATFORM(CHROMIUM) meets PLATFORM(CG). This is where the #ifdefs everywhere that you were hoping to avoid come into play. How many #ifdefs would it really be? --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Windows build error
I've been unable to build Chromium on Windows (VS 2005 + Incredibuild). There seem to be missing generated files. I've tried nuking all the output directories, gclient sync --force, and rebuild with no luck. chrome_font_win.cc C:\chrome\src\app\gfx\chrome_font_win.cc(15) : fatal error C1083: Cannot open include file: 'grit/generated_resources.h': No such file or directory l10n_util_win.cc C:\chrome\src\app\l10n_util_win.cc(14) : fatal error C1083: Cannot open include file: 'grit/locale_settings.h': No such file or directory os_exchange_data.cc C:\chrome\src\app\os_exchange_data.cc(19) : fatal error C1083: Cannot open include file: 'grit/generated_resources.h': No such file or directory Anybody know what this is? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Windows build error
I assume you had _another_ error before this. Try just building only chrome_strings in App. It creates generated_resources.h. M-A On Wed, May 6, 2009 at 6:09 AM, Kevin Millikin kmilli...@chromium.orgwrote: I've been unable to build Chromium on Windows (VS 2005 + Incredibuild). There seem to be missing generated files. I've tried nuking all the output directories, gclient sync --force, and rebuild with no luck. chrome_font_win.cc C:\chrome\src\app\gfx\chrome_font_win.cc(15) : fatal error C1083: Cannot open include file: 'grit/generated_resources.h': No such file or directory l10n_util_win.cc C:\chrome\src\app\l10n_util_win.cc(14) : fatal error C1083: Cannot open include file: 'grit/locale_settings.h': No such file or directory os_exchange_data.cc C:\chrome\src\app\os_exchange_data.cc(19) : fatal error C1083: Cannot open include file: 'grit/generated_resources.h': No such file or directory Anybody know what this is? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Windows build error
There probably was another error before, but after nuking, closing VS, and trying over again I lost it. Rebuilding chrome_strings fixed it. Thanks for the quick solution! On Wed, May 6, 2009 at 3:51 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: I assume you had _another_ error before this. Try just building only chrome_strings in App. It creates generated_resources.h. M-A On Wed, May 6, 2009 at 6:09 AM, Kevin Millikin kmilli...@chromium.orgwrote: I've been unable to build Chromium on Windows (VS 2005 + Incredibuild). There seem to be missing generated files. I've tried nuking all the output directories, gclient sync --force, and rebuild with no luck. chrome_font_win.cc C:\chrome\src\app\gfx\chrome_font_win.cc(15) : fatal error C1083: Cannot open include file: 'grit/generated_resources.h': No such file or directory l10n_util_win.cc C:\chrome\src\app\l10n_util_win.cc(14) : fatal error C1083: Cannot open include file: 'grit/locale_settings.h': No such file or directory os_exchange_data.cc C:\chrome\src\app\os_exchange_data.cc(19) : fatal error C1083: Cannot open include file: 'grit/generated_resources.h': No such file or directory Anybody know what this is? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
One more thing - are you planning to implement a function that will return the status of the machine?For presence information, I want to know if the computer is idle and if it does, I do not want to signal the presence. Say, during screen saver or when the screen is shut down (through windows and its power management system, obviously, not through the shut down button :)). And if you were not planning on it - is it so easy to implement that you will implement it in a few seconds? ;) I wish I knew C++ (and had enough disk space :( really low now), I would have tried to implement it by myself or help a little with everything. :) ☆PhistucK 2009/5/6 PhistucK phist...@gmail.com Yeah, I actually thought about it but never got into implementing it, since my project is kind of secret (to the surroundings) and I am afraid to create a slightly comprehensible bookmark entry with identifiable details. (Too much details, hehe. Forget it. :)) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org No good way. If you were feeling especially hacky, you could use the Bookmark system ( http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/bookmarks-api ) as a temporary data store until LocalStorage is implemented. Not recommended, but it works, we've done it for testing :). - a 2009/5/5 PhistucK phist...@gmail.com: Then... no way for now? :( I built a little instant messaging notifier with the extensions. :) ☆PhistucK On Wed, May 6, 2009 at 02:45, Peter Kasting pkast...@google.com wrote: On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman a...@chromium.org wrote: Note that using cookies, as Peter suggests, won't work either. The lesson is, never listen to me. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
base/idle_timer implements this. The only implementation detail would be exposing it to JS. It would also make us depend on xscreensaver on Linux which is :( but whatever. 2009/5/6 PhistucK phist...@gmail.com: One more thing - are you planning to implement a function that will return the status of the machine? For presence information, I want to know if the computer is idle and if it does, I do not want to signal the presence. Say, during screen saver or when the screen is shut down (through windows and its power management system, obviously, not through the shut down button :)). And if you were not planning on it - is it so easy to implement that you will implement it in a few seconds? ;) I wish I knew C++ (and had enough disk space :( really low now), I would have tried to implement it by myself or help a little with everything. :) ☆PhistucK 2009/5/6 PhistucK phist...@gmail.com Yeah, I actually thought about it but never got into implementing it, since my project is kind of secret (to the surroundings) and I am afraid to create a slightly comprehensible bookmark entry with identifiable details. (Too much details, hehe. Forget it. :)) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org No good way. If you were feeling especially hacky, you could use the Bookmark system (http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/bookmarks-api) as a temporary data store until LocalStorage is implemented. Not recommended, but it works, we've done it for testing :). - a 2009/5/5 PhistucK phist...@gmail.com: Then... no way for now? :( I built a little instant messaging notifier with the extensions. :) ☆PhistucK On Wed, May 6, 2009 at 02:45, Peter Kasting pkast...@google.com wrote: On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman a...@chromium.org wrote: Note that using cookies, as Peter suggests, won't work either. The lesson is, never listen to me. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Great! this will make my IM notifier much much more useful! :) Mmmm... so is that going to happen soon? :) ☆PhistucK 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. It would also make us depend on xscreensaver on Linux which is :( but whatever. 2009/5/6 PhistucK phist...@gmail.com: One more thing - are you planning to implement a function that will return the status of the machine? For presence information, I want to know if the computer is idle and if it does, I do not want to signal the presence. Say, during screen saver or when the screen is shut down (through windows and its power management system, obviously, not through the shut down button :)). And if you were not planning on it - is it so easy to implement that you will implement it in a few seconds? ;) I wish I knew C++ (and had enough disk space :( really low now), I would have tried to implement it by myself or help a little with everything. :) ☆PhistucK 2009/5/6 PhistucK phist...@gmail.com Yeah, I actually thought about it but never got into implementing it, since my project is kind of secret (to the surroundings) and I am afraid to create a slightly comprehensible bookmark entry with identifiable details. (Too much details, hehe. Forget it. :)) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org No good way. If you were feeling especially hacky, you could use the Bookmark system ( http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/bookmarks-api ) as a temporary data store until LocalStorage is implemented. Not recommended, but it works, we've done it for testing :). - a 2009/5/5 PhistucK phist...@gmail.com: Then... no way for now? :( I built a little instant messaging notifier with the extensions. :) ☆PhistucK On Wed, May 6, 2009 at 02:45, Peter Kasting pkast...@google.com wrote: On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman a...@chromium.org wrote: Note that using cookies, as Peter suggests, won't work either. The lesson is, never listen to me. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
This also makes sense to me as something for the wider web platform. I wonder if there could be awindow.onidle event. This seems generally useful to all web apps. - a 2009/5/6 PhistucK phist...@gmail.com: I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [chromium-checkins] r15423 - in trunk/src/chrome: browser/debugger renderer
(Reposting to the more suitable group)
I really hope this will be merged to the 178 branch quickly...
(It was very hard to debug the extensions the past two days in Chromium...)
Thank you all!!!
☆PhistucK
On Wed, May 6, 2009 at 20:37, dglaz...@chromium.org wrote:
Author: dglaz...@chromium.org
Date: Wed May 6 10:37:21 2009
New Revision: 15423
Log:
Add an extra colon to make inspector work again.
This was broken by http://codereview.chromium.org/101026.
R=glen
BUG=11532
TESt=open inspector. Inspector shouldn't show a blank page.
Review URL: http://codereview.chromium.org/113034
Modified:
trunk/src/chrome/browser/debugger/debugger_view.cc
trunk/src/chrome/renderer/renderer_glue.cc
Modified: trunk/src/chrome/browser/debugger/debugger_view.cc
==
--- trunk/src/chrome/browser/debugger/debugger_view.cc (original)
+++ trunk/src/chrome/browser/debugger/debugger_view.cc Wed May 6 10:37:21
2009
@@ -106,7 +106,7 @@
tab_contents_-render_view_host()-AllowDOMUIBindings();
GURL contents(std::string(chrome::kChromeUIScheme) +
-//inspector/debugger.html);
+://inspector/debugger.html);
tab_contents_-controller().LoadURL(contents, GURL(),
PageTransition::START_PAGE);
}
Modified: trunk/src/chrome/renderer/renderer_glue.cc
==
--- trunk/src/chrome/renderer/renderer_glue.cc (original)
+++ trunk/src/chrome/renderer/renderer_glue.cc Wed May 6 10:37:21 2009
@@ -209,7 +209,7 @@
GURL GetInspectorURL() {
return GURL(std::string(chrome::kChromeUIScheme) +
- //inspector/inspector.html);
+ ://inspector/inspector.html);
}
std::string GetUIResourceProtocol() {
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
Please see WebCanvas in the WebKit API. It was designed for this. -Darin On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus scher...@chromium.orgwrote: WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
We just need to figure out what the correct typedef is for the Mac platform. -Darin On Wed, May 6, 2009 at 10:40 AM, Darin Fisher da...@chromium.org wrote: Please see WebCanvas in the WebKit API. It was designed for this. -Darin On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus scher...@chromium.orgwrote: WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
We could either use skia/ext/platform_canvas_mac.h or we could define it to be a CG type. I'm not sure I fully understand the hybridization of CG and Skia in our Chromium Mac port. -darin On Wed, May 6, 2009 at 10:41 AM, Darin Fisher da...@chromium.org wrote: We just need to figure out what the correct typedef is for the Mac platform. -Darin On Wed, May 6, 2009 at 10:40 AM, Darin Fisher da...@chromium.org wrote: Please see WebCanvas in the WebKit API. It was designed for this. -Darin On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus scher...@chromium.orgwrote: WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Hmm. Rather than an idle event, how about a general way to notify on machine state changes? idle / busy, ac / battery, willsleep / didwake, etc. all seem to have the same usage pattern. Apps could then key off of the notification to start/stop workers or timers for idle processing, etc. --Amanda 2009/5/6 Aaron Boodman a...@chromium.org: This also makes sense to me as something for the wider web platform. I wonder if there could be awindow.onidle event. This seems generally useful to all web apps. - a 2009/5/6 PhistucK phist...@gmail.com: I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Sure, it could be a bit more general. - a On Wed, May 6, 2009 at 10:58 AM, Amanda Walker ama...@chromium.org wrote: Hmm. Rather than an idle event, how about a general way to notify on machine state changes? idle / busy, ac / battery, willsleep / didwake, etc. all seem to have the same usage pattern. Apps could then key off of the notification to start/stop workers or timers for idle processing, etc. --Amanda 2009/5/6 Aaron Boodman a...@chromium.org: This also makes sense to me as something for the wider web platform. I wonder if there could be awindow.onidle event. This seems generally useful to all web apps. - a 2009/5/6 PhistucK phist...@gmail.com: I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
I would like to give it a shot (at least the onidle event), if it is alright.But in order to do that, I need to understand (C++, but that is another story) where exactly you are laying the connection between the C++ events and the JavaScript events. (I am probably talking like a newbie (who writes it that way, huh?), but that is because I am a newbie, hehe, I never touched such code before, I know a little Visual Basic when it comes to actual programming and not web applications.) I am searching for events through the codesearch, but it is not coming along great. If you can point me to some example of firing events by C++ that calls up the JavaScript events, it will help me a lot. I could use an existing event as a syntax example. (Besides that, that means window.onidle will invoke the base::IdleTimer sort of directly with a TimeDelta::FromMilliseconds as a parameter (I am shooting for milliseconds, like setInterval\setTimeout). I guess this is really not secured, should I check that it is a positive number (with a limit?) first and if so, let it rock?) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org Sure, it could be a bit more general. - a On Wed, May 6, 2009 at 10:58 AM, Amanda Walker ama...@chromium.org wrote: Hmm. Rather than an idle event, how about a general way to notify on machine state changes? idle / busy, ac / battery, willsleep / didwake, etc. all seem to have the same usage pattern. Apps could then key off of the notification to start/stop workers or timers for idle processing, etc. --Amanda 2009/5/6 Aaron Boodman a...@chromium.org: This also makes sense to me as something for the wider web platform. I wonder if there could be awindow.onidle event. This seems generally useful to all web apps. - a 2009/5/6 PhistucK phist...@gmail.com: I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] A bug in Chrome addon system?
The phenomenon is quite simple: the addon code may not be loaded
(quite random) for the first loaded page (i.e., your homepage when you
first launch Chrome).
I don't know how to attach a file, but here are the steps to duplicate
it:
1. Just follow any standard way to create a new extension:
http://dev.chromium.org/developers/design-documents/extensions/howto
2. Use the following code:
--
Manifest.json:
{
format_version: 1,
id: 08C0AD5C3A6811DEB0A1DEB556D8959301234567,
version: 1.0,
name: Test,
description: Test,
content_scripts: [
{
matches: [http://*/*;, https://*/*;],
js: [test.js]
}
]
}
test.js:
document.title = test title;
document.addEventListener(click, function(){alert('Here I
come...');}, false);
---
As you can see, it is quite simple: it changes the page title, and
alert every time you click your mouse. But when you launch your
chrome, it is not loaded in the specified homepage (e.g., www.google.com).
Only after you navigate out from the page and go to the second page
(e.g., news.google.com) will the addon take effect.
Any ideas about this? Or did I do sth. wrong?
Thanks.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
The JavaScript bindings are (mostly) generated from .idl files found in chromium/src/third_party/WebKit/WebCore/*/*.idl chromium/src/third_party/WebKit/WebCore/dom/Node.cpp has a bunch of dispatch*Event methods. I don't know if the sandbox will get in your way, but doing this entirely in WebKit would be easiest. If that's not possible, then you'll need to have Chromium send an IPC to all the render processes ( http://dev.chromium.org/developers/design-documents/multi-process-architecture) whenever the event should fire. This is not a trivial task, but you'll learn a lot really quickly if you choose to take this on. :-) 2009/5/6 PhistucK phist...@gmail.com I would like to give it a shot (at least the onidle event), if it is alright.But in order to do that, I need to understand (C++, but that is another story) where exactly you are laying the connection between the C++ events and the JavaScript events. (I am probably talking like a newbie (who writes it that way, huh?), but that is because I am a newbie, hehe, I never touched such code before, I know a little Visual Basic when it comes to actual programming and not web applications.) I am searching for events through the codesearch, but it is not coming along great. If you can point me to some example of firing events by C++ that calls up the JavaScript events, it will help me a lot. I could use an existing event as a syntax example. (Besides that, that means window.onidle will invoke the base::IdleTimer sort of directly with a TimeDelta::FromMilliseconds as a parameter (I am shooting for milliseconds, like setInterval\setTimeout). I guess this is really not secured, should I check that it is a positive number (with a limit?) first and if so, let it rock?) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org Sure, it could be a bit more general. - a On Wed, May 6, 2009 at 10:58 AM, Amanda Walker ama...@chromium.org wrote: Hmm. Rather than an idle event, how about a general way to notify on machine state changes? idle / busy, ac / battery, willsleep / didwake, etc. all seem to have the same usage pattern. Apps could then key off of the notification to start/stop workers or timers for idle processing, etc. --Amanda 2009/5/6 Aaron Boodman a...@chromium.org: This also makes sense to me as something for the wider web platform. I wonder if there could be awindow.onidle event. This seems generally useful to all web apps. - a 2009/5/6 PhistucK phist...@gmail.com: I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
I will try and sit on it over the weekend. But, sadly, I will not download the code due to the aformentioned disk space issues. Will there be a way to give one of you the manual differences so you will commit them in the right places? ☆PhistucK 2009/5/6 Jeremy Orlow jor...@google.com The JavaScript bindings are (mostly) generated from .idl files found in chromium/src/third_party/WebKit/WebCore/*/*.idl chromium/src/third_party/WebKit/WebCore/dom/Node.cpp has a bunch of dispatch*Event methods. I don't know if the sandbox will get in your way, but doing this entirely in WebKit would be easiest. If that's not possible, then you'll need to have Chromium send an IPC to all the render processes ( http://dev.chromium.org/developers/design-documents/multi-process-architecture) whenever the event should fire. This is not a trivial task, but you'll learn a lot really quickly if you choose to take this on. :-) 2009/5/6 PhistucK phist...@gmail.com I would like to give it a shot (at least the onidle event), if it is alright.But in order to do that, I need to understand (C++, but that is another story) where exactly you are laying the connection between the C++ events and the JavaScript events. (I am probably talking like a newbie (who writes it that way, huh?), but that is because I am a newbie, hehe, I never touched such code before, I know a little Visual Basic when it comes to actual programming and not web applications.) I am searching for events through the codesearch, but it is not coming along great. If you can point me to some example of firing events by C++ that calls up the JavaScript events, it will help me a lot. I could use an existing event as a syntax example. (Besides that, that means window.onidle will invoke the base::IdleTimer sort of directly with a TimeDelta::FromMilliseconds as a parameter (I am shooting for milliseconds, like setInterval\setTimeout). I guess this is really not secured, should I check that it is a positive number (with a limit?) first and if so, let it rock?) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org Sure, it could be a bit more general. - a On Wed, May 6, 2009 at 10:58 AM, Amanda Walker ama...@chromium.org wrote: Hmm. Rather than an idle event, how about a general way to notify on machine state changes? idle / busy, ac / battery, willsleep / didwake, etc. all seem to have the same usage pattern. Apps could then key off of the notification to start/stop workers or timers for idle processing, etc. --Amanda 2009/5/6 Aaron Boodman a...@chromium.org: This also makes sense to me as something for the wider web platform. I wonder if there could be awindow.onidle event. This seems generally useful to all web apps. - a 2009/5/6 PhistucK phist...@gmail.com: I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
We should be careful about adding non-standard APIs to the Web platform. If we want to make this available to every Web site, we should first standardized the API through W3C. Adam 2009/5/6 Jeremy Orlow jor...@google.com: The JavaScript bindings are (mostly) generated from .idl files found in chromium/src/third_party/WebKit/WebCore/*/*.idl chromium/src/third_party/WebKit/WebCore/dom/Node.cpp has a bunch of dispatch*Event methods. I don't know if the sandbox will get in your way, but doing this entirely in WebKit would be easiest. If that's not possible, then you'll need to have Chromium send an IPC to all the render processes (http://dev.chromium.org/developers/design-documents/multi-process-architecture) whenever the event should fire. This is not a trivial task, but you'll learn a lot really quickly if you choose to take this on. :-) 2009/5/6 PhistucK phist...@gmail.com I would like to give it a shot (at least the onidle event), if it is alright. But in order to do that, I need to understand (C++, but that is another story) where exactly you are laying the connection between the C++ events and the JavaScript events. (I am probably talking like a newbie (who writes it that way, huh?), but that is because I am a newbie, hehe, I never touched such code before, I know a little Visual Basic when it comes to actual programming and not web applications.) I am searching for events through the codesearch, but it is not coming along great. If you can point me to some example of firing events by C++ that calls up the JavaScript events, it will help me a lot. I could use an existing event as a syntax example. (Besides that, that means window.onidle will invoke the base::IdleTimer sort of directly with a TimeDelta::FromMilliseconds as a parameter (I am shooting for milliseconds, like setInterval\setTimeout). I guess this is really not secured, should I check that it is a positive number (with a limit?) first and if so, let it rock?) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org Sure, it could be a bit more general. - a On Wed, May 6, 2009 at 10:58 AM, Amanda Walker ama...@chromium.org wrote: Hmm. Rather than an idle event, how about a general way to notify on machine state changes? idle / busy, ac / battery, willsleep / didwake, etc. all seem to have the same usage pattern. Apps could then key off of the notification to start/stop workers or timers for idle processing, etc. --Amanda 2009/5/6 Aaron Boodman a...@chromium.org: This also makes sense to me as something for the wider web platform. I wonder if there could be awindow.onidle event. This seems generally useful to all web apps. - a 2009/5/6 PhistucK phist...@gmail.com: I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Or sending an email to the WhatWG (wha...@lists.whatwg.org). Unfortunately, things are tightening up on the HTML 5 spec. I think this might be too big of a change to get in at this point. Anyhow, I've heard arguments both ways. Some people think we should not let the standards keep us from experimenting (and then raising the topics with the standards group later) and some people think it's better to bring up the idea and formalize all the details first. Personally, I'm more in the second camp, I don't think there's any harm in prototyping something up and using it as a vehicle for discussion. 2009/5/6 Adam Barth aba...@chromium.org We should be careful about adding non-standard APIs to the Web platform. If we want to make this available to every Web site, we should first standardized the API through W3C. Adam 2009/5/6 Jeremy Orlow jor...@google.com: The JavaScript bindings are (mostly) generated from .idl files found in chromium/src/third_party/WebKit/WebCore/*/*.idl chromium/src/third_party/WebKit/WebCore/dom/Node.cpp has a bunch of dispatch*Event methods. I don't know if the sandbox will get in your way, but doing this entirely in WebKit would be easiest. If that's not possible, then you'll need to have Chromium send an IPC to all the render processes ( http://dev.chromium.org/developers/design-documents/multi-process-architecture ) whenever the event should fire. This is not a trivial task, but you'll learn a lot really quickly if you choose to take this on. :-) 2009/5/6 PhistucK phist...@gmail.com I would like to give it a shot (at least the onidle event), if it is alright. But in order to do that, I need to understand (C++, but that is another story) where exactly you are laying the connection between the C++ events and the JavaScript events. (I am probably talking like a newbie (who writes it that way, huh?), but that is because I am a newbie, hehe, I never touched such code before, I know a little Visual Basic when it comes to actual programming and not web applications.) I am searching for events through the codesearch, but it is not coming along great. If you can point me to some example of firing events by C++ that calls up the JavaScript events, it will help me a lot. I could use an existing event as a syntax example. (Besides that, that means window.onidle will invoke the base::IdleTimer sort of directly with a TimeDelta::FromMilliseconds as a parameter (I am shooting for milliseconds, like setInterval\setTimeout). I guess this is really not secured, should I check that it is a positive number (with a limit?) first and if so, let it rock?) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org Sure, it could be a bit more general. - a On Wed, May 6, 2009 at 10:58 AM, Amanda Walker ama...@chromium.org wrote: Hmm. Rather than an idle event, how about a general way to notify on machine state changes? idle / busy, ac / battery, willsleep / didwake, etc. all seem to have the same usage pattern. Apps could then key off of the notification to start/stop workers or timers for idle processing, etc. --Amanda 2009/5/6 Aaron Boodman a...@chromium.org: This also makes sense to me as something for the wider web platform. I wonder if there could be awindow.onidle event. This seems generally useful to all web apps. - a 2009/5/6 PhistucK phist...@gmail.com: I wish I had the disk space and the know how. ☆PhistucK On Wed, May 6, 2009 at 20:08, Evan Martin e...@chromium.org wrote: Probably only if you do it. :) 2009/5/6 PhistucK phist...@gmail.com: Mmmm... so is that going to happen soon? :) 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
On 6-May-09, at 3:30 PM, Jeremy Orlow wrote: Anyhow, I've heard arguments both ways. Some people think we should not let the standards keep us from experimenting (and then raising the topics with the standards group later) and some people think it's better to bring up the idea and formalize all the details first. Personally, I'm more in the second camp, I don't think there's any harm in prototyping something up and using it as a vehicle for discussion. There isn't, as long as it clearly stays a prototype and it's developed in the open with input from multiple parties. Many successful APIs have evolved this way (see: geolocation). The ones that don't work as well are ones driven by a single party, without consultation or invitation for collaboration, as they tend to be too specific and not broadly useful. From my vantage point, anyway ;) cheers, mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Agreed. It's also worth pointing out that the context of this started out as an API for the add-on/extension system and evolved into an API that might be more broadly available. On Wed, May 6, 2009 at 12:39 PM, Mike Beltzner beltz...@mozilla.com wrote: On 6-May-09, at 3:30 PM, Jeremy Orlow wrote: Anyhow, I've heard arguments both ways. Some people think we should not let the standards keep us from experimenting (and then raising the topics with the standards group later) and some people think it's better to bring up the idea and formalize all the details first. Personally, I'm more in the second camp, I don't think there's any harm in prototyping something up and using it as a vehicle for discussion. There isn't, as long as it clearly stays a prototype and it's developed in the open with input from multiple parties. Many successful APIs have evolved this way (see: geolocation). The ones that don't work as well are ones driven by a single party, without consultation or invitation for collaboration, as they tend to be too specific and not broadly useful. From my vantage point, anyway ;) cheers, mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: A bug in Chrome addon system?
Yes, this is a known issue. I've created a bug that you can track if
you're interested:
http://code.google.com/p/chromium/issues/detail?id=11547
- a
On Wed, May 6, 2009 at 11:37 AM, jack js2...@gmail.com wrote:
The phenomenon is quite simple: the addon code may not be loaded
(quite random) for the first loaded page (i.e., your homepage when you
first launch Chrome).
I don't know how to attach a file, but here are the steps to duplicate
it:
1. Just follow any standard way to create a new extension:
http://dev.chromium.org/developers/design-documents/extensions/howto
2. Use the following code:
--
Manifest.json:
{
format_version: 1,
id: 08C0AD5C3A6811DEB0A1DEB556D8959301234567,
version: 1.0,
name: Test,
description: Test,
content_scripts: [
{
matches: [http://*/*;, https://*/*;],
js: [test.js]
}
]
}
test.js:
document.title = test title;
document.addEventListener(click, function(){alert('Here I
come...');}, false);
---
As you can see, it is quite simple: it changes the page title, and
alert every time you click your mouse. But when you launch your
chrome, it is not loaded in the specified homepage (e.g., www.google.com).
Only after you navigate out from the page and go to the second page
(e.g., news.google.com) will the addon take effect.
Any ideas about this? Or did I do sth. wrong?
Thanks.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: A bug in Chrome addon system?
Thanks for letting me know.
BTW I will try the trick (bookmarking for local storage) you suggested
in the mean time for user preferences.
-Jack
On May 6, 12:57 pm, Aaron Boodman a...@chromium.org wrote:
Yes, this is a known issue. I've created a bug that you can track if
you're interested:
http://code.google.com/p/chromium/issues/detail?id=11547
- a
On Wed, May 6, 2009 at 11:37 AM, jack js2...@gmail.com wrote:
The phenomenon is quite simple: the addon code may not be loaded
(quite random) for the first loaded page (i.e., your homepage when you
first launch Chrome).
I don't know how to attach a file, but here are the steps to duplicate
it:
1. Just follow any standard way to create a new extension:
http://dev.chromium.org/developers/design-documents/extensions/howto
2. Use the following code:
--
Manifest.json:
{
format_version: 1,
id: 08C0AD5C3A6811DEB0A1DEB556D8959301234567,
version: 1.0,
name: Test,
description: Test,
content_scripts: [
{
matches: [http://*/*;, https://*/*;],
js: [test.js]
}
]
}
test.js:
document.title = test title;
document.addEventListener(click, function(){alert('Here I
come...');}, false);
---
As you can see, it is quite simple: it changes the page title, and
alert every time you click your mouse. But when you launch your
chrome, it is not loaded in the specified homepage (e.g.,www.google.com).
Only after you navigate out from the page and go to the second page
(e.g., news.google.com) will the addon take effect.
Any ideas about this? Or did I do sth. wrong?
Thanks.
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
On Wed, May 6, 2009 at 12:39 PM, Mike Beltzner beltz...@mozilla.com wrote: On 6-May-09, at 3:30 PM, Jeremy Orlow wrote: Anyhow, I've heard arguments both ways. Some people think we should not let the standards keep us from experimenting (and then raising the topics with the standards group later) and some people think it's better to bring up the idea and formalize all the details first. Personally, I'm more in the second camp, I don't think there's any harm in prototyping something up and using it as a vehicle for discussion. There isn't, as long as it clearly stays a prototype and it's developed in the open with input from multiple parties. Many successful APIs have evolved this way (see: geolocation). The ones that don't work as well are ones driven by a single party, without consultation or invitation for collaboration, as they tend to be too specific and not broadly useful. From my vantage point, anyway ;) I was involved in the Geolocation spec, so I'm aware of how well it worked. To restate what Jeremy said, this started out as a discussion about an extension API. That would be the easy answer, and it is something that vendors frequently do. It still might be a useful starting point. But I specifically broadened the discussion because we Chromites are very keen to push things down into the web platform where possible, so that it benefits all applications, not just Chrome extensions. Doing this obviously means collaboration with other vendors, and when we get to the point of actually proposing something, that would clearly be the way to go. Right now we're just discussing, though. I think it's OK to ponder without a W3C mandate. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
[It seems that I can only post in the group, instead of replying in gmail, to have my reply posted here. So apologize if you already received this before. ] Thanks for all of your inputs. My previous example (gmail addon) might be misleading. Let's say the popular ad block. Ad block should be working on all web sites, and a user should be able to add/edit/delete any specified ad sources. Such information need to be stored locally, and accessible from any web pages by the add-on. So talking about cookie, IMHO I don't think it is a good candidate for user preferences due to its tight restriction on domains and server interaction. I didn't follow the latest progress of HTML 5, but I remember it had some security issues due to its widely opened door (especially the globalStorage ). On the other hand a user preference system should be working regardless of a user's security setting. But users might prohibit local storage (especially in the public/topmost domain level) like they do to cookies. Just my 2c and any of your comments are welcome. In any case looking forward to checking the new Chrome release and trying it out (Real Soon Now, right? :)). Thanks, -Jack On May 5, 4:43 pm, Aaron Boodman a...@chromium.org wrote: On Mon, May 4, 2009 at 11:08 AM, jack js2...@gmail.com wrote: Dear experts, I am recently playing around Chrome extension development Sweet! does chrome has an add-on preference system? I think a preference system is an essential component for an add-on ecosystem. What I mean is something like Firefox's Components.interfaces.nsIPrefBranch: https://developer.mozilla.org/En/Code_snippets/Preferences e.g., for a gmail addon, a user should be able to save his/her user/ pswd info. WRT to add-on development, how/where to support this? Our idea is that in most cases developers will use HTML5 LocalStorage for this, which will be available to all web pages (including extensions) by default. However, HTML5 LocalStorage is not yet implemented for Chrome, so it doesn't show up for extensions either. There are people working on this, though, and we hope to have it available Real Soon Now. Note that using cookies, as Peter suggests, won't work either. We have purposely decided to not enable cookies for extensions since the concept doesn't really make sense (cookies are really designed for live web pages that interact with servers). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Maybe the thing to do is to have some kind of WebKit namespace for experimental JavaScript APIs, in the same way there is -webkit-border-radius for CSS. Something like: window.onIdleWebKit or window.onIdleWK Adam On Wed, May 6, 2009 at 1:07 PM, Aaron Boodman a...@chromium.org wrote: On Wed, May 6, 2009 at 12:39 PM, Mike Beltzner beltz...@mozilla.com wrote: On 6-May-09, at 3:30 PM, Jeremy Orlow wrote: Anyhow, I've heard arguments both ways. Some people think we should not let the standards keep us from experimenting (and then raising the topics with the standards group later) and some people think it's better to bring up the idea and formalize all the details first. Personally, I'm more in the second camp, I don't think there's any harm in prototyping something up and using it as a vehicle for discussion. There isn't, as long as it clearly stays a prototype and it's developed in the open with input from multiple parties. Many successful APIs have evolved this way (see: geolocation). The ones that don't work as well are ones driven by a single party, without consultation or invitation for collaboration, as they tend to be too specific and not broadly useful. From my vantage point, anyway ;) I was involved in the Geolocation spec, so I'm aware of how well it worked. To restate what Jeremy said, this started out as a discussion about an extension API. That would be the easy answer, and it is something that vendors frequently do. It still might be a useful starting point. But I specifically broadened the discussion because we Chromites are very keen to push things down into the web platform where possible, so that it benefits all applications, not just Chrome extensions. Doing this obviously means collaboration with other vendors, and when we get to the point of actually proposing something, that would clearly be the way to go. Right now we're just discussing, though. I think it's OK to ponder without a W3C mandate. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Fwd: Friend who works on Chrome
Can anyone think of a reason this might be happening? Is there any more info he could provide that could help figure it out? -Nick -- Forwarded message -- Kirill - thanks for the intro. Nick - I just wanted to follow up on that strange issue with Chrome I mentioned when we last talked. When I load Chrome, the favorites boxes load instantly, though when I click on any of them, or go to any site in the first open Chrome tab, it takes about 45 seconds for that site to fully load. 80% of the page's content will load immediately, but the page will be frozen, in the sense that you can't click on any of the links on it, for about 45 seconds. Sites opened subsequently in the same tab, and different tabs, load instantly. It's just the first tab that freezes for 45 seconds. Bizarrely there is a strange interplay between Outlook and Chrome. When Chrome freezes for 45 seconds on the first tab, Outlook also freezes (especially when it's 'updating cached messages' which it does a lot, if you use IMAP as I do), and no other program I am running does. Outlook un-freezes when Chrome comes out of its 45 second freeze. The Chrome freeze happens regardless of whether I have Outlook running, so it's possible that Chrome causes the Outlook freeze. I'm using the latest version of Chrome beta, and Vista, and Outlook 2007 (I IMAP into a couple of accounts, one of which is Gmail). I just thought I'd send you these thoughts in case they are useful. We should chat sometime about how best to go sailing on the bay! Richard --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
On Wed, May 6, 2009 at 1:10 PM, jack js2...@gmail.com wrote: [It seems that I can only post in the group, instead of replying in gmail, to have my reply posted here. So apologize if you already received this before. ] Thanks for all of your inputs. My previous example (gmail addon) might be misleading. Let's say the popular ad block. Ad block should be working on all web sites, and a user should be able to add/edit/delete any specified ad sources. Such information need to be stored locally, and accessible from any web pages by the add-on. So talking about cookie, IMHO I don't think it is a good candidate for user preferences due to its tight restriction on domains and server interaction. I didn't follow the latest progress of HTML 5, but I remember it had some security issues due to its widely opened door (especially the globalStorage ). On the other hand a user preference system should be working regardless of a user's security setting. But users might prohibit local storage (especially in the public/topmost domain level) like they do to cookies. Aaron, what's the plan for extensions using localStorage and databases. I assume they'll each have their own origin that's independent of what page the user is currently browsing? Just my 2c and any of your comments are welcome. In any case looking forward to checking the new Chrome release and trying it out (Real Soon Now, right? :)). Thanks, -Jack On May 5, 4:43 pm, Aaron Boodman a...@chromium.org wrote: On Mon, May 4, 2009 at 11:08 AM, jack js2...@gmail.com wrote: Dear experts, I am recently playing around Chrome extension development Sweet! does chrome has an add-on preference system? I think a preference system is an essential component for an add-on ecosystem. What I mean is something like Firefox's Components.interfaces.nsIPrefBranch: https://developer.mozilla.org/En/Code_snippets/Preferences e.g., for a gmail addon, a user should be able to save his/her user/ pswd info. WRT to add-on development, how/where to support this? Our idea is that in most cases developers will use HTML5 LocalStorage for this, which will be available to all web pages (including extensions) by default. However, HTML5 LocalStorage is not yet implemented for Chrome, so it doesn't show up for extensions either. There are people working on this, though, and we hope to have it available Real Soon Now. Note that using cookies, as Peter suggests, won't work either. We have purposely decided to not enable cookies for extensions since the concept doesn't really make sense (cookies are really designed for live web pages that interact with servers). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: Friend who works on Chrome
Something lazy-loaded after renderer start blocks system IO looking for a nonexistent DLL or network drive or something? I dunno, I'd try and trace what the IO calls being made are. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Blargh. On Wed, May 6, 2009 at 1:35 PM, Aaron Boodman a...@google.com wrote: On Wed, May 6, 2009 at 1:26 PM, Jeremy Orlow jor...@google.com wrote: Aaron, what's the plan for extensions using localStorage and databases. I assume they'll each have their own origin that's independent of what page the user is currently browsing? Yes. Every extension runs in a unique origin of the form chrome-extension://host/ where host is the extension's unique ID. We did this so that web pages would just work naturally as extensions without any hacks to the web platform. The concept of origin is pretty important throughout HTML/JavaScript/DOM, so it made sense to give extensions one if they were going to be reusing those technologies. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: Friend who works on Chrome
On Wed, May 6, 2009 at 1:26 PM, Nick Baum nickb...@chromium.org wrote: -- Forwarded message -- Kirill - thanks for the intro. Nick - I just wanted to follow up on that strange issue with Chrome I mentioned when we last talked. When I load Chrome, the favorites boxes load instantly, though when I click on any of them, or go to any site in the first open Chrome tab, it takes about 45 seconds for that site to fully load. 80% of the page's content will load immediately, but the page will be frozen, in the sense that you can't click on any of the links on it, for about 45 seconds. Sites opened subsequently in the same tab, and different tabs, load instantly. It's just the first tab that freezes for 45 seconds. I thought this could be http://code.google.com/p/chromium/issues/detail?id=9258, but bug 9258 doesn't affect just the first tab, and also can't explain the problem of Outlook freezing at the same time. In any case, bug 9258 has been fixed in the current Dev channel release and will be fixed in the next Beta channel release (expected this week). Wan-Teh --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
I think this is a pretty reasonable idea. Also the extension system can serve as a test bed for ideas. - a On Wed, May 6, 2009 at 1:20 PM, Adam Barth aba...@chromium.org wrote: Maybe the thing to do is to have some kind of WebKit namespace for experimental JavaScript APIs, in the same way there is -webkit-border-radius for CSS. Something like: window.onIdleWebKit or window.onIdleWK Adam On Wed, May 6, 2009 at 1:07 PM, Aaron Boodman a...@chromium.org wrote: On Wed, May 6, 2009 at 12:39 PM, Mike Beltzner beltz...@mozilla.com wrote: On 6-May-09, at 3:30 PM, Jeremy Orlow wrote: Anyhow, I've heard arguments both ways. Some people think we should not let the standards keep us from experimenting (and then raising the topics with the standards group later) and some people think it's better to bring up the idea and formalize all the details first. Personally, I'm more in the second camp, I don't think there's any harm in prototyping something up and using it as a vehicle for discussion. There isn't, as long as it clearly stays a prototype and it's developed in the open with input from multiple parties. Many successful APIs have evolved this way (see: geolocation). The ones that don't work as well are ones driven by a single party, without consultation or invitation for collaboration, as they tend to be too specific and not broadly useful. From my vantage point, anyway ;) I was involved in the Geolocation spec, so I'm aware of how well it worked. To restate what Jeremy said, this started out as a discussion about an extension API. That would be the easy answer, and it is something that vendors frequently do. It still might be a useful starting point. But I specifically broadened the discussion because we Chromites are very keen to push things down into the web platform where possible, so that it benefits all applications, not just Chrome extensions. Doing this obviously means collaboration with other vendors, and when we get to the point of actually proposing something, that would clearly be the way to go. Right now we're just discussing, though. I think it's OK to ponder without a W3C mandate. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] New Using Valgrind page at dev.chromium.org
http://dev.chromium.org/developers now links to a Using Valgrind page which is supposed to be all you need to know to be a valgrind hero. It's not quite as complete as the Using Purify page, but it's close. Let me know if there are unclear or missing bits you'd like clarified. thestig is serving as deputy valgrind sheriff for a while, to help make sure I've documented everything. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] No more NotificationService in views/
I just committed a change that removes all usage of NotificationService from views/. Please do not add new usages. If you need a notification reconsider your design or find some other way to communicate. NotificationService is highly dependent on a chrome-specific enumeration of notification types which is unlikely to be resolved any time soon. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Request for comments: Feed preview work
I just wanted to give you heads up that soon it will be time for me to devote most of my time on the second part of the Feed handling support in Chrome, namely: Feed Previews ( http://dev.chromium.org/user-experience/feed-subscriptions). Consider this a request for your feedback, especially if you know about the status of the previous feed preview work or have opinions on the general direction/approach we should take. I have already added an API for PageActions and have a working RSS PageAction extension, which does feed auto-detection on the page. Now it is time to look into Feed previews. I have spoken briefly to AdamB and EvanM about feed previews and both suggested modelling this after the view-source implementation. It was also suggested to add a scheme for this (like we do with view-source), such as view-feed: or feed: I know there has been some work on this front before, although the status of that is not clear to me -- except that it was disabled at some point (or removed from the codebase?). I would love to see what was done back then, if anyone knows more. A cursory look through the code indicated that mime type sniffing for feed is done. I've heard there is also some remaining work required for sanitizing the feeds before showing, but besides the above there is not much more I know at this point in time. Comments welcome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
The way that makes most sense to me to implement this in the extensions system is: a) In C++ use content sniffing to make sure that the content type is always correct for feeds b) Add a feature to content scripts in extensions, so that they can match by content type c) Have a content script that matches the feed content type and uses XSLT to reformat the page into the prettier UI - a On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson fin...@chromium.org wrote: I just wanted to give you heads up that soon it will be time for me to devote most of my time on the second part of the Feed handling support in Chrome, namely: Feed Previews (http://dev.chromium.org/user-experience/feed-subscriptions). Consider this a request for your feedback, especially if you know about the status of the previous feed preview work or have opinions on the general direction/approach we should take. I have already added an API for PageActions and have a working RSS PageAction extension, which does feed auto-detection on the page. Now it is time to look into Feed previews. I have spoken briefly to AdamB and EvanM about feed previews and both suggested modelling this after the view-source implementation. It was also suggested to add a scheme for this (like we do with view-source), such as view-feed: or feed: I know there has been some work on this front before, although the status of that is not clear to me -- except that it was disabled at some point (or removed from the codebase?). I would love to see what was done back then, if anyone knows more. A cursory look through the code indicated that mime type sniffing for feed is done. I've heard there is also some remaining work required for sanitizing the feeds before showing, but besides the above there is not much more I know at this point in time. Comments welcome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson fin...@chromium.org wrote: I have already added an API for PageActions and have a working RSS PageAction extension, which does feed auto-detection on the page. Now it is time to look into Feed previews. I have spoken briefly to AdamB and EvanM about feed previews and both suggested modelling this after the view-source implementation. It was also suggested to add a scheme for this (like we do with view-source), such as view-feed: or feed: I know there has been some work on this front before, although the status of that is not clear to me -- except that it was disabled at some point (or removed from the codebase?). I would love to see what was done back then, if anyone knows more. A cursory look through the code indicated that mime type sniffing for feed is done. I've heard there is also some remaining work required for sanitizing the feeds before showing, but besides the above there is not much more I know at this point in time. Feed previews only ever got to the state of we know this page is a feed, so right here is where we'd stick in the template. Actually, the old file has somehow evaded deletion: webkit/glue/resources/feed.html . Here are some things to consider: - Parsing feeds is an absolute nightmare. See e.g. http://diveintomark.org/archives/2004/02/04/incompatible-rss . You definitely want to at least do it in the renderer process. Ideally it'd be from JavaScript -- you might then be able to borrow the parsing code from Mozilla(?) -- but I guess that may reject invalid XML, which there is (or at least used to be) a ton of. Maybe we don't care and XSL is sufficient. Definitely look at the Mozilla implementation. - You should be careful about HTML content. Say site A publishes a feed, and site B publishes a feed that mixes posts from A in among others. If A puts script tags in their feed, you don't want to run those scripts on B's origin when you attempt to preview the feed on B. (Normally, this kind of untrusted input handling is B's problem, but that's not how the feed world works.) Ideally, you could work around this by somehow not having an origin *at all* when displaying a feed -- abarth would know more about this than I would. - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. - The feed-sniffing code we have is probably not very good and may currently be disabled. Eye it with suspicion. This page (sorry for the non-public URL) summarizes the behaviors of various browsers in various circumstances: http://www/~evanm/projects/chrome/feeds/ http://www/~evanm/projects/chrome/xml/ I'd suggest starting with getting view-feed: to do the right thing when it's handed something correct, and then worry about fleshing out all the sniffing/redirecting/etc. second. I'd be happy to review any changes you make in this area. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
Why bother with view-feed://? Why not just have the feed be styled more nicely, similar to the way that XML is styled more nicely by default in most browsers? - a On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: On Wed, May 6, 2009 at 5:36 PM, Finnur Thorarinsson fin...@chromium.org wrote: I have already added an API for PageActions and have a working RSS PageAction extension, which does feed auto-detection on the page. Now it is time to look into Feed previews. I have spoken briefly to AdamB and EvanM about feed previews and both suggested modelling this after the view-source implementation. It was also suggested to add a scheme for this (like we do with view-source), such as view-feed: or feed: I know there has been some work on this front before, although the status of that is not clear to me -- except that it was disabled at some point (or removed from the codebase?). I would love to see what was done back then, if anyone knows more. A cursory look through the code indicated that mime type sniffing for feed is done. I've heard there is also some remaining work required for sanitizing the feeds before showing, but besides the above there is not much more I know at this point in time. Feed previews only ever got to the state of we know this page is a feed, so right here is where we'd stick in the template. Actually, the old file has somehow evaded deletion: webkit/glue/resources/feed.html . Here are some things to consider: - Parsing feeds is an absolute nightmare. See e.g. http://diveintomark.org/archives/2004/02/04/incompatible-rss . You definitely want to at least do it in the renderer process. Ideally it'd be from JavaScript -- you might then be able to borrow the parsing code from Mozilla(?) -- but I guess that may reject invalid XML, which there is (or at least used to be) a ton of. Maybe we don't care and XSL is sufficient. Definitely look at the Mozilla implementation. - You should be careful about HTML content. Say site A publishes a feed, and site B publishes a feed that mixes posts from A in among others. If A puts script tags in their feed, you don't want to run those scripts on B's origin when you attempt to preview the feed on B. (Normally, this kind of untrusted input handling is B's problem, but that's not how the feed world works.) Ideally, you could work around this by somehow not having an origin *at all* when displaying a feed -- abarth would know more about this than I would. - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. - The feed-sniffing code we have is probably not very good and may currently be disabled. Eye it with suspicion. This page (sorry for the non-public URL) summarizes the behaviors of various browsers in various circumstances: http://www/~evanm/projects/chrome/feeds/ http://www/~evanm/projects/chrome/xml/ I'd suggest starting with getting view-feed: to do the right thing when it's handed something correct, and then worry about fleshing out all the sniffing/redirecting/etc. second. I'd be happy to review any changes you make in this area. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. Firefox retains the URL of the feed in the address bar (including scheme), which is nice, though it falls back to an internal URL under the hood to do the render of the preview. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
I think Darin had some strong opinions about whether we should do nested schemes like feed-view:http://foo.com/bar. From a security point of view, we'd ideally like to render feeds with JavaScript and plug-ins disabled, as well as in a noAccess SecurityOrigin. This is easier if the feed preview lives in its own scheme. I'm happy to help out with the security bits once you have the basics up and running. Adam On Wed, May 6, 2009 at 6:26 PM, Ben Goodger (Google) b...@chromium.org wrote: On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. Firefox retains the URL of the feed in the address bar (including scheme), which is nice, though it falls back to an internal URL under the hood to do the render of the preview. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
WebKit does not support nested schemes. It would fail in so many places to recognize that the authority of such an URL is actually foo.com. (However, we could perhaps support this as we do view-source, where WebKit never actually sees the view-source URL.) -Darin On Wed, May 6, 2009 at 6:56 PM, Adam Barth aba...@chromium.org wrote: I think Darin had some strong opinions about whether we should do nested schemes like feed-view:http://foo.com/bar. From a security point of view, we'd ideally like to render feeds with JavaScript and plug-ins disabled, as well as in a noAccess SecurityOrigin. This is easier if the feed preview lives in its own scheme. I'm happy to help out with the security bits once you have the basics up and running. Adam On Wed, May 6, 2009 at 6:26 PM, Ben Goodger (Google) b...@chromium.org wrote: On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. Firefox retains the URL of the feed in the address bar (including scheme), which is nice, though it falls back to an internal URL under the hood to do the render of the preview. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
On 6-May-09, at 9:56 PM, Adam Barth wrote: From a security point of view, we'd ideally like to render feeds with JavaScript and plug-ins disabled, as well as in a noAccess SecurityOrigin. This is easier if the feed preview lives in its own scheme. I'm happy to help out with the security bits once you have the basics up and running. FWIW, Firefox has had several security issues crop up with the mixed- content feed preview implementation. Placing privileged controls so close to web content should be avoided, IMO, if you want to keep this from being a problem for Chrome as well. cheers, mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
I don't think we want these feed previews to run with foo.com's authority. I'd rather they ran with no one's authority. Adam On Wed, May 6, 2009 at 8:42 PM, Darin Fisher da...@chromium.org wrote: WebKit does not support nested schemes. It would fail in so many places to recognize that the authority of such an URL is actually foo.com. (However, we could perhaps support this as we do view-source, where WebKit never actually sees the view-source URL.) -Darin On Wed, May 6, 2009 at 6:56 PM, Adam Barth aba...@chromium.org wrote: I think Darin had some strong opinions about whether we should do nested schemes like feed-view:http://foo.com/bar. From a security point of view, we'd ideally like to render feeds with JavaScript and plug-ins disabled, as well as in a noAccess SecurityOrigin. This is easier if the feed preview lives in its own scheme. I'm happy to help out with the security bits once you have the basics up and running. Adam On Wed, May 6, 2009 at 6:26 PM, Ben Goodger (Google) b...@chromium.org wrote: On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. Firefox retains the URL of the feed in the address bar (including scheme), which is nice, though it falls back to an internal URL under the hood to do the render of the preview. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
On Wed, May 6, 2009 at 8:45 PM, Mike Beltzner beltz...@mozilla.com wrote: FWIW, Firefox has had several security issues crop up with the mixed-content feed preview implementation. Placing privileged controls so close to web content should be avoided, IMO, if you want to keep this from being a problem for Chrome as well. Thanks for weighing in Mike. Maybe we should put the subscribe now button in browser chrome instead of in the content area? That makes a lot of sense from a security point of view. Perhaps the feed preview can teach the user how to use the RSS icon in the location bar? Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
