[chromium-dev] Re: Request for comments: Feed preview work
Regardless of whose authority they run at, it is somewhat desirable to have the feed URL display in the address bar, since that's the content that's being loaded. I would like to keep the flow in page as much as possible. We should be able to come up with some solution here that doesn't involve elevation. -Ben On Wed, May 6, 2009 at 10:51 PM, Adam Barth aba...@chromium.org wrote: I don't think we want these feed previews to run with foo.com's authority. I'd rather they ran with no one's authority. Adam On Wed, May 6, 2009 at 8:42 PM, Darin Fisher da...@chromium.org wrote: WebKit does not support nested schemes. It would fail in so many places to recognize that the authority of such an URL is actually foo.com. (However, we could perhaps support this as we do view-source, where WebKit never actually sees the view-source URL.) -Darin On Wed, May 6, 2009 at 6:56 PM, Adam Barth aba...@chromium.org wrote: I think Darin had some strong opinions about whether we should do nested schemes like feed-view:http://foo.com/bar. From a security point of view, we'd ideally like to render feeds with JavaScript and plug-ins disabled, as well as in a noAccess SecurityOrigin. This is easier if the feed preview lives in its own scheme. I'm happy to help out with the security bits once you have the basics up and running. Adam On Wed, May 6, 2009 at 6:26 PM, Ben Goodger (Google) b...@chromium.org wrote: On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. Firefox retains the URL of the feed in the address bar (including scheme), which is nice, though it falls back to an internal URL under the hood to do the render of the preview. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
Let's say the feed is http://foo.com/feed.xml What about a setup where the content rendered in the tab area is running on chrome://, but contains a frame that hosts the actual feed running on http://foo.com? The subscribe UI runs on the other page, so it is the only thing that needs elevated privileges. Initially, the two frames would run in the same process, but they'd still be separated by same-origin. Someday, we could even separate them by process as we have no need to ever communicate between these frames via JS. Adam, what is the concern with having the feed run in the context of the hosting site? That they might XSS themselves? - a On Wed, May 6, 2009 at 11:22 PM, Ben Goodger (Google) b...@chromium.org wrote: Regardless of whose authority they run at, it is somewhat desirable to have the feed URL display in the address bar, since that's the content that's being loaded. I would like to keep the flow in page as much as possible. We should be able to come up with some solution here that doesn't involve elevation. -Ben On Wed, May 6, 2009 at 10:51 PM, Adam Barth aba...@chromium.org wrote: I don't think we want these feed previews to run with foo.com's authority. I'd rather they ran with no one's authority. Adam On Wed, May 6, 2009 at 8:42 PM, Darin Fisher da...@chromium.org wrote: WebKit does not support nested schemes. It would fail in so many places to recognize that the authority of such an URL is actually foo.com. (However, we could perhaps support this as we do view-source, where WebKit never actually sees the view-source URL.) -Darin On Wed, May 6, 2009 at 6:56 PM, Adam Barth aba...@chromium.org wrote: I think Darin had some strong opinions about whether we should do nested schemes like feed-view:http://foo.com/bar. From a security point of view, we'd ideally like to render feeds with JavaScript and plug-ins disabled, as well as in a noAccess SecurityOrigin. This is easier if the feed preview lives in its own scheme. I'm happy to help out with the security bits once you have the basics up and running. Adam On Wed, May 6, 2009 at 6:26 PM, Ben Goodger (Google) b...@chromium.org wrote: On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. Firefox retains the URL of the feed in the address bar (including scheme), which is nice, though it falls back to an internal URL under the hood to do the render of the preview. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] FYI: DEFER no longer means anything
I just committed a change that removes defer from text_expectations.txt. That means that the number of failing tests the bot reports is the total number of webkit tests that we'll ever want to fix (e.g. win-release went from 141 fixable to 768 fixable). In order to know which of those tests need to be fixed for the next release (the formerly undeferred tests), you have to look at the P1/P0 bugs for layout tests at bugs.chromium.org. Ojan --~--~-~--~~~---~--~~ 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: Tab-modal dialogs on the Mac
That's cleaner than I expected, and the behavior looks right. Nice job! I vote for continuing with this approach. --Amanda On Thu, May 7, 2009 at 12:17 AM, Avi Drissman a...@google.com wrote: OK, so attached is my proof of concept. The code is pretty clear, though if you have questions, please let me know. +maf: Your offhand comment about tabs being subwindows led me to this implementation; thanks! +dmac: What do you think? I'll send the DTS incident back to you tomorrow. Avi On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
Minor comment, but I assume you will be triggering the feed-preview when people click on a link to the feed as well. Many sites have an RSS link to the feed's XML file because it is previewable in many browsers without autodiscovery. Currently, Chrome shows unformated XML. Doing CTRL-U after shows the formatted XML source which is at least better than its unformatted version. - Itai On May 6, 8:36 pm, Finnur Thorarinsson fin...@chromium.org wrote: I just wanted to give you heads up that soon it will be time for me to devote most of my time on the second part of the Feed handling support in Chrome, namely: Feed Previews (http://dev.chromium.org/user-experience/feed-subscriptions). Consider this a request for your feedback, especially if you know about the status of the previous feed preview work or have opinions on the general direction/approach we should take. I have already added an API for PageActions and have a working RSS PageAction extension, which does feed auto-detection on the page. Now it is time to look into Feed previews. I have spoken briefly to AdamB and EvanM about feed previews and both suggested modelling this after the view-source implementation. It was also suggested to add a scheme for this (like we do with view-source), such as view-feed: or feed: I know there has been some work on this front before, although the status of that is not clear to me -- except that it was disabled at some point (or removed from the codebase?). I would love to see what was done back then, if anyone knows more. A cursory look through the code indicated that mime type sniffing for feed is done. I've heard there is also some remaining work required for sanitizing the feeds before showing, but besides the above there is not much more I know at this point in time. Comments welcome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
I dig it! NICE! It's similar to the overlay window trick we use for tab dragging between windows. Maybe for consistency you should call the hanger window the overlay window? Is there any way we can keep this generic and put it into GTM? On Thu, May 7, 2009 at 8:46 AM, Amanda Walker ama...@chromium.org wrote: That's cleaner than I expected, and the behavior looks right. Nice job! I vote for continuing with this approach. --Amanda On Thu, May 7, 2009 at 12:17 AM, Avi Drissman a...@google.com wrote: OK, so attached is my proof of concept. The code is pretty clear, though if you have questions, please let me know. +maf: Your offhand comment about tabs being subwindows led me to this implementation; thanks! +dmac: What do you think? I'll send the DTS incident back to you tomorrow. Avi On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi -- Mike Pinkerton Mac Weenie pinker...@google.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: Request for comments: Feed preview work
chrome:// pages cannot load HTTP-based sub-resources. We don't want to taint the processes that render Chrome UI. -Darin On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman a...@chromium.org wrote: Let's say the feed is http://foo.com/feed.xml What about a setup where the content rendered in the tab area is running on chrome://, but contains a frame that hosts the actual feed running on http://foo.com? The subscribe UI runs on the other page, so it is the only thing that needs elevated privileges. Initially, the two frames would run in the same process, but they'd still be separated by same-origin. Someday, we could even separate them by process as we have no need to ever communicate between these frames via JS. Adam, what is the concern with having the feed run in the context of the hosting site? That they might XSS themselves? - a On Wed, May 6, 2009 at 11:22 PM, Ben Goodger (Google) b...@chromium.org wrote: Regardless of whose authority they run at, it is somewhat desirable to have the feed URL display in the address bar, since that's the content that's being loaded. I would like to keep the flow in page as much as possible. We should be able to come up with some solution here that doesn't involve elevation. -Ben On Wed, May 6, 2009 at 10:51 PM, Adam Barth aba...@chromium.org wrote: I don't think we want these feed previews to run with foo.com's authority. I'd rather they ran with no one's authority. Adam On Wed, May 6, 2009 at 8:42 PM, Darin Fisher da...@chromium.org wrote: WebKit does not support nested schemes. It would fail in so many places to recognize that the authority of such an URL is actually foo.com. (However, we could perhaps support this as we do view-source, where WebKit never actually sees the view-source URL.) -Darin On Wed, May 6, 2009 at 6:56 PM, Adam Barth aba...@chromium.org wrote: I think Darin had some strong opinions about whether we should do nested schemes like feed-view:http://foo.com/bar. From a security point of view, we'd ideally like to render feeds with JavaScript and plug-ins disabled, as well as in a noAccess SecurityOrigin. This is easier if the feed preview lives in its own scheme. I'm happy to help out with the security bits once you have the basics up and running. Adam On Wed, May 6, 2009 at 6:26 PM, Ben Goodger (Google) b...@chromium.org wrote: On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. Firefox retains the URL of the feed in the address bar (including scheme), which is nice, though it falls back to an internal URL under the hood to do the render of the preview. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Request for comments: Feed preview work
I see. That probably simplifies things. Hmm... -Darin On Wed, May 6, 2009 at 10:51 PM, Adam Barth aba...@chromium.org wrote: I don't think we want these feed previews to run with foo.com's authority. I'd rather they ran with no one's authority. Adam On Wed, May 6, 2009 at 8:42 PM, Darin Fisher da...@chromium.org wrote: WebKit does not support nested schemes. It would fail in so many places to recognize that the authority of such an URL is actually foo.com. (However, we could perhaps support this as we do view-source, where WebKit never actually sees the view-source URL.) -Darin On Wed, May 6, 2009 at 6:56 PM, Adam Barth aba...@chromium.org wrote: I think Darin had some strong opinions about whether we should do nested schemes like feed-view:http://foo.com/bar. From a security point of view, we'd ideally like to render feeds with JavaScript and plug-ins disabled, as well as in a noAccess SecurityOrigin. This is easier if the feed preview lives in its own scheme. I'm happy to help out with the security bits once you have the basics up and running. Adam On Wed, May 6, 2009 at 6:26 PM, Ben Goodger (Google) b...@chromium.org wrote: On Wed, May 6, 2009 at 6:13 PM, Evan Martin e...@chromium.org wrote: - Some existing practice on the web is to use feed://hostname/etc.xml, which drops the protocol (and should be interpreted as HTTP). Ideally you should redirect these into view-feed:http://hostname/etc.xml so our view-feed works with https, ftp, etc. URLs. Firefox retains the URL of the feed in the address bar (including scheme), which is nice, though it falls back to an internal URL under the hood to do the render of the preview. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: depot_tools is moving!
I fail to update I get the following message: E:\depot_toolsgclient help Installing subversion ... [-] ADODB.Stream 800a01ad: Cannot save file (Automation server can't create object) ... Failed to checkout svn automatically. Please visit http://subversion.tigris.org to download the latest subversion client before continuing. You can also get the prebacked version used at http://src.chromium.org/svn/trunk/tools/third_party/ On May 2, 4:34 am, Marc-Antoine Ruel mar...@chromium.org wrote: gcl, gclient and friends are moving fromhttp://src.chromium.org/svn/trunk/depot_tools/tohttp://src.chromium.org/svn/trunk/tools/depot_tools/ To help you with the switch, there is now a little script to switch automatically. Just run ** *convert_depot_tools* to convert the depot_tools to the new checkout. Warning: the output of this tool isn't nice. If anything fails, just checkout manually: *svn co **http://src.chromium.org/svn/**trunk/tools/depot_tools*http://src.chromium.org/svn/trunk/tools/depot_tools The end result is the same. The far biggest advantage is that there is only one place for all the scripts (no more platform specific) and you can now send patches directly from your depot_tools; e.g. no need to do a separate checkout and run scons anymore. The old depot_tools is scheduled to be removed on May 12, 2009 and you will be upgraded *automatically* next time you run gclient after that date. Windows-only side-effects: - It won't install svn client nor python if they are found in %PATH%. - If you used svn lately, the old depot_tools version was upgraded to 1.6. If you have svn 1.5 in your %PATH%, you may have trouble working with your checkout. Just removing your old client from the path and run gclient help again. 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: Request for comments: Feed preview work
On Thu, May 7, 2009 at 12:03 AM, Adam Barth aba...@chromium.org wrote: On Wed, May 6, 2009 at 11:55 PM, Aaron Boodman a...@chromium.org wrote: What about a setup where the content rendered in the tab area is running on chrome://, but contains a frame that hosts the actual feed running on http://foo.com? Sure, we could do that. Or even better is if the outer page is a chrome-extension. Presumably we'll have a subscribe to feed API for extensions? On Thu, May 7, 2009 at 7:57 AM, Darin Fisher da...@chromium.org wrote: chrome:// pages cannot load HTTP-based sub-resources. We don't want to taint the processes that render Chrome UI. Yeah, I actually meant chrome-extension:// for the outer page. But I don't know what to do about wanting the inner frame to have no authority. Hm. - 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: Tab-modal dialogs on the Mac
1. Naming's arbitrary. The name hanger window comes from an earlier design idea where the clear window was sized only 10 px high, and was the hanger upon which the sheet hung. Once I got the idea that I could also use it to block input to the underlying view, I guess it outgrew the name. (shrug) 2. It was made separable just so I could easily move it from the POC to Chromium, but I'm open to GTMing it. Dave, are there any features you'd like to see? Avi On Thu, May 7, 2009 at 7:49 AM, Mike Pinkerton pinker...@chromium.orgwrote: I dig it! NICE! It's similar to the overlay window trick we use for tab dragging between windows. Maybe for consistency you should call the hanger window the overlay window? Is there any way we can keep this generic and put it into GTM? On Thu, May 7, 2009 at 8:46 AM, Amanda Walker ama...@chromium.org wrote: That's cleaner than I expected, and the behavior looks right. Nice job! I vote for continuing with this approach. --Amanda On Thu, May 7, 2009 at 12:17 AM, Avi Drissman a...@google.com wrote: OK, so attached is my proof of concept. The code is pretty clear, though if you have questions, please let me know. +maf: Your offhand comment about tabs being subwindows led me to this implementation; thanks! +dmac: What do you think? I'll send the DTS incident back to you tomorrow. Avi On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi -- Mike Pinkerton Mac Weenie pinker...@google.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: depot_tools is moving!
Please visit http://subversion.tigris.org to download the latest subversion client before continuing. You can also get the prebacked version used at http://src.chromium.org/svn/trunk/tools/third_party/ The thing that is missing now is to stop the message from happening you need to create depot_tools\svn.bat. Feel free to make it call anything. The default one is in depot_tools\bootstrap\win\svn.new.bat. Just copy it over to depot_tools\svn.bat. I'll try to make more resilient in the coming days. M-A On Thu, May 7, 2009 at 7:58 AM, avcoder ffm...@gmail.com wrote: I fail to update I get the following message: E:\depot_toolsgclient help Installing subversion ... [-] ADODB.Stream 800a01ad: Cannot save file (Automation server can't create object) ... Failed to checkout svn automatically. Please visit http://subversion.tigris.org to download the latest subversion client before continuing. You can also get the prebacked version used at http://src.chromium.org/svn/trunk/tools/third_party/ On May 2, 4:34 am, Marc-Antoine Ruel mar...@chromium.org wrote: gcl, gclient and friends are moving fromhttp://src.chromium.org/svn/trunk/depot_tools/tohttp://src.chromium.org/svn/trunk/tools/depot_tools/ To help you with the switch, there is now a little script to switch automatically. Just run ** *convert_depot_tools* to convert the depot_tools to the new checkout. Warning: the output of this tool isn't nice. If anything fails, just checkout manually: *svn co **http://src.chromium.org/svn/**trunk/tools/depot_tools*http://src.chromium.org/svn/trunk/tools/depot_tools The end result is the same. The far biggest advantage is that there is only one place for all the scripts (no more platform specific) and you can now send patches directly from your depot_tools; e.g. no need to do a separate checkout and run scons anymore. The old depot_tools is scheduled to be removed on May 12, 2009 and you will be upgraded *automatically* next time you run gclient after that date. Windows-only side-effects: - It won't install svn client nor python if they are found in %PATH%. - If you used svn lately, the old depot_tools version was upgraded to 1.6. If you have svn 1.5 in your %PATH%, you may have trouble working with your checkout. Just removing your old client from the path and run gclient help again. 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] Try out --enable-omnibox2!
Please try out the --enable-omnibox2 command line switch in Chrome and file bugs against me in the issue tracker. I'd like to get a better sense of what needs to be done with it so we can turn it on by default. The differences thus far are aesthetic, and in the popup. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: webkit gyp conversion, another (likely) attempt tonight
Heads up: I'm gearing up to close the tree tonight for another attempt at converting the webkit build to gyp, closure starting some time between 20:00 and 22:00 PDT. If this would be a serious imposition, let me know. I'm still working on a few last issues. If I run into another serious roadblock, there's a chance I'll wave off tonight. I'll send out another announcement with final word on whether or not I'm going ahead, and at what specific time, by COB today (~17:00 PDT). In addition to fixing the layout test failures from last attempt, this recent work has been trying to make sure all the dependency and source lists (esp. including resources) are functionally equivalent, by isolating and explaining any size discrepancies between VS-built and gyp-built .lib, .dll and .exe files. The most prominent change in the internal build architecture is that the V* binding are longer built as as separate .lib (i.e., there's no separate V8Bindings target), but are now part of webcore.lib. I've been specifically verifying the following functionality: - Debug builds from scratch - Debug null rebuild (everything up to date) - Release builds from scratch - Release null rebuild (everything up to date) - Tests that will be run by the buildbots all pass (or at least exhibit the same failures as the vanilla VS build) I specifically know that I haven't done anything to verify the following: - Purify builds (erikkay, if there's something simple you or I can do to sanity-check this ahead of time, let me know) If you have some other piece of crucial functionality that really *must* be verified as functioning correctly before we cut this over officially, please let me know. We simply don't have a good central, list of every functional piece that every script or other piece of infrastructure expects our build to do (let alone what developer workflows expect...). Barring some really disastrous problem, I'm planning to leave what we have in place and recruit people to help hunt down and fix additional discrepancies between the new and old builds (and will announce anything known to be not working). The rate of change in the code base (especially in the webkit.gyp and chrome.gyp files) means we simply have to get out of trying to play a constant game of catch-up with this change. Thanks, --SK --~--~-~--~~~---~--~~ 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: Getting LOG(INFO) to print
I'm having the opposite problem. I did a release build on Linux, and I get tons of INFO spew. --log-level=N for N 0 doesn't turn it off. On Wed, Apr 22, 2009 at 11:37 AM, Evan Martin e...@chromium.org wrote: Since Pinkerton just lost some hours to this and I did again: The secret to getting LOG(INFO) to show is to pass --log-level=0 when you run. I added this to http://code.google.com/p/chromium/wiki/LinuxDebugging (which, by the way, has had a lot of content added since you last looked). --~--~-~--~~~---~--~~ 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: Regarding using bookmark to save user info...
Thanks for your tips PhistucK. I am using dev version (2.0.177.1). You are right the object name is chromium, and it works for the extension domain (chrome-extension://[id]/*). Also in web main (http://*) I can get chromium.extension.id_, but not chromium.bookmarks. Also although chromium.extension.connect is available, it always reports error (no such extension). Does that mean I need to go even beyond the dev version and build from the latest code base in order to try out these features? -Jack On May 7, 1:53 am, PhistucK phist...@gmail.com wrote: In what version?Beta, Dev or Chromium? Beta and Dev uses the chromium object, revision 15310http://src.chromium.org/viewvc/chrome?view=revrevision=15310 changed the name of the object to chrome. (So, chromium.tabs got changed to chrome.tabs) Maybe it helps. ☆PhistucK On Thu, May 7, 2009 at 10:47, jack js2...@gmail.com wrote: I just tried to use bookmark to save info: http://code.google.com/p/chromium/issues/detail?id=11431 It seems that the bookmark system only works in the extension itself. i.e., chromium.bookmarks is only defined in the extension domain (chrome-extension://[id]/name.html), but no in the web domain (e.g., http://domain.com). That means in order to save user information from the web domain (e.g.,http://domain.com), the content script needs to communicate w/ the extension, as described in this page: http://dev.chromium.org/developers/design-documents/extensions/proces... http://dev.chromium.org/developers/design-documents/extensions/conten... But I just tried, and 1) extension is undefined in the content script, not mentioning extension.addEventListener 2) chromium.extension.connect always fails. Any ideas or comments? P.S. a side question: is hidden_pages or chrome_scripts still alive in manifest.json? -Jack --~--~-~--~~~---~--~~ 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: Regarding using bookmark to save user info...
I am not sure you can (currently) connect from an HTTP origin to an extension. I guess it is not implemented yet or not even allowed at all. ☆PhistucK 2009/5/7 jack js2...@gmail.com Thanks for your tips PhistucK. I am using dev version (2.0.177.1). You are right the object name is chromium, and it works for the extension domain (chrome-extension://[id]/*). Also in web main (http://*) I can get chromium.extension.id_, but not chromium.bookmarks. Also although chromium.extension.connect is available, it always reports error (no such extension). Does that mean I need to go even beyond the dev version and build from the latest code base in order to try out these features? -Jack On May 7, 1:53 am, PhistucK phist...@gmail.com wrote: In what version?Beta, Dev or Chromium? Beta and Dev uses the chromium object, revision 15310http://src.chromium.org/viewvc/chrome?view=revrevision=15310 changed the name of the object to chrome. (So, chromium.tabs got changed to chrome.tabs) Maybe it helps. ☆PhistucK On Thu, May 7, 2009 at 10:47, jack js2...@gmail.com wrote: I just tried to use bookmark to save info: http://code.google.com/p/chromium/issues/detail?id=11431 It seems that the bookmark system only works in the extension itself. i.e., chromium.bookmarks is only defined in the extension domain (chrome-extension://[id]/name.html), but no in the web domain (e.g., http://domain.com). That means in order to save user information from the web domain (e.g.,http://domain.com), the content script needs to communicate w/ the extension, as described in this page: http://dev.chromium.org/developers/design-documents/extensions/proces. .. http://dev.chromium.org/developers/design-documents/extensions/conten. .. But I just tried, and 1) extension is undefined in the content script, not mentioning extension.addEventListener 2) chromium.extension.connect always fails. Any ideas or comments? P.S. a side question: is hidden_pages or chrome_scripts still alive in manifest.json? -Jack --~--~-~--~~~---~--~~ 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: Regarding using bookmark to save user info...
I'd rather believe it is a not-ready rather than not-allowed issue. Content scripts run in the http domain, and it is the recommended manner for content script to communicate w/ the extension, unless I understood it wrong. -Jack On May 7, 11:39 am, PhistucK phist...@gmail.com wrote: I am not sure you can (currently) connect from an HTTP origin to an extension. I guess it is not implemented yet or not even allowed at all. ☆PhistucK 2009/5/7 jack js2...@gmail.com Thanks for your tips PhistucK. I am using dev version (2.0.177.1). You are right the object name is chromium, and it works for the extension domain (chrome-extension://[id]/*). Also in web main (http://*) I can get chromium.extension.id_, but not chromium.bookmarks. Also although chromium.extension.connect is available, it always reports error (no such extension). Does that mean I need to go even beyond the dev version and build from the latest code base in order to try out these features? -Jack On May 7, 1:53 am, PhistucK phist...@gmail.com wrote: In what version?Beta, Dev or Chromium? Beta and Dev uses the chromium object, revision 15310http://src.chromium.org/viewvc/chrome?view=revrevision=15310 changed the name of the object to chrome. (So, chromium.tabs got changed to chrome.tabs) Maybe it helps. ☆PhistucK On Thu, May 7, 2009 at 10:47, jack js2...@gmail.com wrote: I just tried to use bookmark to save info: http://code.google.com/p/chromium/issues/detail?id=11431 It seems that the bookmark system only works in the extension itself. i.e., chromium.bookmarks is only defined in the extension domain (chrome-extension://[id]/name.html), but no in the web domain (e.g., http://domain.com). That means in order to save user information from the web domain (e.g.,http://domain.com), the content script needs to communicate w/ the extension, as described in this page: http://dev.chromium.org/developers/design-documents/extensions/proces. .. http://dev.chromium.org/developers/design-documents/extensions/conten. .. But I just tried, and 1) extension is undefined in the content script, not mentioning extension.addEventListener 2) chromium.extension.connect always fails. Any ideas or comments? P.S. a side question: is hidden_pages or chrome_scripts still alive in manifest.json? -Jack --~--~-~--~~~---~--~~ 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: Regarding using bookmark to save user info...
Oh, sorry, I thought you meant pure page javascript.Yes, of course, the content script is supposed to be able to interact. ☆PhistucK 2009/5/7 jack js2...@gmail.com I'd rather believe it is a not-ready rather than not-allowed issue. Content scripts run in the http domain, and it is the recommended manner for content script to communicate w/ the extension, unless I understood it wrong. -Jack On May 7, 11:39 am, PhistucK phist...@gmail.com wrote: I am not sure you can (currently) connect from an HTTP origin to an extension. I guess it is not implemented yet or not even allowed at all. ☆PhistucK 2009/5/7 jack js2...@gmail.com Thanks for your tips PhistucK. I am using dev version (2.0.177.1). You are right the object name is chromium, and it works for the extension domain (chrome-extension://[id]/*). Also in web main (http://*) I can get chromium.extension.id_, but not chromium.bookmarks. Also although chromium.extension.connect is available, it always reports error (no such extension). Does that mean I need to go even beyond the dev version and build from the latest code base in order to try out these features? -Jack On May 7, 1:53 am, PhistucK phist...@gmail.com wrote: In what version?Beta, Dev or Chromium? Beta and Dev uses the chromium object, revision 15310http://src.chromium.org/viewvc/chrome?view=revrevision=15310 changed the name of the object to chrome. (So, chromium.tabs got changed to chrome.tabs) Maybe it helps. ☆PhistucK On Thu, May 7, 2009 at 10:47, jack js2...@gmail.com wrote: I just tried to use bookmark to save info: http://code.google.com/p/chromium/issues/detail?id=11431 It seems that the bookmark system only works in the extension itself. i.e., chromium.bookmarks is only defined in the extension domain (chrome-extension://[id]/name.html), but no in the web domain (e.g., http://domain.com). That means in order to save user information from the web domain (e.g.,http://domain.com), the content script needs to communicate w/ the extension, as described in this page: http://dev.chromium.org/developers/design-documents/extensions/proces. .. http://dev.chromium.org/developers/design-documents/extensions/conten. .. But I just tried, and 1) extension is undefined in the content script, not mentioning extension.addEventListener 2) chromium.extension.connect always fails. Any ideas or comments? P.S. a side question: is hidden_pages or chrome_scripts still alive in manifest.json? -Jack --~--~-~--~~~---~--~~ 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: depot_tools is moving!
After checking out the latest from the new location, when I run 'gclient' now, I just get the following message (on Vista 64-bit): The system cannot find the batch label specified - SVN_FORCE -Greg. On Thu, May 7, 2009 at 8:56 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Please visit http://subversion.tigris.org to download the latest subversion client before continuing. You can also get the prebacked version used at http://src.chromium.org/svn/trunk/tools/third_party/ The thing that is missing now is to stop the message from happening you need to create depot_tools\svn.bat. Feel free to make it call anything. The default one is in depot_tools\bootstrap\win\svn.new.bat. Just copy it over to depot_tools\svn.bat. I'll try to make more resilient in the coming days. M-A On Thu, May 7, 2009 at 7:58 AM, avcoder ffm...@gmail.com wrote: I fail to update I get the following message: E:\depot_toolsgclient help Installing subversion ... [-] ADODB.Stream 800a01ad: Cannot save file (Automation server can't create object) ... Failed to checkout svn automatically. Please visit http://subversion.tigris.org to download the latest subversion client before continuing. You can also get the prebacked version used at http://src.chromium.org/svn/trunk/tools/third_party/ On May 2, 4:34 am, Marc-Antoine Ruel mar...@chromium.org wrote: gcl, gclient and friends are moving fromhttp:// src.chromium.org/svn/trunk/depot_tools/tohttp://src.chromium.org/svn/trunk/tools/depot_tools/ To help you with the switch, there is now a little script to switch automatically. Just run ** *convert_depot_tools* to convert the depot_tools to the new checkout. Warning: the output of this tool isn't nice. If anything fails, just checkout manually: *svn co **http://src.chromium.org/svn/**trunk/tools/depot_tools* http://src.chromium.org/svn/trunk/tools/depot_tools The end result is the same. The far biggest advantage is that there is only one place for all the scripts (no more platform specific) and you can now send patches directly from your depot_tools; e.g. no need to do a separate checkout and run scons anymore. The old depot_tools is scheduled to be removed on May 12, 2009 and you will be upgraded *automatically* next time you run gclient after that date. Windows-only side-effects: - It won't install svn client nor python if they are found in %PATH%. - If you used svn lately, the old depot_tools version was upgraded to 1.6. If you have svn 1.5 in your %PATH%, you may have trouble working with your checkout. Just removing your old client from the path and run gclient help again. 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] Linux: removing dependency on libviews
I'm working on http://crbug.com/11066 (removing depencency on libviews on Linux), and there's one thing I'm not sure how to do. It would be a good thing to ensure not only that nothing on Linux links to libviews, but also that nothing built on Linux doesn't #include anything in chrome/views/ For a one-time check, rm -rf chrome/views hammer check_if_it_still_builds would be ok, but I think it's easy to add such dependency by accident, and for some cases it may link fine on Linux. I was thinking about a gyp-aware checkdeps, but I also think it complicates things and is probably not the best solution. What do you think? I also noticed that there is some plan to develop an alternative libviews-based UI for Linux. This may affect this dependency-related work. Paweł --~--~-~--~~~---~--~~ 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: depot_tools is moving!
Thanks, fixed in revision 15567. Sorry about that. You will have to svn up your depot_tools directory. M-A On Thu, May 7, 2009 at 12:17 PM, Greg Spencer gspen...@google.com wrote: After checking out the latest from the new location, when I run 'gclient' now, I just get the following message (on Vista 64-bit): The system cannot find the batch label specified - SVN_FORCE -Greg. On Thu, May 7, 2009 at 8:56 AM, Marc-Antoine Ruel mar...@chromium.orgwrote: Please visit http://subversion.tigris.org to download the latest subversion client before continuing. You can also get the prebacked version used at http://src.chromium.org/svn/trunk/tools/third_party/ The thing that is missing now is to stop the message from happening you need to create depot_tools\svn.bat. Feel free to make it call anything. The default one is in depot_tools\bootstrap\win\svn.new.bat. Just copy it over to depot_tools\svn.bat. I'll try to make more resilient in the coming days. M-A On Thu, May 7, 2009 at 7:58 AM, avcoder ffm...@gmail.com wrote: I fail to update I get the following message: E:\depot_toolsgclient help Installing subversion ... [-] ADODB.Stream 800a01ad: Cannot save file (Automation server can't create object) ... Failed to checkout svn automatically. Please visit http://subversion.tigris.org to download the latest subversion client before continuing. You can also get the prebacked version used at http://src.chromium.org/svn/trunk/tools/third_party/ On May 2, 4:34 am, Marc-Antoine Ruel mar...@chromium.org wrote: gcl, gclient and friends are moving fromhttp:// src.chromium.org/svn/trunk/depot_tools/tohttp://src.chromium.org/svn/trunk/tools/depot_tools/ To help you with the switch, there is now a little script to switch automatically. Just run ** *convert_depot_tools* to convert the depot_tools to the new checkout. Warning: the output of this tool isn't nice. If anything fails, just checkout manually: *svn co **http://src.chromium.org/svn/**trunk/tools/depot_tools* http://src.chromium.org/svn/trunk/tools/depot_tools The end result is the same. The far biggest advantage is that there is only one place for all the scripts (no more platform specific) and you can now send patches directly from your depot_tools; e.g. no need to do a separate checkout and run scons anymore. The old depot_tools is scheduled to be removed on May 12, 2009 and you will be upgraded *automatically* next time you run gclient after that date. Windows-only side-effects: - It won't install svn client nor python if they are found in %PATH%. - If you used svn lately, the old depot_tools version was upgraded to 1.6. If you have svn 1.5 in your %PATH%, you may have trouble working with your checkout. Just removing your old client from the path and run gclient help again. 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: Linux: removing dependency on libviews
I could be a PRESUBMIT.py check that parses the .gyp files instead. M-A 2009/5/7 Paweł Hajdan Jr. phajdan...@chromium.org I'm working on http://crbug.com/11066 (removing depencency on libviews on Linux), and there's one thing I'm not sure how to do. It would be a good thing to ensure not only that nothing on Linux links to libviews, but also that nothing built on Linux doesn't #include anything in chrome/views/ For a one-time check, rm -rf chrome/views hammer check_if_it_still_builds would be ok, but I think it's easy to add such dependency by accident, and for some cases it may link fine on Linux. I was thinking about a gyp-aware checkdeps, but I also think it complicates things and is probably not the best solution. What do you think? I also noticed that there is some plan to develop an alternative libviews-based UI for Linux. This may affect this dependency-related work. Paweł --~--~-~--~~~---~--~~ 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: Implementing an onidle event (and the Linux implications)
I'd encourage you to implement it for extensions first. It seems really useful for queuing up notifications, etc. Adam 2009/5/7 PhistucK phist...@gmail.com: (Creating a new thread for it.) So, I started looking into it. And as you wrote, in order to implement this function for all of the platforms (is it even logical to implement a feature like an event only for certain platforms?), I will need to set the ENABLE_XSS_SUPPORT to 1 (like the comment there says). I just want to know whether I am wasting my time here, or it can really be taken into consideration. Now, Aaron suggested it might be a good idea to use the Extensions system as a playground for new features such as this one, so I thought about implementing it as chrome.onsystemidle. Does this make sense? acceptable? other suggestions? ☆PhistucK 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. It would also make us depend on xscreensaver on Linux which is :( but whatever. 2009/5/6 PhistucK phist...@gmail.com: One more thing - are you planning to implement a function that will return the status of the machine? For presence information, I want to know if the computer is idle and if it does, I do not want to signal the presence. Say, during screen saver or when the screen is shut down (through windows and its power management system, obviously, not through the shut down button :)). And if you were not planning on it - is it so easy to implement that you will implement it in a few seconds? ;) I wish I knew C++ (and had enough disk space :( really low now), I would have tried to implement it by myself or help a little with everything. :) ☆PhistucK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Wed, May 6, 2009 at 10:44 AM, Darin Fisher da...@chromium.org wrote: We could either use skia/ext/platform_canvas_mac.h or we could define it to be a CG type. I'm not sure I fully understand the hybridization of CG and Skia in our Chromium Mac port. I am equally (or even more so) clueless on CG. Anyway with hclam upstreaming our code an #ifdef solution might be the easiest way to get it working for now. I talked to Eric Carlson about the MediaPlayer interface and he had an idea about exposing which painting methods a MediaPlayer prefers (GraphicsContext or exposing an RGB surface) and having WebKit decide. We sort of have this today with the media engine and mime type supports, so it might not be a big stretch. Andrew -darin On Wed, May 6, 2009 at 10:41 AM, Darin Fisher da...@chromium.org wrote: We just need to figure out what the correct typedef is for the Mac platform. -Darin On Wed, May 6, 2009 at 10:40 AM, Darin Fisher da...@chromium.org wrote: Please see WebCanvas in the WebKit API. It was designed for this. -Darin On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus scher...@chromium.orgwrote: WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
We have exactly the same issue with WebWidget::paint. That uses WebCanvas. I think that WebMediaPlayer::paint should be the same. -Darin On Thu, May 7, 2009 at 1:50 PM, Andrew Scherkus scher...@chromium.orgwrote: On Wed, May 6, 2009 at 10:44 AM, Darin Fisher da...@chromium.org wrote: We could either use skia/ext/platform_canvas_mac.h or we could define it to be a CG type. I'm not sure I fully understand the hybridization of CG and Skia in our Chromium Mac port. I am equally (or even more so) clueless on CG. Anyway with hclam upstreaming our code an #ifdef solution might be the easiest way to get it working for now. I talked to Eric Carlson about the MediaPlayer interface and he had an idea about exposing which painting methods a MediaPlayer prefers (GraphicsContext or exposing an RGB surface) and having WebKit decide. We sort of have this today with the media engine and mime type supports, so it might not be a big stretch. Andrew -darin On Wed, May 6, 2009 at 10:41 AM, Darin Fisher da...@chromium.org wrote: We just need to figure out what the correct typedef is for the Mac platform. -Darin On Wed, May 6, 2009 at 10:40 AM, Darin Fisher da...@chromium.orgwrote: Please see WebCanvas in the WebKit API. It was designed for this. -Darin On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus scher...@chromium.orgwrote: WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Graceful updates on Linux
Is this still the plan? I don't see any alternative, since on Linux, when we get updated, the old version's files are no longer available, so any old instances still running either have to be happy with the new version's files, or not need any files at all. On Thu, Feb 5, 2009 at 11:35 AM, t...@chromium.org wrote: I think the current plan is to have a zygote used to spawn sub processes in which case it should be safe to change the chrome executable while it is running. The running chrome process won't depend on disk for anything (all data files are mmapped at process start up). On Thu, 5 Feb 2009, cpu wrote: Are there any implications for sandboxing on the fork vs exec ? I don't want us to paint ourselves in a corner when we implement the sandbox. On Feb 5, 9:57 am, Rahul Kuchhal kuch...@chromium.org wrote: If file structure on Linux is anywhere like Windows than the shared library (chrome.dll on Windows) would be versioned (the dll is kept inside a version directory on Windows) but the executable itself (chrome.exe) will always live at the same place. On Linux are we going to allow Chrome updates to happen while Chrome is running? In this is what we are aiming for forking sounds great since we will end up using the same exe version and this should work as long as we know which shared library we are using with it. On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: Firefox behaves terribly upon update on Linux because they didn't bother even trying to make distro updates work well, and everybody uses distro packages for Firefox. Let's avoid this same problem on Chrome for Linux. Does that sound like a reasonable goal? We're early enough in the port that it might not be too hard to bake that feature in. What would it take to survive all our files changing out from under us? I imagine it would suffice to: 1) open all the files we're going to need early, and keep the handles around for when we need them 2) for our own executables, don't exec, only fork. That would mean using a zygote, i.e. at startup time, fork before creating any threads, and have the initial instance just be a factory for anybody who needs another instance of that executable. Is that practical, and did I miss anything? - Dan --~--~-~--~~~---~--~~ 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: Graceful updates on Linux
This is still the vague plan, at least. Nobody's really looked at performance yet beyond making new tabs sure is slow on Linux; maybe the zygote bit would help, but it seems equally likely to me that we've got other things going wrong. On Thu, May 7, 2009 at 2:19 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: Is this still the plan? I don't see any alternative, since on Linux, when we get updated, the old version's files are no longer available, so any old instances still running either have to be happy with the new version's files, or not need any files at all. On Thu, Feb 5, 2009 at 11:35 AM, t...@chromium.org wrote: I think the current plan is to have a zygote used to spawn sub processes in which case it should be safe to change the chrome executable while it is running. The running chrome process won't depend on disk for anything (all data files are mmapped at process start up). On Thu, 5 Feb 2009, cpu wrote: Are there any implications for sandboxing on the fork vs exec ? I don't want us to paint ourselves in a corner when we implement the sandbox. On Feb 5, 9:57 am, Rahul Kuchhal kuch...@chromium.org wrote: If file structure on Linux is anywhere like Windows than the shared library (chrome.dll on Windows) would be versioned (the dll is kept inside a version directory on Windows) but the executable itself (chrome.exe) will always live at the same place. On Linux are we going to allow Chrome updates to happen while Chrome is running? In this is what we are aiming for forking sounds great since we will end up using the same exe version and this should work as long as we know which shared library we are using with it. On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: Firefox behaves terribly upon update on Linux because they didn't bother even trying to make distro updates work well, and everybody uses distro packages for Firefox. Let's avoid this same problem on Chrome for Linux. Does that sound like a reasonable goal? We're early enough in the port that it might not be too hard to bake that feature in. What would it take to survive all our files changing out from under us? I imagine it would suffice to: 1) open all the files we're going to need early, and keep the handles around for when we need them 2) for our own executables, don't exec, only fork. That would mean using a zygote, i.e. at startup time, fork before creating any threads, and have the initial instance just be a factory for anybody who needs another instance of that executable. Is that practical, and did I miss anything? - Dan --~--~-~--~~~---~--~~ 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: Graceful updates on Linux
I have no idea what I'm talking about, but hand wavingI just wanted to comment that on Linux when firefox is updated while I'm running, things start getting really weird and it generally becomes unusable pretty quickly...no idea why, but I assume it has something to do with its resources being deleted out from under it and the caches of such items eventually going away and it getting very confused. Hopefully whatever we do won't suffer such problems./hand waving On Thu, May 7, 2009 at 2:39 PM, Evan Martin e...@chromium.org wrote: This is still the vague plan, at least. Nobody's really looked at performance yet beyond making new tabs sure is slow on Linux; maybe the zygote bit would help, but it seems equally likely to me that we've got other things going wrong. On Thu, May 7, 2009 at 2:19 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: Is this still the plan? I don't see any alternative, since on Linux, when we get updated, the old version's files are no longer available, so any old instances still running either have to be happy with the new version's files, or not need any files at all. On Thu, Feb 5, 2009 at 11:35 AM, t...@chromium.org wrote: I think the current plan is to have a zygote used to spawn sub processes in which case it should be safe to change the chrome executable while it is running. The running chrome process won't depend on disk for anything (all data files are mmapped at process start up). On Thu, 5 Feb 2009, cpu wrote: Are there any implications for sandboxing on the fork vs exec ? I don't want us to paint ourselves in a corner when we implement the sandbox. On Feb 5, 9:57 am, Rahul Kuchhal kuch...@chromium.org wrote: If file structure on Linux is anywhere like Windows than the shared library (chrome.dll on Windows) would be versioned (the dll is kept inside a version directory on Windows) but the executable itself (chrome.exe) will always live at the same place. On Linux are we going to allow Chrome updates to happen while Chrome is running? In this is what we are aiming for forking sounds great since we will end up using the same exe version and this should work as long as we know which shared library we are using with it. On Thu, Feb 5, 2009 at 9:33 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: Firefox behaves terribly upon update on Linux because they didn't bother even trying to make distro updates work well, and everybody uses distro packages for Firefox. Let's avoid this same problem on Chrome for Linux. Does that sound like a reasonable goal? We're early enough in the port that it might not be too hard to bake that feature in. What would it take to survive all our files changing out from under us? I imagine it would suffice to: 1) open all the files we're going to need early, and keep the handles around for when we need them 2) for our own executables, don't exec, only fork. That would mean using a zygote, i.e. at startup time, fork before creating any threads, and have the initial instance just be a factory for anybody who needs another instance of that executable. Is that practical, and did I miss anything? - Dan --~--~-~--~~~---~--~~ 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] content-type
Right now, the extension system treats any downloaded file that ends in .crx as an extension. This seems like a bad idea, and that we should use a content type. Firefox uses the content type application/x-xpinstall. However, as a Firefox extension developer, I can tell you the content type thing is one of the more frustrating parts of the entire experience. *No* web servers are configured to know that xpi files should be served with a special content type, so you end up having to fight with your server, file share, whatever to make installation work. I would like to avoid this headache if we can. I know that content sniffing is a very dirty business, but our crx files have a very specific format, including a few signature bytes at the very beginning. What if we supported both a content-type *and* did content sniffing of downloaded .crx files? This would allow the simple case of uploading a crx file somewhere to work, as well as allowing files that don't end in .crx to work for more advanced hosts. Thoughts? Also, for the content-type, we were thinking application/x-chrome-extension. Thoughts 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: [extensions] content-type
On Thu, May 7, 2009 at 3:35 PM, Aaron Boodman a...@chromium.org wrote: I know that content sniffing is a very dirty business, but our crx files have a very specific format, including a few signature bytes at the very beginning. What if we supported both a content-type *and* did content sniffing of downloaded .crx files? I'm sure abarth will reply with the right thing to do :) Generally, the Content-Type restriction is to stop confusion in the case where sites accept uploads of files. If one sniffs the content-type then it might appear that an extension is from a trusted site when it's actually the case that the site just let someone random upload the file. If this is a concern, then we shouldn't accept an extension without the content-type or, maybe, if we content-sniff then we don't say xyz.com wishes to install an extension, but An unidentified party wishes to install an extension. Thoughts? Also, for the content-type, we were thinking application/x-chrome-extension. Thoughts on that? That seems good. AGL --~--~-~--~~~---~--~~ 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] content-type
On Thu, May 7, 2009 at 3:35 PM, Aaron Boodman a...@chromium.org wrote: Right now, the extension system treats any downloaded file that ends in .crx as an extension. This seems like a bad idea, and that we should use a content type. You have two use cases in mind here, and I think your solutions are mixing them. In the (rare) case where someone has the correct mime type set, we should obey the mime type and do no sniffing. I think that's non-controversial. That leaves the user cannot set the mime type case. So we're getting application/octet-stream or whatever and the question is how to upgrade from that to an extension install. It seems to me the filename extension is more obvious to a developer than any scary heuristic. Options here (I can't tell if you're suggesting #2 or #3): 1) filename extension only (what I'm suggesting) 2) require both filename extension and sniffing to match (seems to be only minimally different from option #1 -- the delta is cases where you have a .crx that is *not* an extension, but you'll also have this with corrupt extension files where you ought to have some UI to handle it anyway) 3) ignore filename, try sniffing out of other app/octet-stream files. Seems unpredictable to me. --~--~-~--~~~---~--~~ 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] content-type
On Thu, May 7, 2009 at 3:52 PM, Evan Martin e...@chromium.org wrote: You have two use cases in mind here, and I think your solutions are mixing them. In the (rare) case where someone has the correct mime type set, we should obey the mime type and do no sniffing. I think that's non-controversial. Yes, non-controversial, in that case it is an extension for sure. That leaves the user cannot set the mime type case. So we're getting application/octet-stream or whatever and the question is how to upgrade from that to an extension install. It seems to me the filename extension is more obvious to a developer than any scary heuristic. Options here (I can't tell if you're suggesting #2 or #3): 1) filename extension only (what I'm suggesting) 2) require both filename extension and sniffing to match (seems to be only minimally different from option #1 -- the delta is cases where you have a .crx that is *not* an extension, but you'll also have this with corrupt extension files where you ought to have some UI to handle it anyway) 3) ignore filename, try sniffing out of other app/octet-stream files. Seems unpredictable to me. I was suggesting 2), trying to avoid the case where we mistake some existing blob on the web that happens to end in .crx as an 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] Re: [extensions] content-type
On Thu, May 7, 2009 at 3:55 PM, Aaron Boodman a...@chromium.org wrote: On Thu, May 7, 2009 at 3:52 PM, Evan Martin e...@chromium.org wrote: Options here (I can't tell if you're suggesting #2 or #3): 1) filename extension only (what I'm suggesting) 2) require both filename extension and sniffing to match (seems to be only minimally different from option #1 -- the delta is cases where you have a .crx that is *not* an extension, but you'll also have this with corrupt extension files where you ought to have some UI to handle it anyway) 3) ignore filename, try sniffing out of other app/octet-stream files. Seems unpredictable to me. I was suggesting 2), trying to avoid the case where we mistake some existing blob on the web that happens to end in .crx as an extension. Ugg. I basically agree with Adam. Here's what I'd recommend: 1) If the response has the right MIME type, then we can believe that the site has endorsed the extension. As Adam says, Site http://foo.bar.com wises to install an extension. 2) If the response has one of the following Content-Types: * No Content-Type * text/plain * application/octet-stream AND the URL has the .crx extension AND the response starts with a magic string (such as CHROME EXTENSION), then believe that the response is an extension, but don't believe that the site has endorsed the extension. As Adam says, An unknown party wishes to install an extension. Adam --~--~-~--~~~---~--~~ 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: Implementing an onidle event (and the Linux implications)
fwiw, gears had an implementation that didn't depend on XScreenSaverQueryInfo http://code.google.com/p/gears/source/detail?r=2641path=/trunk/gears/notifier/user_activity.cc see user_activity_linux.cc 2009/5/7 Adam Barth aba...@chromium.org I'd encourage you to implement it for extensions first. It seems really useful for queuing up notifications, etc. Adam 2009/5/7 PhistucK phist...@gmail.com: (Creating a new thread for it.) So, I started looking into it. And as you wrote, in order to implement this function for all of the platforms (is it even logical to implement a feature like an event only for certain platforms?), I will need to set the ENABLE_XSS_SUPPORT to 1 (like the comment there says). I just want to know whether I am wasting my time here, or it can really be taken into consideration. Now, Aaron suggested it might be a good idea to use the Extensions system as a playground for new features such as this one, so I thought about implementing it as chrome.onsystemidle. Does this make sense? acceptable? other suggestions? ☆PhistucK 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. It would also make us depend on xscreensaver on Linux which is :( but whatever. 2009/5/6 PhistucK phist...@gmail.com: One more thing - are you planning to implement a function that will return the status of the machine? For presence information, I want to know if the computer is idle and if it does, I do not want to signal the presence. Say, during screen saver or when the screen is shut down (through windows and its power management system, obviously, not through the shut down button :)). And if you were not planning on it - is it so easy to implement that you will implement it in a few seconds? ;) I wish I knew C++ (and had enough disk space :( really low now), I would have tried to implement it by myself or help a little with everything. :) ☆PhistucK --~--~-~--~~~---~--~~ 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] content-type
On Thu, May 7, 2009 at 4:09 PM, Adam Barth aba...@chromium.org wrote: Ugg. I know. What can I say? We are caught between idealism and practicality. 1) If the response has the right MIME type, then we can believe that the site has endorsed the extension. As Adam says, Site http://foo.bar.com wises to install an extension. 2) If the response has one of the following Content-Types: * No Content-Type * text/plain * application/octet-stream AND the URL has the .crx extension AND the response starts with a magic string (such as CHROME EXTENSION), then believe that the response is an extension, but don't believe that the site has endorsed the extension. As Adam says, An unknown party wishes to install an extension. Ok, thanks for the recommendation. Currently the magic string is Cr24. Not enough characters? - 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: Implementing an onidle event (and the Linux implications)
Does this mean PhistucK could just rely on the gears implementation? Then it would require no Chrome changes. 2009/5/7 David Levin le...@chromium.org: fwiw, gears had an implementation that didn't depend on XScreenSaverQueryInfo http://code.google.com/p/gears/source/detail?r=2641path=/trunk/gears/notifier/user_activity.cc see user_activity_linux.cc 2009/5/7 Adam Barth aba...@chromium.org I'd encourage you to implement it for extensions first. It seems really useful for queuing up notifications, etc. Adam 2009/5/7 PhistucK phist...@gmail.com: (Creating a new thread for it.) So, I started looking into it. And as you wrote, in order to implement this function for all of the platforms (is it even logical to implement a feature like an event only for certain platforms?), I will need to set the ENABLE_XSS_SUPPORT to 1 (like the comment there says). I just want to know whether I am wasting my time here, or it can really be taken into consideration. Now, Aaron suggested it might be a good idea to use the Extensions system as a playground for new features such as this one, so I thought about implementing it as chrome.onsystemidle. Does this make sense? acceptable? other suggestions? ☆PhistucK 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. It would also make us depend on xscreensaver on Linux which is :( but whatever. 2009/5/6 PhistucK phist...@gmail.com: One more thing - are you planning to implement a function that will return the status of the machine? For presence information, I want to know if the computer is idle and if it does, I do not want to signal the presence. Say, during screen saver or when the screen is shut down (through windows and its power management system, obviously, not through the shut down button :)). And if you were not planning on it - is it so easy to implement that you will implement it in a few seconds? ;) I wish I knew C++ (and had enough disk space :( really low now), I would have tried to implement it by myself or help a little with everything. :) ☆PhistucK --~--~-~--~~~---~--~~ 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] content-type
On Thu, May 7, 2009 at 4:17 PM, Aaron Boodman a...@chromium.org wrote: Ok, thanks for the recommendation. Currently the magic string is Cr24. Not enough characters? I suggested the above to be analogous to HTML5's appcache manifests: http://www.whatwg.org/specs/web-apps/current-work/#a-sample-manifest In general, the closer you are to that, the more predictable the web becomes. Adam --~--~-~--~~~---~--~~ 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: Implementing an onidle event (and the Linux implications)
That file has been deleted from gears -- not as a reflection on the implementation but due to the lack of its use in gears. 2009/5/7 Evan Martin e...@chromium.org Does this mean PhistucK could just rely on the gears implementation? Then it would require no Chrome changes. 2009/5/7 David Levin le...@chromium.org: fwiw, gears had an implementation that didn't depend on XScreenSaverQueryInfo http://code.google.com/p/gears/source/detail?r=2641path=/trunk/gears/notifier/user_activity.cc see user_activity_linux.cc 2009/5/7 Adam Barth aba...@chromium.org I'd encourage you to implement it for extensions first. It seems really useful for queuing up notifications, etc. Adam 2009/5/7 PhistucK phist...@gmail.com: (Creating a new thread for it.) So, I started looking into it. And as you wrote, in order to implement this function for all of the platforms (is it even logical to implement a feature like an event only for certain platforms?), I will need to set the ENABLE_XSS_SUPPORT to 1 (like the comment there says). I just want to know whether I am wasting my time here, or it can really be taken into consideration. Now, Aaron suggested it might be a good idea to use the Extensions system as a playground for new features such as this one, so I thought about implementing it as chrome.onsystemidle. Does this make sense? acceptable? other suggestions? ☆PhistucK 2009/5/6 Evan Martin e...@chromium.org base/idle_timer implements this. The only implementation detail would be exposing it to JS. It would also make us depend on xscreensaver on Linux which is :( but whatever. 2009/5/6 PhistucK phist...@gmail.com: One more thing - are you planning to implement a function that will return the status of the machine? For presence information, I want to know if the computer is idle and if it does, I do not want to signal the presence. Say, during screen saver or when the screen is shut down (through windows and its power management system, obviously, not through the shut down button :)). And if you were not planning on it - is it so easy to implement that you will implement it in a few seconds? ;) I wish I knew C++ (and had enough disk space :( really low now), I would have tried to implement it by myself or help a little with everything. :) ☆PhistucK --~--~-~--~~~---~--~~ 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: Try out --enable-omnibox2!
Great! adds a new fresh look. One question though, is the transparency really needed? It distracts me for some reason from the actual results. I suggest lowering down the transparency a little, but that's just me. On Thu, May 7, 2009 at 1:53 PM, Ben Goodger (Google) b...@chromium.orgwrote: Please try out the --enable-omnibox2 command line switch in Chrome and file bugs against me in the issue tracker. I'd like to get a better sense of what needs to be done with it so we can turn it on by default. The differences thus far are aesthetic, and in the popup. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: depot_tools is moving!
Thanks Why not just apply the svn switch --relocate http://src.chromium.org/svn/trunk/depot_tools/ http://src.chromium.org/svn/trunk/tools/depot_tools/; if you only just switch to a new svn url? On Thu, May 7, 2009 at 11:56 PM, Marc-Antoine Ruel mar...@chromium.org wrote: Please visit http://subversion.tigris.org to download the latest subversion client before continuing. You can also get the prebacked version used at http://src.chromium.org/svn/trunk/tools/third_party/ The thing that is missing now is to stop the message from happening you need to create depot_tools\svn.bat. Feel free to make it call anything. The default one is in depot_tools\bootstrap\win\svn.new.bat. Just copy it over to depot_tools\svn.bat. I'll try to make more resilient in the coming days. -- -- Inspired by http://ppnext.com Your potential. Our passion. --~--~-~--~~~---~--~~ 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: webkit gyp conversion, another (likely) attempt tonight
[sent this earlier, but from the wrong address...] I'm going ahead with the attempted webkit conversion tonight. ETA to close the tree ~20:30 PDT. --SK On Thu, May 7, 2009 at 11:02 AM, Steven Knight s...@chromium.org wrote: Heads up: I'm gearing up to close the tree tonight for another attempt at converting the webkit build to gyp, closure starting some time between 20:00 and 22:00 PDT. If this would be a serious imposition, let me know. I'm still working on a few last issues. If I run into another serious roadblock, there's a chance I'll wave off tonight. I'll send out another announcement with final word on whether or not I'm going ahead, and at what specific time, by COB today (~17:00 PDT). In addition to fixing the layout test failures from last attempt, this recent work has been trying to make sure all the dependency and source lists (esp. including resources) are functionally equivalent, by isolating and explaining any size discrepancies between VS-built and gyp-built .lib, .dll and .exe files. The most prominent change in the internal build architecture is that the V* binding are longer built as as separate .lib (i.e., there's no separate V8Bindings target), but are now part of webcore.lib. I've been specifically verifying the following functionality: - Debug builds from scratch - Debug null rebuild (everything up to date) - Release builds from scratch - Release null rebuild (everything up to date) - Tests that will be run by the buildbots all pass (or at least exhibit the same failures as the vanilla VS build) I specifically know that I haven't done anything to verify the following: - Purify builds (erikkay, if there's something simple you or I can do to sanity-check this ahead of time, let me know) If you have some other piece of crucial functionality that really *must* be verified as functioning correctly before we cut this over officially, please let me know. We simply don't have a good central, list of every functional piece that every script or other piece of infrastructure expects our build to do (let alone what developer workflows expect...). Barring some really disastrous problem, I'm planning to leave what we have in place and recruit people to help hunt down and fix additional discrepancies between the new and old builds (and will announce anything known to be not working). The rate of change in the code base (especially in the webkit.gyp and chrome.gyp files) means we simply have to get out of trying to play a constant game of catch-up with this change. Thanks, --SK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] FYI - src/chrome/views is now src/views
views has moved into a top level directory under src/. While not yet fully autonomous from chrome (yet) I am in the process of writing a stricter DEPS file that will now prevent new includes from chrome/. If you need to pull something into a common location used by views and some other part of the system, consider src/app/ -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] build error
I've been getting the following build error for the past couple days on Windows. It happens if I use Incredibuild or VS. It happens on a totally fresh checkout. Any one have any ideas as to what could be causing this? 9-- Build started: Project: mksnapshot, Configuration: Debug Win32 -- 9Compiling... 9mksnapshot.cc 9Linking... 9mksnapshot.obj : error LNK2019: unresolved external symbol public: static int __cdecl v8::internal::NativesCollection0::GetBuiltinsCount(void) (?getbuiltinsco...@?$nativescollection@$0A@@inter...@v8@@SAHXZ) referenced in function _main 9v8_base.lib(heap.obj) : error LNK2001: unresolved external symbol public: static int __cdecl v8::internal::NativesCollection0::GetBuiltinsCount(void) (?getbuiltinsco...@?$nativescollection@$0A@@inter...@v8@@SAHXZ) 9v8_base.lib(bootstrapper.obj) : error LNK2001: unresolved external symbol public: static int __cdecl v8::internal::NativesCollection0::GetBuiltinsCount(void) (?getbuiltinsco...@?$nativescollection@$0A@@inter...@v8@@SAHXZ) 9v8_base.lib(bootstrapper.obj) : error LNK2019: unresolved external symbol public: static class v8::internal::Vectorchar const __cdecl v8::internal::NativesCollection0::GetScriptSource(int) (?GetScriptSource@ ?$nativescollect...@$0a@@inter...@v8@@sa?av?$vec...@$$cbd@2...@h@Z) referenced in function public: static class v8::internal::Handleclass v8::internal::String __cdecl v8::internal::Bootstrapper::NativesSourceLookup(int) (?nativessourceloo...@bootstrapper@inter...@v8@@sa?av?$han...@vstring @inter...@v8@@@2...@h@Z) 9v8_base.lib(bootstrapper.obj) : error LNK2019: unresolved external symbol public: static class v8::internal::Vectorchar const __cdecl v8::internal::NativesCollection0::GetScriptName(int) (?GetScriptName@ ?$nativescollect...@$0a@@inter...@v8@@sa?av?$vec...@$$cbd@2...@h@Z) referenced in function private: static bool __cdecl v8::internal::Genesis::CompileBuiltin(int) (?compilebuil...@genesis @inter...@v8@@ca...@z) 9v8_base.lib(debug.obj) : error LNK2001: unresolved external symbol public: static class v8::internal::Vectorchar const __cdecl v8::internal::NativesCollection0::GetScriptName(int) (?GetScriptName@ ?$nativescollect...@$0a@@inter...@v8@@sa?av?$vec...@$$cbd@2...@h@Z) 9v8_base.lib(handles.obj) : error LNK2001: unresolved external symbol public: static class v8::internal::Vectorchar const __cdecl v8::internal::NativesCollection0::GetScriptName(int) (?GetScriptName@ ?$nativescollect...@$0a@@inter...@v8@@sa?av?$vec...@$$cbd@2...@h@Z) 9v8_base.lib(bootstrapper.obj) : error LNK2019: unresolved external symbol public: static int __cdecl v8::internal::NativesCollection0::GetIndex(char const *) (?GetIndex@ ?$nativescollect...@$0a@@inter...@v8@@sah...@z) referenced in function private: bool __thiscall v8::internal::Genesis::InstallNatives(void) (?installnati...@genesis@inter...@v8@@AAE_NXZ) 9v8_base.lib(debug.obj) : error LNK2001: unresolved external symbol public: static int __cdecl v8::internal::NativesCollection0::GetIndex(char const *) (?GetIndex@ ?$nativescollect...@$0a@@inter...@v8@@sah...@z) 9v8_base.lib(bootstrapper.obj) : error LNK2019: unresolved external symbol public: static int __cdecl v8::internal::NativesCollection0::GetDelayCount(void) (?GetDelayCount@ ?$nativescollect...@$0a@@inter...@v8@@SAHXZ) referenced in function private: bool __thiscall v8::internal::Genesis::InstallNatives(void) (?installnati...@genesis@inter...@v8@@AAE_NXZ) 9v8_base.lib(snapshot-common.obj) : error LNK2001: unresolved external symbol private: static unsigned char const * const v8::internal::Snapshot::data_ (?da...@snapshot@inter...@v8@@0QBEB) 9v8_base.lib(snapshot-common.obj) : error LNK2001: unresolved external symbol private: static int v8::internal::Snapshot::size_ (?si...@snapshot @inter...@v8@@0HA) 9E:\chromium\src\chrome\Debug\mksnapshot.exe : fatal error LNK1120: 7 unresolved externals 9Build log was saved at file://E:\chromium\src\chrome\Debug\obj\mksnapshot\BuildLog.htm 9mksnapshot - 13 error(s), 0 warning(s) --~--~-~--~~~---~--~~ 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] content-type
On Thu, May 7, 2009 at 4:20 PM, Adam Barth aba...@chromium.org wrote: On Thu, May 7, 2009 at 4:17 PM, Aaron Boodman a...@chromium.org wrote: Ok, thanks for the recommendation. Currently the magic string is Cr24. Not enough characters? I suggested the above to be analogous to HTML5's appcache manifests: http://www.whatwg.org/specs/web-apps/current-work/#a-sample-manifest In general, the closer you are to that, the more predictable the web becomes. Just to clarify, you understand we're talking about a binary package here, right? Not a text file. Chrome extensions are distributed in what are essentially zip files with some extra metadata tacked on. The first several bytes of that zip file is currently always Cr24. You're saying it should be CHROME EXTENSION instead. Is there any specific value in being closer to the way the appcache manifests work, other than having a longer signature? - 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] Linux splash page update
I've noticed a good deal of helpful bugs filed recently for linux by people who are not developing chromum. Our splash page still says: Please don't file bugs: this point there are so many gaping holes that finding bugs is not the problem and dealing with them is just a distraction. I think it's time to reword this, as users filing bugs has already proven helpful (to me anyway). Also, I don't think we're really treating it as a pre-alpha any more since user-requested features (such as hotkeys, ui elements, etc.) are getting priority. So I propose to update this page. I think instead of the please don't file bugs it should point users to crbug.com, but implore them to report crashers and other broken things rather than missing features, and tell them to use the search first and whatnot. Of course if people completely ignore this splash page (which they seem to do) I guess it's a moot point. -- Evan Stade --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
