[chromium-dev] Mac/Linux & blank tabs (or "don't panic!")
Hey folks, just a heads up. I landed some changes to browser/dom_ui and the temp scaffolding to begin the process of hooking up the new tab page. As of right now, however, all it does is load a url called "chrome-internal:" and display a blank tab. This is expected behavior. I didn't want anyone to freak out and think rendering was broken. If you type a page into the url bar, everything is still fully functional. -- 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: Google Chrome's Most visited page is inferior to Apple Safari 4 (beta) Top Sites page
+1 meetoo On Wed, Feb 25, 2009 at 12:43 AM, Peter Kasting wrote: > On Tue, Feb 24, 2009 at 6:34 PM, Evan Martin wrote: >> >> Yes, I would suggest it is urgent that we improve all of Chromium as >> rapidly as possible. > > I AGREE THINGS THAT ARE BAD SHOULD BE LESS BAD > PLEASE TO BE FIX THIS NOW I CANOT TELL ALL MY FREIND TO SWITCH FROM FOXFIRE > PK > > > -- 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: Mac chrome from the tree
Actually, http://dev.chromium.org wasn't ever a problem. More importantly: We can now render http://www.google.com without crashing!!! :-D On Wed, Feb 25, 2009 at 12:32 AM, John Grabowski wrote: > For Mac Chrome multiprocess bringup a group of us had been throwing diffs > around. There were various reasons for this; e.g. hacks which can't be > landed without more work, changes that need to be upstreamed, and so on. > The last of these has landed with http://codereview.chromium.org/27108. > In short, this means a build of Chromium.app from an unmodified tree can now > render http://dev.chromium.org without crashing. > MacChromeTastic! > jrg > > > -- 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: Mac chrome from the tree
Great! Keep up the good work :) On Wed, Feb 25, 2009 at 9:19 AM, Mike Pinkerton wrote: > > Actually, http://dev.chromium.org wasn't ever a problem. More importantly: > > We can now render http://www.google.com without crashing!!! > > :-D > > On Wed, Feb 25, 2009 at 12:32 AM, John Grabowski wrote: > > For Mac Chrome multiprocess bringup a group of us had been throwing diffs > > around. There were various reasons for this; e.g. hacks which can't be > > landed without more work, changes that need to be upstreamed, and so on. > > The last of these has landed with http://codereview.chromium.org/27108. > > In short, this means a build of Chromium.app from an unmodified tree can > now > > render http://dev.chromium.org without crashing. > > MacChromeTastic! > > jrg > > > > > > > > > -- > 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] Streamlining key events
If you never use the keyboard in Chromium, you can skip this email. I'm going to land http://codereview.chromium.org/27056 which fixes most of the glaring problems with keyboard support on the Mac by unifying and streamlining key events for everyone. If things don't work for you, it's probably my fault. Wanted to give a heads-up. 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: Streamlining key events
Avi went above and beyond the call of duty to make it work on Linux too! As your prize, I send you a video of RMS dancing: http://www.youtube.com/watch?v=Pube5Aynsls On Wed, Feb 25, 2009 at 11:15 AM, Avi Drissman wrote: > If you never use the keyboard in Chromium, you can skip this email. > > I'm going to land http://codereview.chromium.org/27056 which fixes most of > the glaring problems with keyboard support on the Mac by unifying and > streamlining key events for everyone. If things don't work for you, it's > probably my fault. Wanted to give a heads-up. > > 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: Streamlining key events
On Wed, Feb 25, 2009 at 11:49 AM, Evan Martin wrote: > As your prize, I send you a video of RMS dancing: > http://www.youtube.com/watch?v=Pube5Aynsls RMS is disturbed that video of himself is available on a site not run by Free Software. I am just disturbed at that video of him. 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] [Linux] new symlinks needed
Linux builds after r10369 will need some additional symlinks on 64-bit Ubuntu machines. Ubuntu messed up the /usr/lib32 directory, this should fix it. Evan is updating the docs: # cd /usr/lib32 # ln -s libX11.so.6.2.0 libX11.so # ln -s libXrender.so.1.3.0 libXrender.so # ln -s libXext.so.6.4.0 libXext.so Once can also run ./build/install-build-deps.sh 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: [Linux] new symlinks needed
On Wed, Feb 25, 2009 at 1:00 PM, Adam Langley wrote: > Linux builds after r10369 will need some additional symlinks on 64-bit > Ubuntu machines. Also, one may notice that red and blue are swapped on shared memory X setups. I'll be fixing that soon ;) 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] linux async IO
Hey Dean, I talked to Darin and he told me that this needs work since it's impacting the page cycler times, so I figured I'd pick it up. You have a TODO there saying to figure out how to best do async IO. Did you ever figure this out? I talked to Darin briefly and decided that the simplest thing to do for now is simply to post tasks to the global WorkerPool. The global WorkerPool linux implementation looks pretty silly and needs work, but it's probably good enough for the page cycler. How does this approach sound to you? --~--~-~--~~~---~--~~ 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 async IO
On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌) wrote: > I talked to Darin and he told me that this needs work since it's > impacting the page cycler times, so I figured I'd pick it up. You > have a TODO there saying to figure out how to best do async IO. Did > you ever figure this out? I talked to Darin briefly and decided that > the simplest thing to do for now is simply to post tasks to the global > WorkerPool. The global WorkerPool linux implementation looks pretty > silly and needs work, but it's probably good enough for the page > cycler. How does this approach sound to you? It's not clear if you were considering using POSIX async IO on Linux or not. Just in case you were: don't. It mostly doesn't work. 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] Let's make build system history!
Over the past month, some of us have been working on a not-so-well-kept secret project to create a "build system system." Our goal is to have something Generate Your Projects (GYP) in a variety of formats, all from the same source. Today, we're ready to allow Mac developers to begin testing this experimental system. If you're on a Mac, I encourage you to try this out. From the "src/build" directory in a Chromium working copy, run: ../tools/gyp/gyp and in less than 10 seconds, a whole bunch of new Xcode projects will be generated for you. For the most part, they follow the same structure as the existing Xcode projects you're familiar with, so if you've been working with chrome.xcodeproj or test_shell.xcodeproj, you'll have no problem finding and using chrome_gyp.xcodeproj and test_shell_gyp.xcodeproj. Similarly, build results go into xcodebuild_gyp. The _gyp suffix is temporary, and keeps us from clobbering the old checked-in project files. Right now, Generating Your Projects is voluntary and manual. If a .gyp file changes because you've edited it or because of a sync, you'll need to re-run the above command to regenerate your project files. Before we go live, we'll add a hook to gclient to Generate Your Projects automatically when .gyp files change during a sync. I believe that the generated projects are now at parity with the old checked-in project files, but the .gyp files do suffer from becoming outdated pretty quickly. If you're adding or removing files from the tree, I'd appreciate it if you could help me out by making the appropriate modifications to our .gyp files. For the time being, please Cc me on all reviews involving a .gyp file. I think you'll all find that maintaining .gyp files is far easier than working with Xcode projects. We have some work-in-progress documentation available at http://code.google.com/p/gyp/w/list to help orient yourself. I'll be working more on the documentation in the days to come. We've also made significant progress on gyp-based Visual Studio, SCons, and Makefile generation, so those of you who aren't using Macs won't miss out for too long. Have fun! Mark --~--~-~--~~~---~--~~ 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 async IO
Woops, newbie mistake, sent from my google.com addr the first time. 2009/2/25 William Chan (陈智昌) : > Sorry for not being clear. Yep, you're correct, I'm not planning use > POSIX async IO. Just planning to execute the sync IO on the > WorkerPool. > > On Wed, Feb 25, 2009 at 1:21 PM, Adam Langley wrote: >> On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌) >> wrote: >>> I talked to Darin and he told me that this needs work since it's >>> impacting the page cycler times, so I figured I'd pick it up. You >>> have a TODO there saying to figure out how to best do async IO. Did >>> you ever figure this out? I talked to Darin briefly and decided that >>> the simplest thing to do for now is simply to post tasks to the global >>> WorkerPool. The global WorkerPool linux implementation looks pretty >>> silly and needs work, but it's probably good enough for the page >>> cycler. How does this approach sound to you? >> >> It's not clear if you were considering using POSIX async IO on Linux >> or not. Just in case you were: don't. It mostly doesn't work. >> >> 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] [linux] converting some notimplemented()s into bugs
As we get closer to something stable, it's helpful to not have real error messages masked by console spew about bits we don't especially care about yet. For example, we currently output this on startup: [4635:4635:1130873151532:ERROR:browser/process_singleton_linux.cc(60)] Not implemented reached in void ProcessSingleton::HuntForZombieChromeProcesses() That function on Windows attempts to, during startup, find previous instances of Chrome that have hung and kill them if necessary. Maybe it'd be a good idea for us to have something similar (if it's even possible to judge whether the other processes are hung) but it is not helpful right now. I suggest removing such calls to NOTIMPEMENTED() and converting them into bugs. A good heuristic is if it would be filed as a low-priority bug if the code didn't work, then it's probably safe to make it into a low-priority bug now. (Don't forget the os:linux label if appropriate.) Large NOTIMPLEMENTEDs that represent real holes, like those that will cause crashes or our missing support for keyboard accelerators, are better to leave in the code for now. Use your judgement. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] NSS and NSPR
Sorry for arriving late w/ this question... I'm guessing NSS & NSPR are needed for the linux build? Should they be pulled in via DEPS instead of being directly in src/third_party? In the current form it causes both mac and windows to have to add ~80M to their svn trees that really isn't needed. TVL --~--~-~--~~~---~--~~ 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: NSS and NSPR
BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten wrote: > Sorry for arriving late w/ this question... > > I'm guessing NSS & NSPR are needed for the linux build? Should they be > pulled in via DEPS instead of being directly in src/third_party? In the > current form it causes both mac and windows to have to add ~80M to their svn > trees that really isn't needed. > > TVL > > > > > --~--~-~--~~~---~--~~ 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: NSS and NSPR
On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten wrote: > Sorry for arriving late w/ this question... > > I'm guessing NSS & NSPR are needed for the linux build? Should they be > pulled in via DEPS instead of being directly in src/third_party? In the > current form it causes both mac and windows to have to add ~80M to their svn > trees that really isn't needed. By my calculations (du) it's only about 44M, but point taken. I can move it to deps once I figure out how. Michael --~--~-~--~~~---~--~~ 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: NSS and NSPR
There are actually both nss and nspr under base, but only a handful of files, not the whole trees. I plan to clean those up as appropriate, once this is all in and working. Michael On Wed, Feb 25, 2009 at 5:15 PM, Lei Zhang wrote: > > BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. > > On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten > wrote: >> Sorry for arriving late w/ this question... >> >> I'm guessing NSS & NSPR are needed for the linux build? Should they be >> pulled in via DEPS instead of being directly in src/third_party? In the >> current form it causes both mac and windows to have to add ~80M to their svn >> trees that really isn't needed. >> >> TVL >> >> >> > >> > > > > --~--~-~--~~~---~--~~ 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 async IO
On Wed, Feb 25, 2009 at 11:21 PM, Adam Langley wrote: > > On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌) > wrote: >> I talked to Darin and he told me that this needs work since it's >> impacting the page cycler times, so I figured I'd pick it up. You >> have a TODO there saying to figure out how to best do async IO. Did >> you ever figure this out? I talked to Darin briefly and decided that >> the simplest thing to do for now is simply to post tasks to the global >> WorkerPool. The global WorkerPool linux implementation looks pretty >> silly and needs work, but it's probably good enough for the page >> cycler. How does this approach sound to you? > > It's not clear if you were considering using POSIX async IO on Linux > or not. Just in case you were: don't. It mostly doesn't work. LWN has a nice article on the future of async IO on linux here btw. http://lwn.net/Articles/316806/ Unfortunately that's not that useful currently. --Craig --~--~-~--~~~---~--~~ 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: NSS and NSPR
On Wed, Feb 25, 2009 at 10:29 PM, Michael Moss wrote: > On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten > wrote: > > Sorry for arriving late w/ this question... > > > > I'm guessing NSS & NSPR are needed for the linux build? Should they be > > pulled in via DEPS instead of being directly in src/third_party? In the > > current form it causes both mac and windows to have to add ~80M to their > svn > > trees that really isn't needed. > > By my calculations (du) it's only about 44M, but point taken. I can > move it to deps once I figure out how. you on git? that would cut it in half, svn has the second copies w/in .svn. and thanks! TVL > > Michael > --~--~-~--~~~---~--~~ 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: NSS and NSPR
If we do that cleanup, then we will need NSS and NSPR on all platforms. -Darin On Wed, Feb 25, 2009 at 7:31 PM, Michael Moss wrote: > > There are actually both nss and nspr under base, but only a handful of > files, not the whole trees. I plan to clean those up as appropriate, > once this is all in and working. > > Michael > > On Wed, Feb 25, 2009 at 5:15 PM, Lei Zhang wrote: > > > > BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. > > > > On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten > > wrote: > >> Sorry for arriving late w/ this question... > >> > >> I'm guessing NSS & NSPR are needed for the linux build? Should they be > >> pulled in via DEPS instead of being directly in src/third_party? In the > >> current form it causes both mac and windows to have to add ~80M to their > svn > >> trees that really isn't needed. > >> > >> TVL > >> > >> > >> > > >> > > > > > > > > > > > --~--~-~--~~~---~--~~ 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: NSS and NSPR
Does that imply that it shouldn't move to deps? We can restrict it to Linux with deps_os now, and then make it apply to all platforms later, right? Or is it better to just leave it in trunk since it's already there? I'm fine with it either way, though it's less hassle for me to leave it where it is, and it means it's in my git tree instead of gclient/svn, but that's only a minor benefit since I don't expect to be changing it a lot once all these initial commits are in. Michael On Wed, Feb 25, 2009 at 8:08 PM, Darin Fisher wrote: > If we do that cleanup, then we will need NSS and NSPR on all platforms. > -Darin > > > On Wed, Feb 25, 2009 at 7:31 PM, Michael Moss wrote: >> >> There are actually both nss and nspr under base, but only a handful of >> files, not the whole trees. I plan to clean those up as appropriate, >> once this is all in and working. >> >> Michael >> >> On Wed, Feb 25, 2009 at 5:15 PM, Lei Zhang wrote: >> > >> > BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. >> > >> > On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten >> > wrote: >> >> Sorry for arriving late w/ this question... >> >> >> >> I'm guessing NSS & NSPR are needed for the linux build? Should they be >> >> pulled in via DEPS instead of being directly in src/third_party? In >> >> the >> >> current form it causes both mac and windows to have to add ~80M to >> >> their svn >> >> trees that really isn't needed. >> >> >> >> TVL >> >> >> >> >> >> > >> >> >> > >> > > >> > >> >> >> > > --~--~-~--~~~---~--~~ 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: NSS and NSPR
Hmm... I'm OK with having the small duplication of NSS/NSPR code for the foreseeable future. I think it is nice that base doesn't require all of NSS+NSPR. So, I guess that's a +1 in favor of moving it to deps_os as planned. -Darin On Wed, Feb 25, 2009 at 9:08 PM, Michael Moss wrote: > Does that imply that it shouldn't move to deps? We can restrict it to > Linux with deps_os now, and then make it apply to all platforms later, > right? Or is it better to just leave it in trunk since it's already > there? I'm fine with it either way, though it's less hassle for me to > leave it where it is, and it means it's in my git tree instead of > gclient/svn, but that's only a minor benefit since I don't expect to > be changing it a lot once all these initial commits are in. > > Michael > > On Wed, Feb 25, 2009 at 8:08 PM, Darin Fisher wrote: > > If we do that cleanup, then we will need NSS and NSPR on all platforms. > > -Darin > > > > > > On Wed, Feb 25, 2009 at 7:31 PM, Michael Moss > wrote: > >> > >> There are actually both nss and nspr under base, but only a handful of > >> files, not the whole trees. I plan to clean those up as appropriate, > >> once this is all in and working. > >> > >> Michael > >> > >> On Wed, Feb 25, 2009 at 5:15 PM, Lei Zhang > wrote: > >> > > >> > BTW, we have both src/third_party/nss/ and src/base/third_party/nss/. > >> > > >> > On Wed, Feb 25, 2009 at 5:04 PM, Thomas Van Lenten > >> > wrote: > >> >> Sorry for arriving late w/ this question... > >> >> > >> >> I'm guessing NSS & NSPR are needed for the linux build? Should they > be > >> >> pulled in via DEPS instead of being directly in src/third_party? In > >> >> the > >> >> current form it causes both mac and windows to have to add ~80M to > >> >> their svn > >> >> trees that really isn't needed. > >> >> > >> >> TVL > >> >> > >> >> > >> >> > > >> >> > >> > > >> > > > >> > > >> > >> > >> > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
