Re: [chromium-dev] Generate extensions _locale directories from grd files?
Nobody has considered it before. An easier workaround would be to just expose a custom API to yourself that sends the dictionary into your extension. - a On Tue, Jan 12, 2010 at 1:43 PM, Erik Arvidsson a...@chromium.org wrote: I'm currently working on the new bookmark manager which is being developed as an extension. For the extension I am using the i18n extension APIs which works great. However, we currently have all the bookmark manager messages in generated_resources.grd and I would like to generate the extension _locales files from the grd file. It seems like the Grit supports different output types and I was wondering if anyone has considered doing this before? erik -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Generate extensions _locale directories from grd files?
No. On Tue, Jan 12, 2010 at 2:40 PM, Darin Fisher da...@chromium.org wrote: A side question: Does the bookmark manager as extension imply an extension process even when the bookmarks window is not visible? (It would be nice to avoid that process otherwise.) -Darin On Tue, Jan 12, 2010 at 1:43 PM, Erik Arvidsson a...@chromium.org wrote: I'm currently working on the new bookmark manager which is being developed as an extension. For the extension I am using the i18n extension APIs which works great. However, we currently have all the bookmark manager messages in generated_resources.grd and I would like to generate the extension _locales files from the grd file. It seems like the Grit supports different output types and I was wondering if anyone has considered doing this before? erik -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to
On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting pkast...@google.com wrote:
If you have ever used any of the EmptyXXX() functions, or ever will, please
read on.
These functions (in string_util.h and gurl.h) are meant for a single,
specific use case:
const std::string MyClass::foo() const {
return (everything == OK) ? member_string : EmptyString();
}
Here you cannot return string(), because it's destroyed before the
function returns, and the caller receives garbage; and you don't want to
have the function return by value, because you can access the member
variable directly and save a copy. The utility functions give you a global
empty string that you can safely return a const reference to.
DON'T USE THESE OUTSIDE THIS CASE. You should never use these as
initializers, arguments to functions, or return values in functions that
return by value. Just use the default constructor; that's what it's there
for.
Out of curiosity, what is wrong with using EmptyString() in those
cases? Is there a correctness problem? Unnecessary inclusion of
string_util.h?
- a
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Running multiple Google Chrome channels side-by-side (for testing)
On Fri, Dec 18, 2009 at 12:07 PM, Mark Mentovai m...@chromium.org wrote: Finnur Thorarinsson wrote: You can use the channel changer, as PhistucK points out, to switch and then use the About box to update, but you can only move forward in time (stable - beta - dev). I'm pretty sure the changer is deprecated. The supported way to hop between channels is to run the installer for whatever channel you want to move to. Right, but you can't downgrade, so this approach only works a maximum of twice. I'm leaning toward just having separate user accounts for now. -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] [extensions] Merge docs changes to beta
I've just merged all the docs and samples changes since we branched (except those related to unmerged features) to 249, so that Nick can flip the switch and make code.google.com reflect beta. Please remember if you're making changes after this point to docs or samples (or reviewing changes) to merge the changes to 249. Thanks, - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] [extensions] bug gardening, stable version
On Wed, Dec 16, 2009 at 3:40 AM, Evan Martin e...@chromium.org wrote: On Mon, Dec 14, 2009 at 6:13 PM, Aaron Boodman a...@chromium.org wrote: I've gone through and gardened the bugs per our goals for stable: Win, linux: http://bit.ly/5s4lrp Mac: http://bit.ly/8hHpdO Surely I'm missing some, but this should be a start. I know you had to decide to boot some stuff to make a reasonable goal set, but if you weren't aware of it, this one is needed for the translate extension to work, which is sorta one of the flagship extensions. We did a last minute change before beta to make the translate extension work on mac and linux. It now falls back to server-side detection, which isn't quite as fast or accurate, but works. So this isn't critical, is it? - 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] [extensions] Please leave bugs open until they've been merged to beta (where necessary)
That's all, thanks. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] [extensions] Please leave bugs open until they've been merged to beta (where necessary)
On Wed, Dec 16, 2009 at 1:07 PM, Evan Stade est...@chromium.org wrote: a) what labels will a bug that's been deemed merge-worthy have? I dunno if there is an existing convention for this, but I was thinking we just leave the bug open. Basically everything on mstone-4 releaseblock-stable needs to be merged, by definition, right? b) isn't the next beta cut from ToT? are we planning to re-release the current beta? No, I confirmed with Mal. 249 is bound for stable. Everything we want in m4 stable needs to be merged to 249. - 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: Exposing Chrome Extensions APIs to DOM UI.
Seems like a bad idea. Extensions and DOMUI are basically two competing systems for doing the same thing, it would get confusing combining them. I would rather either: a) add new (possibly experimental) APIs for the issues you've run into. b) manually plumb the extension APIs you need through DOMUI (this is basically composition instead of inheritance) Is this the complete list of bugs? http://code.google.com/p/chromium/issues/list?can=2q=feature:extensions+reporter:arv Context menu is potentially on the M5 list. Depending on how complex a context menu API you want, this might not be too bad. We should just implement the chrome:// urls one I guess. - a On Mon, Dec 14, 2009 at 3:36 PM, Erik Arvidsson a...@chromium.org wrote: I'm in the process of writing a bookmark manager in HTML. So far I've written it as an extension but I'm now considering changing this to a DOM UI page instead. [*] I would like to be able to expose the extensions API for bookmarks to the DOM UI (and eventually make all DOM UI pages use extension APIs). Where do I start? Is this a bad idea? Another option is to keep the bookmarks manager as a special extension that is always turned on. [*] Extensions do not have enough privileges and there aren't enough hooks to allow extensions to do all the things the bookmark manager needs to do. I've filed bugs for everything I've run into. erik -- 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: Exposing Chrome Extensions APIs to DOM UI.
On Mon, Dec 14, 2009 at 5:29 PM, Erik Arvidsson a...@chromium.org wrote: On Mon, Dec 14, 2009 at 16:48, Aaron Boodman a...@chromium.org wrote: Seems like a bad idea. Extensions and DOMUI are basically two competing systems for doing the same thing, it would get confusing combining them. I would rather either: a) add new (possibly experimental) APIs for the issues you've run into. b) manually plumb the extension APIs you need through DOMUI (this is basically composition instead of inheritance) Seems like b then. However, the extensions APIs are much nicer than all the ad-hoc chrome.send + CallJavascriptFunction we are currently using and having the same API seems like a win for maintainability. I agree the current DOM UI method of sending calls stinks. I've looked at using the extension system's mechanism before but it will be a lot of work to decouple from the extension system I think. But feel free to take a fresh look if you want. Is this the complete list of bugs? http://code.google.com/p/chromium/issues/list?can=2q=feature:extensions+reporter:arv Context menu is potentially on the M5 list. Depending on how complex a context menu API you want, this might not be too bad. We should just implement the chrome:// urls one I guess. If we make the bookmark manager completely as an extension extensions need to be able to hook up global keyboard shortcuts (27702) as well as some way to hook into the wrench and system menus on mac. I don't see why. We can implement those things in Chrome directly. Chrome can know about this special extension. - 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] [extensions] bug gardening, stable version
I've gone through and gardened the bugs per our goals for stable: Win, linux: http://bit.ly/5s4lrp Mac: http://bit.ly/8hHpdO Surely I'm missing some, but this should be a start. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-extensions] Re: Desktop Notifications
Not implemented yet. I have a patch to make this work, but it needs somebody to volunteer to write tests for it and get it committed. Otherwise, it is backlogged behind 300 open bugs. - a On Fri, Dec 11, 2009 at 6:34 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, Bringing this topic back again. I've been able to show notifications from our extension, with a friendly name in the from label. What I'm not able to do is communicate with the background page. Is this implemented or not yet? Thanks On Tue, Nov 10, 2009 at 11:51 PM, Aaron Boodman a...@chromium.org wrote: On Tue, Nov 10, 2009 at 8:19 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hey Aaron, thanks for your answer. Does this mean that extension and communication will be able to communicate between them without using Shared workers? Yes, also, all the extension APIs, like chrome.tabs, chrome.bookmarks, etc should be available in the notification HTML page. Being able to do getBackgroundPage() from extension-created notifications would be awesome. We'll star those issues. Ok! -a -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Extensions and the Mac
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote: Andy sent me a CL for review about an extension crashing (http://crbug.com/29584). Turns out the cause was a failure to load a Windows .dll on the Mac. We have had threads on this before. The consensus was that it was possible to simply fail to load incompatible plugins, without crashing. That is, that it should be possible for each platform to try and load all plugins, but they will only succeed in loading those that are meant for them. Can you point me to the CL? - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Extensions and the Mac
On Thu, Dec 10, 2009 at 4:27 PM, Avi Drissman a...@google.com wrote: Can we have the syntax say platform x loads x.dll, platform y loads y.so, etc? Yes that is the idea. If a dll required by a platform fails to load, we need to alert the user that their extension is busted. The prospect of having failure to load binaries be an expected thing scares me. Agree. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Extensions and the Mac
It is good that we can avoid the crash. We do need to get some kind of
syntax in the manifest.
- a
On Thu, Dec 10, 2009 at 4:18 PM, Avi Drissman a...@google.com wrote:
The crash is fixed. But the fact that we're now expecting random dll loads
to fail prevents us from giving good UI to users, and not labelling what
platforms it'll work on prevents us from warning in advance.
Imagine a million angry Mac and Linux users filing bugs because their
favorite extension fails to fully load because it relies on an NPAPI plugin
not available on their platform.
Avi
On Thu, Dec 10, 2009 at 7:15 PM, Matt Perry mpcompl...@chromium.org wrote:
Yeah, that's very bad. I knew the NPAPI syntax sucked, but we punted on it
because we didn't like any of the alternatives. (Even if we do have a
manifest syntax for it, the extension package becomes bloated with plugin
binaries for other platforms.) But I didn't realize that it could cause a
crash. I'll definitely have to figure something out soon.
On Thu, Dec 10, 2009 at 4:03 PM, Avi Drissman a...@chromium.org wrote:
Andy sent me a CL for review about an extension crashing
(http://crbug.com/29584). Turns out the cause was a failure to load a
Windows .dll on the Mac.
Huh? Then I went to look at the docs
(http://code.google.com/chrome/extensions/npapi.html):
{
name: My extension,
...
plugins: [
{ path: content_plugin.dll, public: true },
{ path: extension_plugin.dll }
],
...
}
Are you kidding me? How can we get away with not specifying what platform
the extension will run on? (Hint: we can't.)
If we had something like:
plugins: {
mac: ...
win: ...
linux: ...
}
then at least we could warn on the extensions website that a given
extension is only compatible with a certain platform. On a load attempt we
could know that the extension requires a certain native library and fail to
load it with a real user-friendly warning.
And developers could make extensions that are cross-platform compatible.
Today?
- We can't tell in advance what platforms an extensions runs on, so we
can't warn the user (either on the extensions site or in the app)
- The developer has no way of creating a cross-platform extension.
This is a really bad situation we've created. We need to get a new syntax
out for extensions to fix this, and soon, before world-breaking becomes
prohibitively expensive.
Avi
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Extensions and the Mac
Yes, extensions that include NPAPI are a very small minority. Last time I checked there were something like 5. It is a way out for people who already have binary code that they would like to reuse, or who need to talk to the platform. I don't see what the big deal is about a few extensions only supporting a particular platform. As long as it is clear to users (you're right, we need to do this), I think this is ok. - 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] Extensions gallery open for uploads
Hello all, I'm happy to announce that the developer area of our extensions gallery is now open: https://chrome.google.com/extensions You can upload your extensions, edit their details, add screenshots and videos, test the autoupdate system, and begin publishing your download URL. We are opening these features early so that developers like yourselves will have time to get familiar with the system, flush out any bugs, and publish your extensions before our full launch. For more information, please see the blog post, here: http://blog.chromium.org/2009/11/extensions-one-step-closer-to-finish.html Looking forward to seeing what you've built! -- Aaron Boodman, on behalf of the Google Chrome Extensions team -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Some people still making new toolstrip-based extensions
We're going to have to explain again when we actually remove toolstrips, because some people won't have seen the first announcement (understandably): http://www.guyvider.com/2009/11/i-love-chrome-extensions.html - 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] [extensions] s/Area-/Feature-/g
Since we no longer have the cc list on Area-Extensions, I've relented and added the Feature-Extensions label to all our existing bugs. Please update your bookmarks and try to remember to use Feature-Extensions now, not Area-Extensions. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-extensions] openDatabase() maximum size
My name is Aaron Boodman and I support the motion to give extensions extra space. On Fri, Nov 13, 2009 at 12:01 PM, Antony Sargent asarg...@google.com wrote: [+chromium-dev and dumi] I'm not sure what our overall plan is with respect to quotas for html5 databases, and whether we've discussed giving extensions larger quotas than regular web content. Dumi or anyone else care to comment? On Thu, Nov 12, 2009 at 10:39 PM, Yuichi Tateno hotchpo...@gmail.com wrote: Hi, I am experiencing some issues specifying the maximum size with estimatedSize in openDatabase. Regardless of whatever value I specify it as, approximately 5MB seems to be the maximum size. http://dev.w3.org/html5/webdatabase/#databases Because the extension that I am developing is used to synchronize data from a social bookmarking site, the 5MB size is not enough and I am having some trouble. In the future could you please see that estimatedSize can be specified properly, or do you have a plan to increase the size limit to higher than 5MB? Yuichi Tateno -- You received this message because you are subscribed to the Google Groups Chromium-extensions group. To post to this group, send email to chromium-extensi...@googlegroups.com. To unsubscribe from this group, send email to chromium-extensions+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/chromium-extensions?hl=. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: Waiting for privacy blacklists to load in ResourceDispatcherHost
Aaaarrrgh On Thu, Nov 12, 2009 at 12:48 PM, Aaron Boodman a...@google.com wrote: On Thu, Nov 12, 2009 at 12:13 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Nov 12, 2009 at 11:45 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: On Thu, Nov 12, 2009 at 20:26, John Abd-El-Malek j...@chromium.org wrote: My question still stands: if this list is needed in order to process the first network request, why add extra complexity to RDH to make more things asynchronous, when either way any IO is basically blocked on the blacklist? You might as well load the list on the IO thread. Indeed, that would simplify a lot of things. However, we may recompile the blacklist when browser is running, for example when loading a new extension. In that case, we probably don't want to stall the IO thread. The difference is that when starting the browser, we don't have yet any blacklist. We should definitely wait for the blacklists to load, because it would be surprising for the user if the blacklist doesn't take effect for some time after starting the browser. When changing the blacklists when the browser is already running, it's more complicated. Nick, could you comment whether new network requests should be paused when a blacklist is changing? (for example due to now extension being loaded) Not waiting then would make things trivial. And anyway, waiting for blacklists after the browser started is even more surprising, as some request may already be started (it's not obvious what to do with them). per our chat on irc, I think if a new privacy blacklist is added while running, it should be loaded on the file thread, and when it's available the IO thread should be updated. The user won't have expectations or know how already pending requests are scheduled, and won't be loading a blacklist and within a 100ms loading a page. FWIW, I agree with what was apparently John's suggestion. There's no need to pause requests while the blacklist/extension is loading after the browser is already running. In the autoupdate case, the user won't even know this is happening. In the dev mode case, the user might get luckly and do a request or two while the blacklist is recompiling, but: a) I expect this would be hard to do given I expect the latency is on the order of seconds. b) We can solve this later if necessary. - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] [linux] page action extensions crashy on 4.0.237.0
You can disable the extensions easily by going to wrench extensions, and clicking the Disable link next to each item. - a On Mon, Nov 9, 2009 at 6:20 PM, Tony Chang t...@chromium.org wrote: If you don't run Chrome on Linux or you don't have any extensions installed, you can ignore this email. If you have any browser action extensions (like the buildbot extension or the gmail extension) installed on Linux Chrome, you may be experiencing frequent crashes when closing browser windows. A potential fix has been checked in, but until the next dev channel build is released, you can work around the crash by disabling the extension. This applies to any extension that puts a button in your browser toolbar. If you're curious: http://code.google.com/p/chromium/issues/detail?id=26751 tony --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-extensions] Re: Desktop Notifications
I did some quick spelunking with this feature this evening. It doesn't look like the integration with extensions is quite working yet. For one, when showing an HTML notification for a chrome-extension:// URL, it looks like the notification window ends up in a different process. This prevents chrome.extension.getBackgroundPage() from working, which how communication between notification windows and other extension views should work. I filed a few bugs on the integration between the two systems. You can find them all here: http://code.google.com/p/chromium/issues/list?q=Area:extensions+feature:notifications - a On Mon, Nov 9, 2009 at 10:09 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi John, To be more specific. We have logic in our background page that acts as a single entry point for several features, including opening site pages according to some user preferences and location. Any component that needs to open a page should do it through this entry point. We also have implemented an observer-like service, so that several parts of the application can react over several events. Use cases: * The notification contains a link or button that when clicked, the extension performs an action, ie. opening a custom link in a new tab, in a new window, etc... * The extension would want to update a notification's content(if visible) when some updated data is received via a remote API. Those are our specific use cases. Shared workers sound like what we need though. @Drew, Does near future include the 4.0 release? Let us know if you need help testing this. Thanks a lot! On Mon, Nov 9, 2009 at 10:33 PM, John Gregg john...@google.com wrote: Hi Marcos, It might help if you could describe (as specifically as you feel you can) the use-case you're hoping to realize, since changes to the spec should be driven by use-cases rather than just programming style. At present my concern is to make sure we remain flexible with the presentation of notifications rather than building in too many hooks before the feature has received a lot of use. But if there's an important use-case that the spec doesn't meet, that would be a place to start. As far as workarounds that wouldn't depend on changing the Notifications spec, you might look at shared workers, which are coming soon to Chromium as well (atwilson@ can provide details): it should be the case that both the notification page and the main creating script can communicate via the same shared worker. -John On Mon, Nov 9, 2009 at 11:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've managed to use the Notifications API from our extension, thanks to John Gregg's implementation. However we are missing a key feature for us, which is to be able to have some logic inside the notifications itself, so that we can communicate with the background script for several things. I understand the way of communicating this components is under discussion, but are there any tips or clues for us to base our work on? We've tried setting something like background to the Notification object and try accesing it from the inner javascript in the notification, with no luck, ince we can only reach up to a DOMWindow object. The same goes backwards, where onDisplay we were trying to call a method in the notifications internal javscript, but we can go deeper from the Notification object. Inside the DOMWindow from the notification we can go through chrome.[windows/tabs/extension] but any call to those APIs will throw an access denied error. Is there any workaround or something we can do in the short term to accomplish this type of communication? Maybe something like what content scripts do with ports. What are the proposals for this under discussion? Thanks for your help. Marcos On Thu, Nov 5, 2009 at 6:22 PM, Marcos Aruj marcos.a...@gmail.com wrote: Ok, done: http://www.crbug.com/26859 I attached a crx to the report that triggers the bug. Thanks! On Thu, Nov 5, 2009 at 5:19 PM, John Gregg john...@google.com wrote: Thanks for the bug report, I am currently working on getting Notifications working for extensions and I'm familiar with this issue, although I don't think there is a bug for it yet. If you would create one I can update it as I get the fix checked in (which will hopefully be tomorrow, I think it's a fairly easy fix). -John On Thu, Nov 5, 2009 at 6:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've been testing the Notifications API and have shown them successfully on a regular page. We are trying to use it from within an extension, but Chromium crashes when calling requestPermission. It correctly asks to allow notifications for chrome-extension://XX/, but after allowing or denying, it crashes. Let me know if a bug needs to be created, if it's a known issue or if we are missing something. Thanks, Marcos On Fri, Oct 30, 2009 at 3:57 PM, Marcos Aruj
[chromium-dev] A plan for i18n
We need to have basic i18n for extensions for the stable release, but our constraints are: a) Time is tight b) We should not slow down Chrome startup (eg by loading message catalogs early in startup) c) We should not do something that is incompatible with our eventual i18n vision Here is a proposal that I think meets these constraints: 1. Use the same message catalog layout we had before (_locales directory, one JSON catalog per locale, we find them by crawling the directory structure). This means we will be forward compatible. 2. Support i18n in text fields of the manifest (name, description, browser and page default titles, browser action default badge). These fields cannot be internationalized by developers any other way, so we need to support this at a minimum. 3. Support chrome.i18n.getMessage(). This allows developers to i18n the rest of their extension manually. Implementation notes: In order to avoid slowing down Chrome startup, I think we need to store the manifest in the preferences already localized. So basically, somewhere during extension installation, we need to localize the manifest and store it that way. Whenever the current locale in Chrome changes, we must re-localize from the version stored on disk. chrome.i18n.getMessage() is spec'd to be synchronous, which seems very useful. In order to support this, it means that we must load the message catalogs before the extension process is started. Thoughts? - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] A plan for i18n
On Tue, Nov 10, 2009 at 12:21 PM, Thomas Van Lenten thoma...@google.com wrote: Off list since I haven't really looked at extensions, so some of this might be obvious... Not a dumb question at all, so replying on-list :) On Tue, Nov 10, 2009 at 3:17 PM, Aaron Boodman a...@chromium.org wrote: We need to have basic i18n for extensions for the stable release, but our constraints are: a) Time is tight b) We should not slow down Chrome startup (eg by loading message catalogs early in startup) c) We should not do something that is incompatible with our eventual i18n vision Here is a proposal that I think meets these constraints: 1. Use the same message catalog layout we had before (_locales directory, one JSON catalog per locale, we find them by crawling the directory structure). This means we will be forward compatible. 2. Support i18n in text fields of the manifest (name, description, browser and page default titles, browser action default badge). These fields cannot be internationalized by developers any other way, so we need to support this at a minimum. 3. Support chrome.i18n.getMessage(). This allows developers to i18n the rest of their extension manually. Implementation notes: In order to avoid slowing down Chrome startup, I think we need to store the manifest in the preferences already localized. So basically, somewhere during extension installation, we need to localize the manifest and store it that way. Whenever the current locale in Chrome changes, we must re-localize from the version stored on disk. Where do extensions end up getting installed? ie-are they only in the profile directory or can they be installed machine wide? if machine wide, they you might not be able to write back into some places to update for a different locale. Worse, with Mac fast user switching, could two users have it active at the same time in different locales? Good point. We do allow machine-wide installation, but the way it works is that the extension ends up getting installed per-profile, on all profiles by default. So I think we are still good here. - 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: [chromium-extensions] A plan for i18n
On Tue, Nov 10, 2009 at 2:31 PM, Erik Kay erik...@google.com wrote: To be clear what's (intentionally) omitted from this proposal: - localized resource fetching (transparently turning /foo/bar.gif into /_locales/jp/foo/bar.gif) - auto string substitution (l18n templating) I think what you've got is a good start for our initial release. The above omissions are going to be trickier to do without significant performance penalties, and I think we can add them later. This will mean that i18n will be more manual for developers with the initial release, but it should still perform well and should be forwards compatible. One minor thing you left out was getURL providing a way to generate a localized URL (ideally without stats). If we don't provide devs a way to construct URLs manually, then they won't have a good migration path for when we do implement localized resource fetching. One thing is that odd is that if we don't do fallback for getURL(), it will be inconsistent. The manifest and getMessage() API will localize using fallback, but getURL() won't. - 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: [chromium-extensions] A plan for i18n
On Tue, Nov 10, 2009 at 3:21 PM, Nebojša Ćirić c...@google.com wrote: One minor thing you left out was getURL providing a way to generate a localized URL (ideally without stats). If we don't provide devs a way to construct URLs manually, then they won't have a good migration path for when we do implement localized resource fetching. One thing is that odd is that if we don't do fallback for getURL(), it will be inconsistent. The manifest and getMessage() API will localize using fallback, but getURL() won't. We could let them build resource URL in the message catalog and get it using getMessage. JavaScript: ... getURL(chrome.i18n.getMessage(some_resource)); ... _locales/en/messages.json: ... some_resource : _locales/en/some_resource.jpg ... This approach would solve fallback problem too, since we would check all sublocales, without stating files. Developer would have to make sure the file actually exists. Yeah, I would rather something like this. Erik, I don't understand why you say this has no forward migration path. Wouldn't it just keep working if we introduced more clever APIs that automate more of this? At that point, the developer could choose to use the new APIs or keep doing it the old way. - 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: [chromium-extensions] A plan for i18n
On Tue, Nov 10, 2009 at 3:24 PM, Nebojša Ćirić c...@google.com wrote: Implementation notes: In order to avoid slowing down Chrome startup, I think we need to store the manifest in the preferences already localized. So basically, somewhere during extension installation, we need to localize the manifest and store it that way. Whenever the current locale in Chrome changes, we must re-localize from the version stored on disk. We could generate all manifest.json files during the installation process and store them in respective locales: _locales/en/manifest.json _locales/es/manifest.json When user switches UI language, we would load correct manifest.json file and replace one in prefs. I think this would be cheaper (perf wise) than loading message catalogs when we detect UI language change, and then doing manifest localization on the fly (less files to load, less processing). I think it is OK to re-read the catalogs when the UI language changes. This is pretty infrequent. - 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: [chromium-extensions] A plan for i18n
On Tue, Nov 10, 2009 at 3:31 PM, Aaron Boodman a...@chromium.org wrote: On Tue, Nov 10, 2009 at 3:24 PM, Nebojša Ćirić c...@google.com wrote: Implementation notes: In order to avoid slowing down Chrome startup, I think we need to store the manifest in the preferences already localized. So basically, somewhere during extension installation, we need to localize the manifest and store it that way. Whenever the current locale in Chrome changes, we must re-localize from the version stored on disk. We could generate all manifest.json files during the installation process and store them in respective locales: _locales/en/manifest.json _locales/es/manifest.json When user switches UI language, we would load correct manifest.json file and replace one in prefs. I think this would be cheaper (perf wise) than loading message catalogs when we detect UI language change, and then doing manifest localization on the fly (less files to load, less processing). I think it is OK to re-read the catalogs when the UI language changes. This is pretty infrequent. Ok, so it seems like the key people are all on board. This doesn't seem like a huge amount of work. I'll start creating some small bugs against the current state of the world. Cira, are you ready to start diving back into this, or are you still committed to beta blockers on the general product? - a -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Re: [chromium-extensions] Re: Desktop Notifications
On Tue, Nov 10, 2009 at 8:19 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hey Aaron, thanks for your answer. Does this mean that extension and communication will be able to communicate between them without using Shared workers? Yes, also, all the extension APIs, like chrome.tabs, chrome.bookmarks, etc should be available in the notification HTML page. Being able to do getBackgroundPage() from extension-created notifications would be awesome. We'll star those issues. Ok! -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: How to log exceptions/console messages from shared worker context?
It would be cool if the devtools window had some kind of UI where you could see all running top-level contexts. Like tabs that had: + extensions - foo extension - background page - worker - tab 1 - tab 2 - content script a + bar extensions + worker 1 + worker 2 + tab 1 + tab 2 Then we could reconfigure the current entrypoints into devtools to go automatically to the right place in this tree. - a On Sun, Nov 8, 2009 at 10:34 AM, Ojan Vafai o...@chromium.org wrote: +chrome-devtools-team I think this is a general UI problem that needs to be solved for the inspector. There are increasingly more and more pages we have that don't have a page visible to the developer (sharedworkers, extensions background pages, etc.). I can't think of any good solutions off the top of my head though. Ojan On Sun, Nov 8, 2009 at 10:14 AM, Drew Wilson atwil...@chromium.org wrote: I'm trying to figure out the best way to report exceptions/console messages from shared workers. Currently, dedicated workers just send their messages back to their parent frame, where they are reported like any other frame-level exception. SharedWorkers don't have a specific parent window (they may have many parents) so this approach won't really work for them. I can think of a couple of ways to approach this: 1) These exceptions/messages are already marshaled up to the browser process - perhaps they could be routed to the inspector/dev tools from there? 2) There's a shadow frame that is created in worker context to handle resource requests from the worker. It's possible that this could be leveraged to report exceptions. It seems like #1 would be the simplest, but I've never been in this code before so I'm not positive about the details. Who's a good person to talk to about this? -atw --~--~-~--~~~---~--~~ 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: Next dev release
On Thu, Nov 5, 2009 at 10:18 AM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, Just wanted to know when will the next dev release be? Hi Marcos, We usually try to do dev channel releases once a week, but it varies depending on the state of the tree. Releases (even dev channel ones) take time to create and test. Currently we are a few weeks behind, but we hope to get something out by early next week. - 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: [chromium-extensions] Re: Desktop Notifications
Creating a bug with a small sample attached would be great. On Thu, Nov 5, 2009 at 3:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've been testing the Notifications API and have shown them successfully on a regular page. We are trying to use it from within an extension, but Chromium crashes when calling requestPermission. It correctly asks to allow notifications for chrome-extension://XX/, but after allowing or denying, it crashes. Let me know if a bug needs to be created, if it's a known issue or if we are missing something. Thanks, Marcos On Fri, Oct 30, 2009 at 3:57 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, Quick question, how is the Notifications API going for the release of 4.0? Are there any news on this? Any sample code? Just wanted to know if we can rely on it now or if we should wait. Thanks! Marcos On Tue, Oct 20, 2009 at 11:04 AM, Darin Fisher da...@chromium.org wrote: OK, that sounds reasonable to me. -Darin On Tue, Oct 20, 2009 at 9:51 AM, John Gregg john...@google.com wrote: Not precisely embedding a TabContents; I'm drawing a custom toast using views and putting a RenderViewHost+RenderWidgetHostView in it. -John On Tue, Oct 20, 2009 at 12:27 AM, Darin Fisher da...@chromium.org wrote: Is this accomplished by embedding a TabContents in a custom drawn (using Views) toast? -Darin On Mon, Oct 19, 2009 at 2:17 PM, Drew Wilson atwil...@chromium.org wrote: To be clear - our priority is to support HTML notifications on all platforms *before* investigating support for native notification platforms (like Growl/libnotify). -atw On Mon, Oct 19, 2009 at 11:25 AM, Ian Fette i...@chromium.org wrote: We're trying to come up with a way to display html notifications on these platforms, once we get the windows one checked in. (Likely code that we will have to write.) 2009/10/19 Evan Martin e...@chromium.org On Mon, Oct 19, 2009 at 11:16 AM, John Gregg john...@google.com wrote: The implementation of notifications is nearly complete for Windows chromium with the final pieces being reviewed right now. Hopefully it will be available on the dev channel very soon behind a command-line switch for developers to start using. If you have questions about the specifics of the API, let me know, I'm happy to answer them and/or provide more documentation. I had alluded to this before, but I don't still see a good answer: what is the plan on Mac/Linux when the API is called with HTML? -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - --~--~-~--~~~---~--~~ 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: Singleton, LazyInstance, and testability
On Wed, Nov 4, 2009 at 12:12 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: On Wed, Nov 4, 2009 at 08:56, Aaron Boodman a...@chromium.org wrote: Why don't you pass an Extension instance? It's in a test. Mocking an Extension is not trivial as well. :( Or maybe... I didn't read all of the extensions unit tests, maybe it's not that hard. It's a simple data object, there's no need to mock it. Just create an instance of it. I see. Hmm... the test assumes that the only listener is BlacklistManager, because the idea of the unit test is to test it in isolation. In the browser_test I'm obviously not making that assumption, and it's using ExtensionsService with real Extensions etc. Please also note that the BlacklistManager unit test will only send EXTENSION_LOADED notification, without pairing EXTENSION_UNLOADED. This is going to cause problems anyway at some point if there are other, unexpected listeners. If the Extension was easily mocked, I would pass a real instance anyway. What do you think I should do (for the unit test)? I think in this case you can just pass an Extension instance. This is done all over the unit tests for extensions. See, eg extension_unittest.cc. - 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: Singleton, LazyInstance, and testability
On Wed, Nov 4, 2009 at 8:17 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Oh, indeed. Thanks, after looking at other tests it was easy. It was a bit annoying that I had to use #ifdefs for FilePath though. You may be able to just specify an empty FilePath() ? I'm not sure. Give it a try. - 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: Extensions performance data
On Tue, Oct 27, 2009 at 8:26 AM, Antony Sargent asarg...@google.com wrote: Page Cycler Tests Since the page cycler tests take a long time to run, we've only added one extensions case to 2 of the individual data sets: Moz (relatively simple pages, less javascript) and MoreJS (more complicated DOM and javascript). The Moz set runs very quickly, typically something like 40ms per page on a fast machine. The MoreJS set runs much more slowly, typically something like 190-200ms per page on a fast machine. We use the _extcs1 suffix on the test names to denote extensions with 1 content script. Time Moz: 10-17% increase in cycle time (absolute increase of ~4-5ms per page) MoreJS: 2-4% (absolute increase of ~5-10ms per page, perhaps a little higher than Moz due to v8 having more garbage to collect?) FYI, we got the Moz one down to about .7% regression. See here: http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150 This was done by delaying injection until after page load is complete for fast pages. The heuristic is that we inject at min(DOMContentLoaded + 200ms, onload). The idea is to not delay fast pages, but not to have to wait too long for injection for slow pages. We still have work to do on Chrome startup, but I'm hopeful we can fix that, too. - 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: refactoring and git
On Tue, Nov 3, 2009 at 9:18 AM, Evan Martin e...@chromium.org wrote: Generally it should Just Work. If it doesn't, I'd like to hear about it. http://code.google.com/p/chromium/wiki/UsingGit#Renames_and_Copies FWIW, it never used to work at all for me, but it recently started working. Did you change something recently? (I also have been messing around with my env recently -- I may have been using an older version of git-cl accidentally). - 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: revert now, ask questions later? WAS: Reverting a change, the fast way
IMO, I wouldn't mind draconian reverts in the interest of keeping the tree open and allowing the sheriffs some semblance of productivity. OTOH, git makes it really easy for me to un-revert and try again, so maybe I'm biased there. - a On Tue, Nov 3, 2009 at 3:03 PM, Eric Seidel esei...@chromium.org wrote: Could we just automate rollouts and this 5-minute timer? If we have the tools to do automated rollouts, would it be reasonable to add them as a phase in the buildbot? On Tue, Nov 3, 2009 at 2:52 PM, Nicolas Sylvain nsylv...@chromium.org wrote: +1 On Tue, Nov 3, 2009 at 3:38 PM, Avi Drissman a...@chromium.org wrote: I'm OK with that. Just make it clear that the sheriff does have authority. One time when I was sheriff I wanted to revert a broken patch. The author insisted on patching it over and over. He finally got it working about about seven patches and nearly three hours or so, when I was insisting on backing it out after the first 30m. Yes, this is exactly what we want to avoid. The 2-minute rule usually includes: Oops, I forgot to commit a file Let me disable the test I just added, it clearly does not work Oops, before committing I renamed a variable and forgot to change it at one place It also use to mean: Oops, I forgot an include. But this one has been biting us to much in the past, so I leave it at the discretion of the sheriff. I think people need to use their good judgement too. The length of a minute should be inversely proportional to the number of people trying to commit during this time of the day. Nicolas Avi On Tue, Nov 3, 2009 at 5:34 PM, Peter Kasting pkast...@google.com wrote: On Tue, Nov 3, 2009 at 2:08 PM, Ojan Vafai o...@chromium.org wrote: To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in 2 minutes. How about: If a change closes the tree, the change author has 1 or 2 minutes to respond to a ping. The change should be reverted if the author doesn't respond, if he says to revert, or if he does not say he has a fix within the next 5 minutes. I can't fix _any_ problem in 2 minutes. But I can fix most of them in 5. The goal is to allow the author a reasonable chance to fix trivial problems before we revert. And I think the tree should go ahead and close during that interval. 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: Singleton, LazyInstance, and testability
Why don't you pass an Extension instance? It seems like you are violating the contract of that notification by not doing so, and even if you solve this problem, other similar problems would be likely to happen again in the future. - a On Tue, Nov 3, 2009 at 11:49 PM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: I encountered another problem related to Singletons in unit tests. PluginService is a Singleton, and it listens to extensions notifications. In one of my tests when I was using the extensions notifications the PluginService crashed because I passed NULL as the Extension* - because the listener I was testing didn't even read that value, but PluginService did (it was unexpected). I tried to fix the issue by adding a shadow AtExitManager to the test which instantiated PluginService (resource_dispatcher_host_unittest.cc). And then another crash appeared on Windows: NPAPI::PluginList is a LazyInstance, which means that the shadow AtExitManager destroyed it, but it didn't re-instantiate itself the next time it was used. Is there a big difference between a Singleton and LazyInstance? I was thinking about making NPAPI::PluginList a Singleton instead... By the way, I have a more general fix in the queue (an unwanted Singleton detector). If you're interested, please star http://crbug.com/12710. It seems that the most recent gtest (1.4.0) has necessary support. --~--~-~--~~~---~--~~ 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: readability extension (experience writeup)
On Sat, Oct 31, 2009 at 4:29 PM, Evan Martin e...@chromium.org wrote: I've updated this to the browser actions API. Thanks for trying again. - The docs are behind the code (had to read the code once or twice to figure out what was going wrong). Were you using trunk or dev? The docs on http://code.google.com/chrome/extensions are the ones for the dev channel, and they should be correct. Though there is some support for browser actions on dev right now, it was not complete and the API was in flux, so we purposely didn't document it. If you developed against that, you're probably going to have to change it for the next dev channel (sorry). You can always see the trunk docs, here: http://code.google.com/chrome/extensions/trunk - Not exactly clear sometimes which error console you're supposed to look at; the workflow of reload, see what error happened this time takes a few too many clicks. Would be nice if chrome://extensions/ remembered whether I had the developer tools turned on or off. We have a bug to keep the inspector open (http://crbug.com/25287). It is nontrivial to fix, but we're hoping to get it in for beta. As for knowing which console to look at, I agree it sucks. For now, we're going to have to just document it, but I hope to come up with some kind of master console output later. - 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: A tale of two (or more) syncing extensions, and a proposal
On Tue, Oct 27, 2009 at 8:55 PM, Tim Steele t...@chromium.org wrote:
I can take a stab at more formal heuristics for bookmarks, at least. We
will have a better idea of actual limiting parameters for bookmarks (as in
how many operations in a certain time frame is reasonable) once the
ExtensionsActivityMonitor I just landed percolates and we can aggregate
across representative sample data it produces.
A couple thoughts:
a) I think it is overly clever to hash the changes to the bookmarks
and count per unique-params. This can be easily or accidentally
defeated by just doing something like update({title:foo}),
update({url:blech}), over and over, anyway. Instead, at least for
bookmarks, I think a simple per-item-count is very reasonable. It
doesn't make sense to me to update the same bookmark more than a few
times per minute. An easy heuristic could be that updating the same
bookmark more than twice a minute sustained over 10 minutes. For
creates it's a bit tricker. In that case, maybe the best we can do is
the same combination of properties.
b) What is wrong with solving this by rate limiting the communication
between the Chrome sync client and the Chrome sync server? It seems
like that would be more foolproof; if the client tries to send too
many updates for any reason, they are rate limited.
- 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: A tale of two (or more) syncing extensions, and a proposal
On Wed, Oct 28, 2009 at 10:42 AM, Nick Carter n...@chromium.org wrote: On Wed, Oct 28, 2009 at 8:46 AM, Scott Violet s...@chromium.org wrote: I'm confused by the diagram. In step 5, why does F' get added to the model. Are you saying the 'extension cloud' service always creates a new bookmark, without verifying if the model already has a matching entry? This is indeed the behavior we're seeing with one extension -- delete all old bookmarks, write a whole new copy. One thing I forgot I wanted to point out about that extension in particular. In Tim's proposal he says: ...in Chrome Sync, we try really hard to not get into feedback loops with ourselves, and not to make unnecessary / no-op changes, but we have seen at least one extension (GBX) periodically delete all bookmarks and then recreate all bookmarks with no changes to the nodes in question. That seems almost positively unnecessary. If we detect that they have removed the same tree (from the same root position) 10 times in one day, this does really seem fishy and enough to trigger limiting. But at that point the onus is on extension developers, not us. It sounds like Tim agrees here, but I just want to reiterate: we should not be the arbiters of quality or taste wrt extensions. There will be buggy and crappy extensions. We should try and design things such that you have to go out of your way to write crappy things, but at the end of the day we want this to be an open environment where people surprise us -- both in good and bad ways :). If we need to protect our own systems that is fine, but other than that we shouldn't prevent things in the extensions system, even if they don't seem to make much sense. -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: A tale of two (or more) syncing extensions, and a proposal
On Wed, Oct 28, 2009 at 11:39 AM, Tim Steele t...@chromium.org wrote:
The update{foo} update{blech} case is most likely a different kind of
failure, though, and I was thinking we could limit that with a generic cap
on just the number of updates in a period of time. From the data we have
seen so far, most common is 'update{foo}' in a loop type behavior. But if
the generic cap gets us far enough along, then I agree simpler is better.
Cool. I hope and suspect we can get far enough with the simple approach.
We have this. The problem is that the user doesn't even realize the
extension is spamming the server. Our server knows the client is producing a
lot of traffic, that's all. So what happens is we limit the client and the
user is left bewildered and helpless because a rogue extension is eating
away his quota. What I just landed was a way to correlate how many of our
sync commits originate from extensions, but we need to find a way to solve
the problem once we learn from the data. The reason I suggested this, is
because it dawned on me that this problem affects any extension author
trying to send updates from Chrome to their servers. If extension Bob and
Eve are installed, Eve can bring down Bob's service because of a silly bug.
I was proposing we just add some layer of protection in here, because we
can, to help our extensions developers out (and Chrome Sync in the process).
Thanks for explaining. Makes sense to me.
- 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: Extensions performance data
Thanks for doing this.
It seems like we should shoot for getting the cost of browser/page
actions down to zero, and the cost of content scripts to zero above
similar script running in page.
I will create bugs for these two (plus another bug just to create
startup tests for browser actions).
- a
On Tue, Oct 27, 2009 at 9:26 AM, Antony Sargent asarg...@google.com wrote:
As we move closer to getting extensions enabled on the beta channel, we
wanted to summarize the current data we have on performance. The 3 sources
we have right now are startup tests, page cycler tests, and script injection
histograms.
Content scripts get injected with a separate isolated world javascript
context into pages matching an extensions match patterns, and have direct
access to the DOM of the page but not its javascript context. See our
documentation here for more details. These scripts can be arbitrarily
expensive depending on the code extension developers write, so for our perf
tests we are interested in the minimum cost to setup the isolated world and
run a minimal script. We use an essentially empty content script in startup
and page cycler tests (it just declares and initializes 3 variables with
integer values).
Startup Tests
We added 4 tests to the normal startup ones: extension_content_scripts{1,50}
and extension_toolstrip{1,50}. For the content script tests, instead of
loading about:blank we have them load a simple file-url html page with no
script, and have an extension installed that injects either 1 or 50 content
scripts.
The toolstrip tests need to be replaced with browser actions versions, but
they show the startup impact of having an extension with 1 or 50 toolstrips
installed, which for the 1 extension case is about 7% (8ms).
Focusing on the 1 content script case, depending on which perf bot you look
at (XP Dual/Single Core, Vista Dual/Single Core, Linux/Mac), this causes a
12-20% slowdown in startup compared to about:blank (absolute increase of
14-46ms). In a test I did independently of the buildbots comparing against
loading a simple file-url page that did have script, the slowdown with 1
content script was about 3% (around 9ms).
See the graph for XP dual-core here:
http://build.chromium.org/buildbot/perf/xp-release-dual-core/startup/report.html?history=30
Page Cycler Tests
Since the page cycler tests take a long time to run, we've only added one
extensions case to 2 of the individual data sets: Moz (relatively simple
pages, less javascript) and MoreJS (more complicated DOM and javascript).
The Moz set runs very quickly, typically something like 40ms per page on a
fast machine. The MoreJS set runs much more slowly, typically something like
190-200ms per page on a fast machine. We use the _extcs1 suffix on the
test names to denote extensions with 1 content script.
Time
Moz: 10-17% increase in cycle time (absolute increase of ~4-5ms per page)
MoreJS: 2-4% (absolute increase of ~5-10ms per page, perhaps a little higher
than Moz due to v8 having more garbage to collect?)
http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=30
http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=30
In tests I ran independently of the buildbots, the increase in cycle time
for multiple extensions with 1 content script each was roughly linear in the
number of extensions as we'd expect (adding about 5-10ms per page per
extension).
Memory
There are a lot of memory statistics gathered for page cycler tests, but
I've just focused on renderer peak working set (ws_peak_r):
Moz: 14% increase (absolute ~10MB)
MoreJS: (essentially no increase discernable on graph)
http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=30graph=vm_final_r
http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=30graph=ws_peak_r
Content Script Injection Histograms
We've added histograms to measure aggregate data on the number of content
scripts and css files that get injected into pages, and how long that
process takes, so we can understand how real world extension content scripts
perform. There are two options for when content scripts run, either at
document_start (before the document's html/js has been parsed) or
document_end (just before onload event fires, the default and most
useful/popular option by far for extension developers). Whether a slow
content script can affect perceived page load time depends a bit on the page
in question; in some informal tests I found many popular pages that didn't
seem to layout until after body onload fired, but some that did.
After you've been browsing for a while with some extensions installed, open
a tab and go to about:histograms/Extensions, and you'll see histograms named
Extensions.Inject{Start,End}_{ScriptCount,CssCount,Time}. The Start vs.
End part of the name refers to when injection took place, and Time
refers
[chromium-dev] Re: Code Yellow: Dev Channel Release On-Hold This Week
On Tue, Oct 27, 2009 at 4:04 PM, Anthony LaForge lafo...@google.com wrote: Moving forward, the TPMs are going to be more closely monitoring the P0 and ReleaseBlock-Dev (which we will treat effectively synonymously). Please help us to ensure labels on bugs are accurate. This part in particular, I am happy about. It is nice to have a label that means please please do not release a dev channel release with this bug in it. - 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: A tale of two (or more) syncing extensions, and a proposal
Have not read all of it yet, but am in favor in general of having some sort of quota for extension api calls to protect from meltdown. We have a very convenient chokepoint to implement this in our system, so it would just be a matter of a more detailed design of the heuristics to use for each API type. - a On Wed, Oct 21, 2009 at 5:08 PM, Tim Steele t...@chromium.org wrote: [re-sending from correct email account] Hi, I wrote up a document that discusses some interesting unintentional relationships that can exist between independent extensions, and how this general problem also currently affects the browser sync engine. This issue was discovered from trying to explain the primary symptom of unusually high syncing traffic generated by Chrome clients. Please find it here: A Tale of Two (or more) Sync Engines You should read that before continuing! This led to me thinking about what we do long term, short term, or basically before Chrome Sync and extensions are running in parallel in a beta channel environment. You'll see a bit of this at the end of the first document, but after posing the problem as an extensions problem I ended up at a random idea that I think makes at least a little sense, though I admit I was having fun thinking and writing about it so maybe I missed some major roadblocks along the way. There are downsides, mainly revolving around the added hand-holding we would impose on extensions. Please read! Hoping for comments and feedback. Extensions API quotaserver In addition to that, Colin and Todd (cc'ed) brought up some sync specific ideas they have (I mention it a bit at the end of the first doc). We'll try to get a separate thread going about this soon! Thanks! Tim --~--~-~--~~~---~--~~ 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: Reminder: File bugs for behavior changes on different platforms!
But is it correct chromium practice to actually close the blockee while it is being blocked? To cut to the chase, I'm against having a master bug that represents a UI change on all platforms. I've found it works better for me to have one bug for each platform that are all independent. I guess I just hate having bugs linger for a long time with tons of changes against them. - a On Tue, Oct 20, 2009 at 11:49 AM, Anthony LaForge lafo...@google.com wrote: Nico beat me to it, but that's precisely correct, you just need to add the child bug ids to the blocked by line in the parent bug. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Oct 20, 2009 at 11:30 AM, Nico Weber tha...@chromium.org wrote: In the blockee, enter the blockers in the Blocked by line at the bottom. On Tue, Oct 20, 2009 at 11:21 AM, Aaron Boodman a...@chromium.org wrote: On Tue, Oct 20, 2009 at 11:16 AM, Ben Goodger (Google) b...@chromium.org wrote: - mark the new bug as blocking the original bug for the work, even if the original bug is now or soon will be closed. Can you explain more what you mean by this? What is the way to mark a bug as blocking? How can the blockee be closed if it is blocked by another bug that is open? - 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: [DESIGN DOC] registerProtocolHandler HTML5 API
On Tue, Oct 20, 2009 at 6:35 PM, Alex Russell slightly...@google.com wrote: The first was to perhaps use AppCache manifests to declare this sort of metadata. You might have some sort of header in the manifest that describes the page as persistently bless-able (much like Ben's description), followed by the list of requested permissions. UA's would fetch the AppCache, detect that it corresponds to a blessable app and handle the process of granting privs enumerated in the manifest. It'd be up to the UA to find some way to offer the ability to bless the app/page in it's UI, but in the case of Chromium you could imagine this all getting integrated into a process by which you bless an app and it asks for perms like: * app-mode desktop shortcut * location * persistent storage that's not subject to cache clearing There is a problem with leaning on app cache. We cannot grant extended permissions to resources served over plain-old HTTP because of MITM. The resources could be intercepted and malicious third parties could gain the extra permissions. This is what led to the current signed-package design of the Chromium extension system. If you really want to serve resources live (not have to package an application), then you could restrict extra permissions to apps that are served over SSL. Or perhaps extend appcache to allow signatures for each resource. Or maybe we continue to insist that we don't need or want elevated permissions for any kinds of apps. - 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: [chromium-extensions] Re: Desktop Notifications
Hello, sorry for not replying sooner. The reason I think nobody responded is that this proposal is not technically part of the extensions system, but would be available to all web pages (including extensions). I think that the wider mailing list chromium-dev may contain people who know what the status is. - a On Mon, Oct 19, 2009 at 10:18 AM, Marcos Aruj marcos.a...@gmail.com wrote: Hi again, Are there really no news in this? Is the notifications API going live for the next release? Any docs on how can we use it now if it's available? We depend on this for some functionality and want to avoid DIV injection since it brings some UI issues when switching pages, override flash contents, etc... Thanks again, Marcos On Sun, Oct 11, 2009 at 7:47 PM, Marcos Aruj marcos.a...@gmail.com wrote: Any news on this? We are really interested in this. Thanks for your help. Marcos On Fri, Oct 9, 2009 at 1:00 AM, Raymond Lee raymondlee...@googlemail.com wrote: Hi all, We are planning to use the desktop notifications in our extension. http://dev.chromium.org/developers/design-documents/desktop-notifications Does anyone when the desktop notifications API will be ready? Best Regards Raymond -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [extensions] Bug gardening
As promised in meatspace: http://code.google.com/p/chromium/issues/list?q=Area:extensions+releaseblock:betasort=pri We're now getting to the point where we're running out of major feature work (hooray!), so what should be P1/P2/P3 is squishier. Please feel free to push back and make changes where I've gone wrong. - 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: [chromium-extensions] HTML5 spellcheck attribute
This is not really an extensions question. I think you want chromium-...@. - a On Thu, Oct 15, 2009 at 9:10 AM, Mixe twitter...@googlemail.com wrote: Chrome does not support HTML5 spellcheck attribute? Then why spellchecking is enabled by default? How we can disable (using JS) spellchecking into INPUT and TEXTAREA elements? For example, when a user put the path or another specific text into a text box, Chrome spellcheck always put red lines under the text :( A user may think that something is wrong. --~--~-~--~~~---~--~~ 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: [LTTF][WebKit Gardening]: Keeping up with the weeds.
On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov dglaz...@chromium.org wrote: * [ your idea goes here ] I'm probably going to get things thrown at me, but ... I don't think the idea of a webkit sheriff really works. By definition the webkit sheriff is pulling in code that they don't know how to fix and aren't allowed to rollback. So creating bugs is the only option. I feel like the effort of keeping up with upstream (and making any changes required upstream to make that easier) should be centralized in a dedicated team. The fun of building new platform features comes hand-in-hand with the non-fun of keeping up with upstream. Sorry. - 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: [LTTF][WebKit Gardening]: Keeping up with the weeds.
On Tue, Oct 13, 2009 at 1:36 PM, Aaron Boodman a...@chromium.org wrote: I'm probably going to get things thrown at me, but ... Balls, I just checked with Dimitri and we already do my proposal. Ignore. - 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] Friendly reminder: don't let changes rot
Lots of the engineers on Chromium aim to turn around code reviews in hours. Some (like me) have even committed to making it more important than their own work. It makes me sad when I find code reviews that have been waiting for lgtm from me for weeks. If someone doesn't reply to your review or response within a half day, you should definitely ping them. It isn't rude. It may have simply slipped by, or there may be a misunderstanding about whose court the ball is in. Also, I have noticed a convention developing where, when sending reviews or responses, the target is pinged in irc. Like this: aboodman: fyi: http://codereview.chromium.org/... I think this is totally awesome and encourage it, at least to me. Thanks, - 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: Friendly reminder: don't let changes rot
On Thu, Oct 8, 2009 at 10:45 AM, Scott Violet s...@chromium.org wrote: Perhaps I'm too old school here, but I'll ask anyway. Why use IRC for what is meant as a ping to one person? If you want to let the reviewer know immediately, isn't an IM a better approach. That way you keep the noise on the irc channel down. I meant ping in an abstract sense. Non-communication-mechanism specific. It could be a private ping on IRC, or a ping on some other IM system. Non-googlers wouldn't necessarily have IM addresses for other people working on Chromium, though, so I used IRC as an example. - 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: UI across multiple platforms
FWIW, on extensions, what we have been finding works is to file separate bugs for each platform's UI implementation. It is just too much code to track with one bug. You end up with these mega bugs that never close. We label each bug OS-whatever the case may be - a On Wed, Oct 7, 2009 at 10:01 AM, Ben Goodger (Google) b...@chromium.org wrote: Because we have different frontend codebases on different platforms, it's important that we strive to maintain feature parity between them. For this reason whenever we implement a modification to the UI in substance (e.g. add a feature, change a behavior) we should make sure to file a bug for the other platforms as well (or implement it there if you're capable). We should probably have some sort of platform parity label in the bug tracker so we can track these divergences. -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] [extensions] first cut at beta bug list
As promised in today's extensions meeting, I've taken a first pass to identify extensions beta bugs. As a sort of new novelty, I've also attempted to use the Priority and Size labels, so that we can know what we should do first, and how much it's going to hurt. Please see: http://code.google.com/p/chromium/issues/list?q=Area:extensions+releaseblock:betasort=pricolspec=ID+Pri+Status+Summary+Owner+Mstone+Size Extensions people: Please take a careful look through this and check my work. Go ahead and add anything you think should be on the list or comment if you think something should not be. Special note: All browser action and popup bugs on mac and linux are blocked behind the extensions team deciding that we are definitely doing this feature. We hope to make this decision Friday this week with the help of the UI posse. Thanks! - 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: UTF8 and Skia
On Sat, Oct 3, 2009 at 11:25 PM, Adam Langley a...@chromium.org wrote: On Sat, Oct 3, 2009 at 6:29 PM, Aaron Boodman a...@chromium.org wrote: I double-checked that the font I'm using actually contains these characters (by rendering them using HTML). When rendering via HTML a browser will use any font on the system which provides those codepoints. I'm not sure how one could use HTML to check if a font provides some code points. So you might be mistaken that the font includes the characters that you're looking for. Argh, that was it. I was predisposed to thinking that this particular font had this particular code point, so I did not check this very carefully. Thanks, - 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] UTF8 and Skia
I'm trying to use SkCanvas::drawText() with mulitbyte UTF-8 characters, but they always come out rendered as a square box placeholder glyph. I've walked into the code and I can see that Skia is indeed parsing the UTF-8 correctly, and it comes up with the correct code point. And in SkGlyphCache, it finds a matching glyph and returns it. So it appears that the matching glyph just looks like a box for some reason. I double-checked that the font I'm using actually contains these characters (by rendering them using HTML). Does anyone know what might cause this? thanks, - 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: When disabling a test, please assign to whoever wrote it
Seriously. In a project as big as Chrome, tests are *critical* and a disabled test can hurt a team within just a few days. This has happened to me a few times and it is terrifying to find out a test that you think was proving you are working had actually been disabled. Disabling bad tests is super important, and I'm not arguing against that. Just make sure that someone knows that it was done who can take action on it. - a On Tue, Sep 22, 2009 at 12:40 PM, John Abd-El-Malek j...@chromium.org wrote: It only takes a few moments to figure out this information, and ensures that the bug lands on the right person's desk. http://src.chromium.org/viewvc/chrome/trunk/src/ can show who wrote the initial test For commits before we moved to the open source repository, look at http://chrome-corpsvn.mtv/viewvc/trunk/?root=chrome (internal only) 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: Shipping features behind a run-time flag can sometimes still be dangerous
It is really useful to have early code compiling and running as much as possible on all platforms right from the beginning. This catches a lot of issues early in the development cycle and prevents scary monolithic integration phases. Could we also fix this problem by doing something in the bindings-generation phase to just not have these features' constructors created? - a On Mon, Sep 21, 2009 at 2:43 PM, Anthony LaForge lafo...@google.com wrote: That raises an excellent point! I would extend those compile time flags to include prevent experiments from getting into beta/stable as well. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Mon, Sep 21, 2009 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote: I think we need to re-consider our practice of shipping beta/stable browsers with experimental features hidden behind flags--at least when they have any side-effects in JavaScript. An example of where this has bitten us is http://code.google.com/p/chromium/issues/detail?id=22181 Although part of the problem is the way they coded things (since both SessionStorage and LocalStorage use the Storage interface, its existence doesn't imply SessionStorage is necessarily available), this bug has pointed out a couple problems. 1) constructors are visible to javascript even when the feature is totally disabled. 2) When an object (like the Storage interface) wraps a NULL it shows up as null in JavaScript. Since returning NULL/0 is the standard thing to do when the feature is disabled, this means that the functions return null when disabled at run time and undefined when disabled at compile time. 3) Even if we fixed the undefined problem, |'localStorage' in window| would still return true. We've been discussing these issues in a WebKit-dev thread (https://lists.webkit.org/pipermail/webkit-dev/2009-September/thread.html#9860) and although (2) is probably something we can solve without too much effort (Drew is going to look into it), (1) and (3) probably aren't worth changing if the runtime flag is just temporary. As such, I feel fairly strongly that we should start disabling features behing a run-time flag with compile-time flags in future beta/stable builds if they have any side-effects in JavaScript. I'm working with Anthony LaForge to fix this for LocalStorage/SessionStorage right now. I'm not sure if it's worth doing preemptively for other features, but it might be. I definitely think we should do it the next time we cut a beta build. Especially if there's a chance the beta will be an ancestor of a stable channel release. J --~--~-~--~~~---~--~~ 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: JSNES: A NES emulator that runs well in Chrome
I was stoked to play SMB III, but without music it isn't the same :-/. - a On Thu, Sep 17, 2009 at 10:14 AM, Peter Kasting pkast...@google.com wrote: http://benfirshman.com/projects/jsnes/ I highly recommend you use Google Chrome to play JSNES. ... it just about runs on Firefox 3.5 or Safari 4, but it's hardly playable. I wonder if we can get this guy to throw this into chromeexperiments.com ? 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: JSNES: A NES emulator that runs well in Chrome
On Thu, Sep 17, 2009 at 11:59 AM, Evan Martin e...@chromium.org wrote: - new insano Windows machine: 60fps, feels just right I am happy that I could contribute insano (though I believe the correct spelling is insane-o) to the Chromium lexicon. - 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: [extensions] RFC: NPAPI manifest change
On Fri, Sep 4, 2009 at 10:23 AM, Evan Martine...@chromium.org wrote: We actually already content sniff plugin files on Linux, so that we don't print a loading error when attempting to load a wrong bit-ness plugin. (Printing a loading error breaks layout tests.) Thankfully, ELF has this information in the fifth byte of the file, just after the four-byte magic number, so it's not too heinous. Yeah, I am kinda curious whether this approach can work generically without adding anything to the manifest. Particularly since there is a naming convention for shared libraries on all platforms. I don't really know enough about this area to have a strong opinion, though. - 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: [extensions] RFC: NPAPI manifest change
On Thu, Sep 3, 2009 at 9:08 PM, Adam Barthaba...@chromium.org wrote: On Thu, Sep 3, 2009 at 7:51 PM, Matt Perrympcompl...@chromium.org wrote: public: false, Does that mean the default is now true? It's probably a good idea to make the default value false here. The default is currently false: http://chromeextensionsdocs.appspot.com/npapi.html Also: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/extension.cc (search for keys::kPlugins) - 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: PSA std::cout / std:cerr in tests
Actually, I found two: thumbnail_store_unittest.cc:134: std::cout Max diff btwn original and encoded image (b,g,r,a) = (v8_unit_test.cc:91: std::cout message \n; - a On Tue, Sep 1, 2009 at 10:49 AM, Aaron Boodman a...@chromium.org wrote: Yeah, no problem. Do you have the test in question off hand? On Tue, Sep 1, 2009 at 10:46 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: That's fine, we simply filter to ERROR by default. Can you change it to ERROR (if that's what you think it is) Thanks, M-A On Tue, Sep 1, 2009 at 10:44 AM, Aaron Boodman a...@google.com wrote: On Tue, Sep 1, 2009 at 10:43 AM, Aaron Boodman a...@google.com wrote: Sorry. I tried LOG(INFO) and LOG(WARNING) and neither worked. I then jumped to just using std::cout. - a On Tue, Sep 1, 2009 at 10:40 AM, Marc-Antoine Ruel mar...@chromium.org wrote: Please never use std::cout in unit tests. Use LOG(ERROR) if you want to output debug information about internal error state. That will log the correct process id. The reason is dead simple, it makes automatic log processing hard and Pawel's regexp miserable. If you still want to use cout, at least please use \n or std::endl. Thanks, M-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: PSA std::cout / std:cerr in tests
Yeah, no problem. Do you have the test in question off hand? On Tue, Sep 1, 2009 at 10:46 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: That's fine, we simply filter to ERROR by default. Can you change it to ERROR (if that's what you think it is) Thanks, M-A On Tue, Sep 1, 2009 at 10:44 AM, Aaron Boodman a...@google.com wrote: On Tue, Sep 1, 2009 at 10:43 AM, Aaron Boodman a...@google.com wrote: Sorry. I tried LOG(INFO) and LOG(WARNING) and neither worked. I then jumped to just using std::cout. - a On Tue, Sep 1, 2009 at 10:40 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Please never use std::cout in unit tests. Use LOG(ERROR) if you want to output debug information about internal error state. That will log the correct process id. The reason is dead simple, it makes automatic log processing hard and Pawel's regexp miserable. If you still want to use cout, at least please use \n or std::endl. Thanks, M-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: Formatting substrings in a views::Label
On Thu, Aug 27, 2009 at 12:06 AM, Ben Goodger (Google)b...@chromium.org wrote: I actually don't like having a mix of HTML/native UIs in the product. When we switched to the NTP from the old Destinations page we made the decision to have the content of tabs feel webby and the content of dialogs feel dialoggy. As a result the NTP now feels pleasantly webby, but many of the HTML dialogs don't feel dialoggy (focus issues, key accelerators, etc). This is why I decided to go with native for the install dialog. I feel like doing this the way that the about dialog is done would be incredibly painful and buggy because of wrapping issues. Also, at least on my machine (I am one of those weirdos that uses vista with the classic theme), the about dialog does not look right. The alignment of the links is slightly off. I would prefer to use the platform APIs that already know how to do this correctly. I'm thinking of adding something like set_bold_delimiter(const std::string) on Label. You could use it like this: myLabel-set_bold_delimiter(*); myLabel-set_text(hello *world*); Is this totally lame? - 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: Formatting substrings in a views::Label
Argh. Forgot attachment. On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodmana...@chromium.org wrote: I'm playing with different ideas for the extension install dialog, and would like to do something like the attacked mock. I can see that there is no support for this in Label presently and I'm told by Dean that the APIs for doing this are different across platforms. Is it worth adding an abstraction to Label for this? - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~--- attachment: dialog.png
[chromium-dev] Formatting substrings in a views::Label
I'm playing with different ideas for the extension install dialog, and would like to do something like the attacked mock. I can see that there is no support for this in Label presently and I'm told by Dean that the APIs for doing this are different across platforms. Is it worth adding an abstraction to Label for this? - 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: Subversion tags for stable/beta/dev?
Checking up on this. I don't see the tags in src.chromium.org yet. Can we get this going for the next dev release? - a On Tue, Aug 11, 2009 at 1:30 PM, Aaron Boodmana...@chromium.org wrote: Hooray, thanks Mark. - a On Tue, Aug 11, 2009 at 1:22 PM, Mark Larson (Google)m...@chromium.org wrote: Yes, I think we can add something so each channel has a persistent URL. I'll discuss with Aaron offline. On Sat, Aug 8, 2009 at 00:17, Darin Fisher da...@chromium.org wrote: On Fri, Aug 7, 2009 at 11:59 PM, Aaron Boodman a...@chromium.org wrote: Ok, sorry I got defensive. Short answer is we don't know if it can handle the load. I will add a bug to myself to investigate. Oh, I didn't think you were overly defensive... Do you have any opinion on adding the tags? I guess the cost would be that when we do new releases the release manager would have to update the tag. It sounds like a reasonable request to me. -Darin - a On Fri, Aug 7, 2009 at 11:45 PM, Darin Fisherda...@chromium.org wrote: I totally agree. Reducing the cost of maintaining docs is very nice indeed ;-) -Darin On Fri, Aug 7, 2009 at 11:36 PM, Aaron Boodman a...@chromium.org wrote: We can put a cache in front of it if needed. Actually I'd like to put something dumb and simple in front of it anyway, so we could have shorter URLs that aren't tied to viewvc. But I think having the docs be checked in and not having a separate deploy step is worth some extra complexity on the frontend. In Gears the docs being out of date, or out of sync with the various versions was an annoying problem. - a On Fri, Aug 7, 2009 at 9:55 PM, Darin Fisherda...@chromium.org wrote: This is pretty cool, but my experience with ViewVC is that it is kind of slow. Do we know if it can handle the additional load this will generate? -Darin On Fri, Aug 7, 2009 at 3:23 PM, Aaron Boodman a...@chromium.org wrote: Hi all, I was wondering if the release managers could add a tag in Subversion for each of the stable, beta, and dev release channels. I want a ViewVC URL that I can give people that will always refer to the version of the code that is on stable (or whatever) at that moment. The reason I want to do this is because the extensions possee is checking our docs into source control, so that they can be viewed live from viewvc. They're still in progress, but you can see them starting to come together here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/index.html The cool thing about this approach is that when we branch releases, the docs from trunk will be branched too. So the docs for a certain release area always with the code for that release. If we had the aforementioned tags, the canonical URL for, eg, the stable extension docs could just be: http://src.chromium.org/viewvc/chrome/branches/stable/src/chrome/common/extensions/docs/index.html - 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] How to keep aware of bug changes for a particular label
I would like to be cc'd on every bug that has the label: Area-Extensions. Is this possible to automate? How do other subteams keep aware of bugs changes? - 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: How to keep aware of bug changes for a particular label
Darin, can you make this list of people automatically cc'd for Area-Extensions? aa asargent nickbaum erikkay mpcomplete rafaelw - a On Mon, Aug 17, 2009 at 11:27 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: You need someone with admin privileged on bugtracker do that for you. For example, I'm on CC for every FlakyTest bug, and Darin helped me do that. On Mon, Aug 17, 2009 at 11:25, Aaron Boodman a...@chromium.org wrote: I would like to be cc'd on every bug that has the label: Area-Extensions. Is this possible to automate? How do other subteams keep aware of bugs changes? - 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: How to keep aware of bug changes for a particular label
Whee! Thanks. On Mon, Aug 17, 2009 at 11:38 AM, Darin Fisherda...@chromium.org wrote: Done On Mon, Aug 17, 2009 at 11:36 AM, Aaron Boodman a...@chromium.org wrote: Darin, can you make this list of people automatically cc'd for Area-Extensions? aa asargent nickbaum erikkay mpcomplete rafaelw - a On Mon, Aug 17, 2009 at 11:27 AM, Paweł Hajdan Jr.phajdan...@chromium.org wrote: You need someone with admin privileged on bugtracker do that for you. For example, I'm on CC for every FlakyTest bug, and Darin helped me do that. On Mon, Aug 17, 2009 at 11:25, Aaron Boodman a...@chromium.org wrote: I would like to be cc'd on every bug that has the label: Area-Extensions. Is this possible to automate? How do other subteams keep aware of bugs changes? - 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: Can't edit others' codereviews?
On Sun, Aug 16, 2009 at 2:47 PM, Peter Kastingpkast...@google.com wrote: I really need the ability to edit others' issues, including closing them. I don't really care up or down on the close button issue, but please restore my ability to edit and close others' changes. Yeah, I liked the feature too, for the same reason at Peter: I would frequently close contributors changes after they were committed. - 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: Subversion tags for stable/beta/dev?
Hooray, thanks Mark. - a On Tue, Aug 11, 2009 at 1:22 PM, Mark Larson (Google)m...@chromium.org wrote: Yes, I think we can add something so each channel has a persistent URL. I'll discuss with Aaron offline. On Sat, Aug 8, 2009 at 00:17, Darin Fisher da...@chromium.org wrote: On Fri, Aug 7, 2009 at 11:59 PM, Aaron Boodman a...@chromium.org wrote: Ok, sorry I got defensive. Short answer is we don't know if it can handle the load. I will add a bug to myself to investigate. Oh, I didn't think you were overly defensive... Do you have any opinion on adding the tags? I guess the cost would be that when we do new releases the release manager would have to update the tag. It sounds like a reasonable request to me. -Darin - a On Fri, Aug 7, 2009 at 11:45 PM, Darin Fisherda...@chromium.org wrote: I totally agree. Reducing the cost of maintaining docs is very nice indeed ;-) -Darin On Fri, Aug 7, 2009 at 11:36 PM, Aaron Boodman a...@chromium.org wrote: We can put a cache in front of it if needed. Actually I'd like to put something dumb and simple in front of it anyway, so we could have shorter URLs that aren't tied to viewvc. But I think having the docs be checked in and not having a separate deploy step is worth some extra complexity on the frontend. In Gears the docs being out of date, or out of sync with the various versions was an annoying problem. - a On Fri, Aug 7, 2009 at 9:55 PM, Darin Fisherda...@chromium.org wrote: This is pretty cool, but my experience with ViewVC is that it is kind of slow. Do we know if it can handle the additional load this will generate? -Darin On Fri, Aug 7, 2009 at 3:23 PM, Aaron Boodman a...@chromium.org wrote: Hi all, I was wondering if the release managers could add a tag in Subversion for each of the stable, beta, and dev release channels. I want a ViewVC URL that I can give people that will always refer to the version of the code that is on stable (or whatever) at that moment. The reason I want to do this is because the extensions possee is checking our docs into source control, so that they can be viewed live from viewvc. They're still in progress, but you can see them starting to come together here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/index.html The cool thing about this approach is that when we branch releases, the docs from trunk will be branched too. So the docs for a certain release area always with the code for that release. If we had the aforementioned tags, the canonical URL for, eg, the stable extension docs could just be: http://src.chromium.org/viewvc/chrome/branches/stable/src/chrome/common/extensions/docs/index.html - 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 8:50 AM, Avi Drissmana...@google.com wrote: Right now there's no real control over themes. Once they're installed, they're permanently installed; there's no easy way to remove them We should completely drop the concept of theme installation. We can do this by changing the language around themes in the UI. For example, instead of get themes, the button could read pick new theme. There can only be one theme active at a time, so whether the themes are still on your computer when you switch away from them is sorta irrelevant. From a cleanliness perspective, I would like to remove them, but the fact that you currently can't remove a theme after you switch away from it should not be an issue for most people. (chrome://extensions used to list them so they could be removed, but now you can't even do that). So why not let the user switch? I'm not saying the user shouldn't be able to switch. I'm saying why have two ways to switch, one that is inferior to the other. Assuming that the themes gallery will be the only source of themes and that the users would just have to go there is silly. The Get Themes button is only a suggestion, and while we have themes that we think are nice, there will be third-party providers. Of course, but if you want to reinstall one of those themes, you can just go back to the page you originally got it from. Why is it useful to have a list of every theme you have ever picked in the options menu? Like others have said, I expect this list to get long and there is no way to manage it. If you don't think the popup does an adequate job of showing previews/management, you are absolutely correct. I'd love a chrome://themes page that - showed installed themes - allowed switching themes It sounds like you want something almost like favorite themes - a list that can be managed. I can see some minor utility in this above just going back to the web page that has the theme you want and picking it again, but it seems pretty thin. I don't believe it is worth the implementation, maintenance, and simplicity costs to implement it. -- with previews Why do we need a separate concept of preview when you can just install a theme, and if you don't like it switch back to the one you had before. If the infobar said (and did) undo instead of back to default, doesn't this meet the need? -- with deinstall buttons Why does it matter to uninstall a theme that you aren't using? Particularly if we automatically delete theme resources when they are switched away from? - allowed tinting for themes (which I've heard only Cole talk about but no one else mention) Once we have this, you're right that we'll need some UI around it. I'd prefer to wait until we know what the needs. - 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 9:24 AM, Steve Vandebogartvand...@google.com wrote: Undoubtedly, there will be hundreds of themes, finding the same one you were using last week before you decided to try a different one will be a daunting task. From a usability perspective, it seems to me that keeping around a small set of recently used themes makes sense. That seems better. I'm a lot more interested in a recently used themes or previously used themes (in the style of the history page) chrome://themes/ page than having the dropdown in the options menu. On the same page, we could combine the theme customization controls (tinting, etc). - 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 10:05 AM, Peter Kastingpkast...@google.com wrote: [Edit: right as I was going to send this, I see you seem to be thinking along similar lines.] You're right that a dropdown with the names of every theme the user has ever used is both unwieldy and unhelpful. How about this: We replace the Options buttons with a page with the 5 MRU themes (perhaps that have been used for more than 1 minute) and the default theme, each with a name, a thumbnail, and perhaps a link to the container page; and a link to the main theme gallery called pick another theme or get more themes or something. Click on a theme and it changes the current theme instantly, but doesn't reorder the list until you close the page. Or, instead of building this list in locally, we could build it in to the themes gallery. When you go there these MRU themes (and the default) are right on the first page. This can also help when you're trying to set up another machine with the theme you like and need to remember what it is. I hope you can understand why having the MRU themes at your fingertips can be convenient even if there is some way (the history page?) to try and find past themes. I think that building this into the gallery makes a lot of sense. And I realized that by preview you all might mean a picture of what this looks like, before you click anything. Similar to what is on the current gallery pages. Incidentally, two other asks: * When installing a theme, give the user a way to switch back to the previous theme (e.g. an infobar). We currently have an option to switch back to the default theme, which is also useful, in different cases. We have a bug open on this. It requires some changes to the themes service. I think that Avi is working on this. Perhaps have both? I'd rather it be just undo alone. We have an emergency exit back to default theme hidden in the prefs. Maybe it could also be in the gallery. * Don't leave crud (.crx files, anything in downloads directory, files in the user profile) on disk for previously installed themes. Clean them up. (Low priority.) It actually deletes them as of right now. You're remembering the way it used to behave. However, they still show up on the downloads page. There is a bug open on that. - 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: Why does Chromium on mac have a theme switch UI in the preferences?
On Mon, Aug 10, 2009 at 11:09 AM, Avi Drissmana...@google.com wrote: On Mon, Aug 10, 2009 at 1:31 PM, Aaron Boodman a...@chromium.org wrote: Incidentally, two other asks: * When installing a theme, give the user a way to switch back to the previous theme (e.g. an infobar). We currently have an option to switch back to the default theme, which is also useful, in different cases. We have a bug open on this. It requires some changes to the themes service. I think that Avi is working on this. I am? Please assign the bug, then, because I was unaware of it. FYI, just so interested parties know the resolution, the work I was thinking of Avi was working on, but it i done now. We can now implement the undo UI, I will create a bug on myself. - 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] Why does Chromium on mac have a theme switch UI in the preferences?
Currently the mac port has a dropdown in the preferences that allows you to switch between themes that happen to be installed. None of the other ports have this, and I think it should be removed from mac. All it allows you to do is switch between themes you have previously installed. How is that better than the web UI, which allows you to switch between all themes in the gallery? - 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: Subversion tags for stable/beta/dev?
We can put a cache in front of it if needed. Actually I'd like to put something dumb and simple in front of it anyway, so we could have shorter URLs that aren't tied to viewvc. But I think having the docs be checked in and not having a separate deploy step is worth some extra complexity on the frontend. In Gears the docs being out of date, or out of sync with the various versions was an annoying problem. - a On Fri, Aug 7, 2009 at 9:55 PM, Darin Fisherda...@chromium.org wrote: This is pretty cool, but my experience with ViewVC is that it is kind of slow. Do we know if it can handle the additional load this will generate? -Darin On Fri, Aug 7, 2009 at 3:23 PM, Aaron Boodman a...@chromium.org wrote: Hi all, I was wondering if the release managers could add a tag in Subversion for each of the stable, beta, and dev release channels. I want a ViewVC URL that I can give people that will always refer to the version of the code that is on stable (or whatever) at that moment. The reason I want to do this is because the extensions possee is checking our docs into source control, so that they can be viewed live from viewvc. They're still in progress, but you can see them starting to come together here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/index.html The cool thing about this approach is that when we branch releases, the docs from trunk will be branched too. So the docs for a certain release area always with the code for that release. If we had the aforementioned tags, the canonical URL for, eg, the stable extension docs could just be: http://src.chromium.org/viewvc/chrome/branches/stable/src/chrome/common/extensions/docs/index.html - 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: Subversion tags for stable/beta/dev?
Ok, sorry I got defensive. Short answer is we don't know if it can handle the load. I will add a bug to myself to investigate. Do you have any opinion on adding the tags? I guess the cost would be that when we do new releases the release manager would have to update the tag. - a On Fri, Aug 7, 2009 at 11:45 PM, Darin Fisherda...@chromium.org wrote: I totally agree. Reducing the cost of maintaining docs is very nice indeed ;-) -Darin On Fri, Aug 7, 2009 at 11:36 PM, Aaron Boodman a...@chromium.org wrote: We can put a cache in front of it if needed. Actually I'd like to put something dumb and simple in front of it anyway, so we could have shorter URLs that aren't tied to viewvc. But I think having the docs be checked in and not having a separate deploy step is worth some extra complexity on the frontend. In Gears the docs being out of date, or out of sync with the various versions was an annoying problem. - a On Fri, Aug 7, 2009 at 9:55 PM, Darin Fisherda...@chromium.org wrote: This is pretty cool, but my experience with ViewVC is that it is kind of slow. Do we know if it can handle the additional load this will generate? -Darin On Fri, Aug 7, 2009 at 3:23 PM, Aaron Boodman a...@chromium.org wrote: Hi all, I was wondering if the release managers could add a tag in Subversion for each of the stable, beta, and dev release channels. I want a ViewVC URL that I can give people that will always refer to the version of the code that is on stable (or whatever) at that moment. The reason I want to do this is because the extensions possee is checking our docs into source control, so that they can be viewed live from viewvc. They're still in progress, but you can see them starting to come together here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/index.html The cool thing about this approach is that when we branch releases, the docs from trunk will be branched too. So the docs for a certain release area always with the code for that release. If we had the aforementioned tags, the canonical URL for, eg, the stable extension docs could just be: http://src.chromium.org/viewvc/chrome/branches/stable/src/chrome/common/extensions/docs/index.html - 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] Subversion tags for stable/beta/dev?
Hi all, I was wondering if the release managers could add a tag in Subversion for each of the stable, beta, and dev release channels. I want a ViewVC URL that I can give people that will always refer to the version of the code that is on stable (or whatever) at that moment. The reason I want to do this is because the extensions possee is checking our docs into source control, so that they can be viewed live from viewvc. They're still in progress, but you can see them starting to come together here: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/index.html The cool thing about this approach is that when we branch releases, the docs from trunk will be branched too. So the docs for a certain release area always with the code for that release. If we had the aforementioned tags, the canonical URL for, eg, the stable extension docs could just be: http://src.chromium.org/viewvc/chrome/branches/stable/src/chrome/common/extensions/docs/index.html - 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: Dev Chrome crashes on subsequent starts after installing a theme
You can find the location of your profile directory on this page: http://dev.chromium.org/user-experience/user-data-directory - a On Thu, Aug 6, 2009 at 2:16 PM, Evan Stadeest...@chromium.org wrote: oh sorry. Not using linux. rm -rf means to delete. So go find your profile directory and delete the Extensions/ folder in there. -- Evan Stade On Thu, Aug 6, 2009 at 2:15 PM, Evan Stadeest...@chromium.org wrote: Open your favorite terminal program and type rm -rf ~/.config/google-chrome/Default/Extensions/ at the prompt -- Evan Stade On Thu, Aug 6, 2009 at 2:13 PM, Gobbledegookaftabkha...@gmail.com wrote: Thanks for the replies guys. What exactly does this mean: The fix is to rm -rf your Extensions directory out of your profile directory. ??? On Aug 6, 10:06 pm, Dan Kegel d...@kegel.com wrote: Evan wrote about this earlier: A few people have found their trunk builds crashing on startup. This comes from a bug in theme loading and can bite you if you installed some of the in-development themes. The fix is to rm -rf your Extensions directory out of your profile directory. The next release will have the bug fixed, and at that point these themes will no longer cause crashes. Does that help? On Thu, Aug 6, 2009 at 6:04 AM, Gobbledegookaftabkha...@gmail.com wrote: Hi, I've been unable to get into chrome dev (latest) ever since I installed the Baseball theme. Everything worked fine till my computer crashed (unrelated to chrome / a USB - windows sleep mode driver incompatibility) It just gives the Whoa! Google has crashed error. I uninstalled and tried reinstalling but it still refuses to work. I didn't want to lose my history so I didn't try doing a completely clean reinstall. However, I'm now on the beta channel and it's working fine. Toshiba A300D-15B dual core 2.1GHz AMD laptop 4 GB RAM Windows 7 RTM (build 7600) 64 bit Steps to recreate scenario: 1. Install Google Chrome Dev channel version. 2. Open 5 tabs. 3. Install the baseball theme and keep Chrome running. 4. Put Windows into Sleep mode. 5. Wake up windows. 6. Do a hard restart (do not safely restart the computer but use the power button if you're on a laptop or reset button if ure on a desktop) 7. Run Windows normally. 8. Try to start Google Chrome. It should crash. --~--~-~--~~~---~--~~ 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-extensions] Re: Extension API Proposal: Performance Tracing
[moving to chromium-dev, as it seems better for this discussion] Kelly, Sorry for not replying earlier. I'm a little bit underwater right now, as we're trying to get everything with extensions tied up so we can turn it on by default on dev. I'd like to take a step back and ponder why even do this as an extension. I assume your end goal must be to build this feature into Chrome's dev tools, right? If so, I think it would be better to start out building the code into Chrome, not on top of the extension system. There is a significant cost to adding APIs to the extension system. They must be general, relatively safe, and we must maintain them, forever. In this case, I don't see a huge demand for these kind of APIs. Even in Firefox, which has infinite flexibility, we only see a few of these type of extensions. In contrast, when something is part of Chrome directly, there is a lot more power and flexibility available. - a On Wed, Aug 5, 2009 at 9:28 AM, Kelly Nortonknor...@google.com wrote: If you're interested in what the mechanics of this would look like, an initial patch for this is posted here: http://codereview.chromium.org/159882 /kelly On Tue, Aug 4, 2009 at 2:39 PM, Kelly Norton knor...@google.com wrote: I've added a document to the chromium wiki that describes an extensions API to support a performance tool, which is being called APU for now. For those who haven't seen the tool, there is a very brief demo in this video: http://www.youtube.com/watch?v=S5aJAaGZIvk#t=21m15s. The API is essentially a firehose of timing data that can be enabled on a per-tab basis. We're hoping this API is a good starting point for DevTools-related APIs in that it has a narrowly focused initial use case and very little API surface area. I'm interested in getting your feedback. http://code.google.com/p/chromium/wiki/ExtensionsPerfTraceAPI Thanks, /kelly -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ 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: Call for highlights to the 196.0 release notes
Extension changes: * Introduce moles! These are a new extra area that can pop up above toolstrips. 21621 * Theme install experience is now complete: 21626 * Themes now work with --load-extension (good for development): 21619 * You can now reload extensions from a button on chrome://extensions. Useful for debugging. 21719 * Fix bug where bookmarks.getTree() doesn't return any bookmarks: 21503 * Minimum auto-update frequency from command line is now 30 seconds. Useful for debugging. 21849 * (Re-)enable content scripts executing in isolated worlds: 21878 On Thu, Jul 30, 2009 at 10:48 AM, Nico Webertha...@chromium.org wrote: Mac changes: * Trackpad scrolling on maps works again * First stab at history menu * Download shelf now has real download items * Lots of polish bugs (gradient between tabs and toolbar looks smooth again, double-clicking tabstrip to minimize works, app icon is slightly smaller, completion popups behave correctly on page scroll, scrollbars now get inactive look when chrome is not the active app, space bar can now open popup boxes, fixed tab title text truncation, location bar looks nice again for https pages) -- the stuff in parens should probably be omitted though :-) On Thu, Jul 30, 2009 at 10:15 AM, Anthony LaForgelafo...@google.com wrote: I'm in the process of building the release notes/ blog post for the 196.0 release. I figured I'd try something a little different this week and turn over the process of picking high to the shiny folks on chromium-dev. I've attached a filtered list of changes that were made to the 196.0 release since 195.1 (between revisions 21177 and 21983). Please let me know if there are any particulars that you'd like to see bubble up. Thanks in advance for your help! Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA External Phone: 1-650-214-4055 --~--~-~--~~~---~--~~ 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: Quota UI for LocalStorage (and others in the future)
On Wed, Jul 29, 2009 at 11:28 AM, Drew Wilsonatwil...@chromium.org wrote: I've been starting to lean in this direction as well. The problem is that extensions are currently not cross-platform and would require separate implementations for each platform. Just to clarify, you really mean cross-browser, right? Chrome and Firefox extensions are both cross-platform (in the OS sense). And in many cases the extension delivery mechanism is under the control of an arbitrary third party (i.e. Google, Mozilla, Apple, etc) who has control over which extensions can be hosted, which is not particularly open-web-by. That isn't true. In the case of both Chrome and Firefox, extensions can be installed from anywhere on the web, though it is true that there are additional UI roadblocks for the case of installing from an untrusted source. - 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: [extensions] Shankland: Thanks for giving my back pixels, browser makers
Yes, but for v1 we will just have one home for them. We are trying to decide between the bookmark bar and the bottom bar now. They both have their plusses and minuses: - The bookmark bar is better for people who already use the bookmark bar, particularly if it isn't already full. - The bottom bar is a lot simpler to implement and better for people who don't use the bookmark bar, or people who would have many toolstrips. On Tue, Jul 28, 2009 at 10:11 AM, Evan Martine...@chromium.org wrote: Did we not plan to allow them even one bar higher? I had thought that was the resolution for the fellow who wanted to add a bookmarks button next to the page and tools menus. On Tue, Jul 28, 2009 at 10:05 AM, Aaron Boodmana...@chromium.org wrote: One person who, like me, would probably prefer toolstrips on the bookmark bar: http://news.cnet.com/8301-17939_109-10296433-2.html - 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: [chromium-extensions] Inter-extension communication API proposal
+chromium-dev
I think this is great. I suggest creating a wiki page with a design
for this so that we can refer to it whenever we implement, and a bug
that refers to the wiki page.
Up until now, we've been putting our designs here:
http://dev.chromium.org/developers/design-documents/extensions (see
proposed api), but that page isn't editable without a @chromium.org
account.
I've been thinking we should move that content to the wiki so that it
is editable by all. So if you want, you could be the first.
Besides that, a few minor comments:
1. I think we should add a permission for inter-extension
communication once we have a permissions mechanism. That is, an
extension should have to declare in the manifest which extensions it
would like to contact. This is just a security precaution against the
extension accidentally leaking privileges if it gets XSS'd or
something.
On Tue, Jul 28, 2009 at 10:58 AM, James Robinsonjam...@google.com wrote:
I think that extensions should be able to communicate with each other
using message passing. Currently, it's possible to do something like
this:
var ext = new chrome.Extension('abcdefgh...');
var port = ext.connect('channel from another world!');
port.postMessage({message: im in ur channel});
However, there are a few problems with this approach. First, it's
probably a bug that it works. The more serious issue is that a
onConnect event is fired at extension 'abcdefgh...' and there is no
way for that extension to know that the port is not from a content
script within the same extension but from another extension. An
extension should be able to allow other extensions to open connections
to it, be explicitly aware of where the connection is coming from, and
then communicate with it using the existing chrome.extension.Port
system.
This would require two new APIs on the chrome.extension object, based
on the ones presented in
http://dev.chromium.org/developers/design-documents/extensions/content-scripts:
// Open a channel to another extension with the provided ID.
// If no extension with the provided ID exists, nothing happens.
// Otherwise the chrome.extension.onConnectExternal event is fired
// to all components of the extension with the provided ID each time
// the method is called.
// The channel can optionally be named. This name will be sent along
with the
// onConnectExternal event
Port connectExternal(String ID, [String channelName])
2. I think we can merge connect() and connectExternal() by adding an
optional param to connect() that specifies the target extension. If
omitted it defaults to the current extension.
// Fired when another extension opens a channel to this extension via
// chrome.extension.connectExternal().
// If a channelName was provided, it is accessible via port.name.
Event onConnectExternal(Object port)
In order for an extension to know what the other side of a connection
is I'd also propose adding the following property to the
chrome.extension.Port class:
// ID of the extension at the other side of this port.
String senderID;
An extension could check this field in the onConnectExternal handler
and compare it to a whitelist/blacklist to decide whether to attach
onMessage handlers. An extension might also want to expose some UI to
the user listing all connected extensions.
The other issue to address is startup order. The order in which the
scripts within different background pages is not defined, which is
entirely reasonable, but it means that doing the obvious thing:
script
var port = chrome.extension.connectExternal('abcdef..');
/script
would work unreliably depending on the exact order in which the
background pages get loaded, the event handlers get registered, and
the events are fired. To resolve this I think that all connectExternal
() events be queued until each extension's background page has loaded,
so that any handler registration code in top-level scripts has a
chance to run.
This seems reasonable. It might be possible to be even cleverer if we
know who wants to connect to who by way of what they declare in their
manifests.
- 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: [chromium-extensions] Inter-extension communication API proposal
On Tue, Jul 28, 2009 at 11:30 AM, Drew Wilsonatwil...@chromium.org wrote: SGTM. Note that we're essentially duplicating (assumedly intentionally so) the window.postMessage() APIs which require specifying a target domain and whose connect event has a source and origin attribute specifying the window that sent the message. Yeah, intentionally so. It seemed OK in this instance to not try and couple ourselves directly to postMessage() since the shape of extensions and web pages are slightly different. In the future, if it gets easier to use IDL (I hear other teams on Chromium are working on this), we might adopt something closer to postMessage(). It's an excellent point about connectExternal and startup ordering - in fact, one of the problems with window.postMessage now is that there's no guarantee that your message will be delivered if the target window has not loaded yet. I brought this up in the original design discussions, that messages should be queued until the page either loads or fails. Web platform APIs should be deterministic! Blech. In extensions, we queue the messages :). - 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: [chromium-extensions] Inter-extension communication API proposal
On Tue, Jul 28, 2009 at 12:09 PM, James Robinsonjam...@google.com wrote: Thanks for the feedback. I've created http://code.google.com/p/chromium/wiki/InterExtensionCommunication with the proposal and would appreciate if someone with an @chromium account could link to it Done. I also created a bug: http://code.google.com/p/chromium/issues/detail?id=17910 This sounds like it should be possible, but since connect() takes an optional param 'name' of type string already and the ID will also be of type string it seems like this would be ambiguous. Yeah, I don't feel too strongly about it. I was bringing it up more as a possibility. I presume that whenever someone implements this they will pick the best of the several ways to phrase this. We'll always know what extension the onConnectExternal event will be fired at when the connectExternal() call is made, so at the very least we could promise that no onConnectExternal event will be fired at an extension until its background page, if there is one, has fully loaded. Queuing until all extensions' background pages load is a simpler way to guarantee the same thing. Using the manifests could be a way to have a clever implementation, but in general the best you can get out of manifests is a partial order of extensions and you might get cycles. True. I guess I am worried about blocking an extension from communicating with, eg, itself, until all other extensions have loaded their background pages. This doesn't seem fair. - 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: [chromium-extensions] Inter-extension communication API proposal
On Tue, Jul 28, 2009 at 12:20 PM, Aaron Boodmana...@chromium.org wrote: We'll always know what extension the onConnectExternal event will be fired at when the connectExternal() call is made, so at the very least we could promise that no onConnectExternal event will be fired at an extension until its background page, if there is one, has fully loaded. Queuing until all extensions' background pages load is a simpler way to guarantee the same thing. Using the manifests could be a way to have a clever implementation, but in general the best you can get out of manifests is a partial order of extensions and you might get cycles. True. I guess I am worried about blocking an extension from communicating with, eg, itself, until all other extensions have loaded their background pages. This doesn't seem fair. I like your other proposal best, of just queuing onConnect events fired at an extension until its background page has loaded. We should do this for extensions talking to themselves, too. - 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: Chromium Embedded build bot on FYI waterfall
As a bystander, I just want to note how cool it is that we set this up for Marshall. Sometimes the infrastructure we wield on this project completely blows my mind. - a On Fri, Jul 24, 2009 at 1:11 PM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, A new build bot has been added to the Chromium FYI waterfall (many thanks to Nicolas and Darin for making this happen!) that tracks the build status of the Chromium Embedded Framework (CEF) project. http://build.chromium.org/buildbot/waterfall.fyi/waterfall?branch=builder=Chromium+Embedded CEF provides a framework for embedding the Chromium browser in Windows applications and is a heavy consumer of the Chromium WebKit API layer. Because CEF uses the Chromium WebKit API layer a bit differently than the standard Chromium browser it can be very easy for Chromium changes to break us accidentally. The CEF community would be very thankful if Chromium developers could keep us in mind when making changes to related areas of the code base so that accidental breakages of CEF can be avoided :-). For more information on CEF please visit our project page at http://code.google.com/p/chromiumembedded Regards, Marshall --~--~-~--~~~---~--~~ 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: Proposal for adding ChangeLog files to Chromium
The point about reverts is confusing RELEASE_NOTE is a good one, but I don't think it outweighs the pain of maintaining ChangeLog. On Wed, Jul 22, 2009 at 8:41 AM, Erik Kayerik...@chromium.org wrote: You can still have a single file/URL with this info for convenience. Just auto-generate it from the svn-logs. You lose the ability to edit it and make it look nice, but that could be done manually as a separate file if you'd like. Erik On Tue, Jul 21, 2009 at 11:08 PM, Anthony LaForge lafo...@google.com wrote: The main advantage that I could see for a file would be that I could point people to a single file (at any given revision) which could tell then the exact state of feature work and history. It seems to me that the RELEASE_NOTE tag would be more cumbersome. Kind Regards, Anthony Laforge Technical Program Manager Mountain View, CA On Tue, Jul 21, 2009 at 10:27 PM, Evan Martin e...@chromium.org wrote: On Tue, Jul 21, 2009 at 10:22 PM, Adam Langleya...@chromium.org wrote: On Tue, Jul 21, 2009 at 9:37 PM, Anthony LaForgelafo...@google.com wrote: In order to make it easier for the community to see the changes are going on inside Chromium I'd like to propose that we add one or more ChangeLog files into our code base. The proposed usage would go something like this: I'm not saying anything that Jeremy and Adam haven't already said, just reinforcing their point in case there's any question. What you want is `git log | grep RELEASE_NOTE` git log --grep=RELEASE_NOTE will show the full log entries that match that text. PS: I've gotta be 100% on responding to threads that mention git, huh. --~--~-~--~~~---~--~~ 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: No more buildbot auto-refresh - Update your bookmark!
Nicolas, Are you going to be turning back on the extension support at any point? If not, just let us know so that we can remove the feature from the sample. Right now it looks broken. - a On Tue, Jul 21, 2009 at 8:27 AM, Nicolas Sylvainnsylv...@chromium.org wrote: Hi, Last week a lot of people on this list said that they like the idea of disabling the auto-reload for our buildbot waterfall and console view. This is now implemented. If you do want to keep the page auto-refreshing, please update your bookmark. just add the query parameter reload=X, where X is the number of second to wait between each reloads. X used to be 90. Depending on your needs, you can increase or decrease this number. Examples: console view: http://build.chromium.org/buildbot/waterfall/console?reload=180 waterfall : http://build.chromium.org/buildbot/waterfall/waterfall?reload=180 For sheriffs: http://build.chromium.org/buildbot/waterfall/waterfall?failures=1reload=30 Thanks Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Proposal for new changelist annotation: RELEASE_NOTE=....
I propose we add a new tag to changelist descriptions: RELEASE_NOTE=description of something interesting that users would like to know happened in this build It would be up to the developer to decide whether something was worth going in the release notes. In the extension world, the reason I specifically want this is I want to keep people testing the system up to date with changes. I have been trying to do this with a mail I send to chromium-extensions@ with each new release, but it is hard to stay in sync with build schedule. Thoughts? - 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: Proposal for new changelist annotation: RELEASE_NOTE=....
On Fri, Jul 17, 2009 at 11:07 AM, Aaron Boodmana...@chromium.org wrote: Sorry, my idea was that the release manager would use these notes to create the actual release notes (with some editorializing along the way), and then I wouldn't have to do my side email. - a On Fri, Jul 17, 2009 at 11:05 AM, Evan Martine...@chromium.org wrote: I say go for it. Even if you're the only one who uses it it'll help you. :) On Fri, Jul 17, 2009 at 5:48 PM, Aaron Boodmana...@chromium.org wrote: I propose we add a new tag to changelist descriptions: RELEASE_NOTE=description of something interesting that users would like to know happened in this build It would be up to the developer to decide whether something was worth going in the release notes. In the extension world, the reason I specifically want this is I want to keep people testing the system up to date with changes. I have been trying to do this with a mail I send to chromium-extensions@ with each new release, but it is hard to stay in sync with build schedule. Thoughts? - 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: Proposal for new changelist annotation: RELEASE_NOTE=....
On Fri, Jul 17, 2009 at 11:16 AM, Mark Larson (Google)m...@chromium.org wrote: I've been thinking of something along the same lines. I was also considering a ReleaseNotes file, like a ChangeLog but only to announce noteworthy changes. The advantages are that it can be edited post-commit and that your notes get reverted if your change gets reverted. In any case, if you want to pioneer 'add an optional RELEASE_NOTES line to your log description', I'm all for it. Ok, I will start using it. - 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: Proposal for new changelist annotation: RELEASE_NOTE=....
On Fri, Jul 17, 2009 at 11:00 AM, Jeremy Orlowjor...@chromium.org wrote: Would this be optional? I ask because the TEST one seems to have junk in it half the time. I think it'd be valuable, but most patches won't need it. It would definitely be optional, and it developers would be encouraged to only add it when they think something is useful to go in the release notes. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
