[chromium-dev] buildbot failure in Chromium on Modules Mac, revision 33073
Automatically closing tree for net_unittests on Modules Mac http://build.chromium.org/buildbot/waterfall/builders/Modules%20Mac/builds/17388 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20Mac --= Automatically closing tree for net_unittests on Modules Mac =-- Revision: 33073 Blame list: mbel...@google.com Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] PrefsService shared with OffTheRecordProfile
Hi, I was investigating how notifications should work in incognito mode, and came across the fact that the PrefsService for the incognito profile is the same one as the real profile. In some ways I guess that makes sense, since it's state about *how* the user uses the browser, not what the user is doing. But it does lead to some things that seem odd, like if you whitelist an origin for popups while in incognito mode, that origin is whitelisted permanently even when you go back to normal mode. And in my case, it behaves likewise for notifications, since those permissions are stored in the PrefsService. Is that how we want it to work? -John -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 11:38 AM, John Gregg john...@google.com wrote: Hi, I was investigating how notifications should work in incognito mode, and came across the fact that the PrefsService for the incognito profile is the same one as the real profile. In some ways I guess that makes sense, since it's state about how the user uses the browser, not what the user is doing. But it does lead to some things that seem odd, like if you whitelist an origin for popups while in incognito mode, that origin is whitelisted permanently even when you go back to normal mode. And in my case, it behaves likewise for notifications, since those permissions are stored in the PrefsService. Is that how we want it to work? Nope. That sounds like a bug. We should never write URLs or hosts the user visits while in incognito to disk. Adam -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 12:14 PM, Adam Barth aba...@chromium.org wrote: On Wed, Nov 25, 2009 at 11:38 AM, John Gregg john...@google.com wrote: if you whitelist an origin for popups while in incognito mode, that origin is whitelisted permanently even when you go back to normal mode. And in my case, it behaves likewise for notifications, since those permissions are stored in the PrefsService. Is that how we want it to work? Nope. That sounds like a bug. We should never write URLs or hosts the user visits while in incognito to disk. This is the sort of thing for which Profile::ServiceAccessType was invented. Ideally, things like recording whitelisted popup hosts should request IMPLICIT_ACCESS, which should result in no read happening. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 12:26 PM, Peter Kasting pkast...@google.com wrote: On Wed, Nov 25, 2009 at 12:14 PM, Adam Barth aba...@chromium.org wrote: On Wed, Nov 25, 2009 at 11:38 AM, John Gregg john...@google.com wrote: if you whitelist an origin for popups while in incognito mode, that origin is whitelisted permanently even when you go back to normal mode. And in my case, it behaves likewise for notifications, since those permissions are stored in the PrefsService. Is that how we want it to work? Nope. That sounds like a bug. We should never write URLs or hosts the user visits while in incognito to disk. This is the sort of thing for which Profile::ServiceAccessType was invented. Ideally, things like recording whitelisted popup hosts should request IMPLICIT_ACCESS, which should result in no read happening. From reading the code, I'm not sure that's consistent. Adding a whitelisted host for popups is a result of a user action (the user choosing always allow from the blocked popup container), so according to the code comments, that would be an explicit access. It's kind of a gray area: it's like adding a bookmark in terms of user-initiation, but it also affects web browsing. -John -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] buildbot failure in Chromium on Webkit Mac Builder, revision 33109
Automatically closing tree for compile on Webkit Mac Builder http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac%20Builder/builds/10287 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Mac%20Builder --= Automatically closing tree for compile on Webkit Mac Builder =-- Revision: 33108, 33109 Blame list: js...@chromium.org,pkast...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 12:49 PM, John Gregg john...@google.com wrote: On Wed, Nov 25, 2009 at 12:26 PM, Peter Kasting pkast...@google.comwrote: This is the sort of thing for which Profile::ServiceAccessType was invented. Ideally, things like recording whitelisted popup hosts should request IMPLICIT_ACCESS, which should result in no read happening. From reading the code, I'm not sure that's consistent. Adding a whitelisted host for popups is a result of a user action (the user choosing always allow from the blocked popup container), so according to the code comments, that would be an explicit access. It's kind of a gray area: it's like adding a bookmark in terms of user-initiation, but it also affects web browsing. Hmm. On the one hand, we persist things like created bookmarks and downloaded files. On the other hand, we don't preserve changes due to other user actions like clicking a link. It's not obvious to me what the best example is. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Flaky SessionHistoryTest.LocationReplace, fun with investigating it
On Wed, Nov 25, 2009 at 20:57, Tim Steele timste...@google.com wrote: It seems like the test should wait for the title to update, and not the navigation to finish. I'm pretty sure it's not a waiting problem. I followed what the test does manually, and I could still reproduce the issue. I also checked with debugger, where things are slowed down, and it was still there. The renderer just doesn't send the UpdateTitle message at all. Today I followed the code flow very carefully, just attached to the browser under test in a debugger, set breakpoints in title-related functions down to WebCore. It's quite possible that it's some part of WebCore logic that's involved (like not telling the glue code about the title). It's mysterious though why the test generally passes on the buildbot (but not on trybot). Would it be a good idea for the browser to query the renderer for title before it declares navigation as finished? Or maybe the renderer could do so internally? What do you think? -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Compiler version used for official Windows builds?
Hi, I couldn't find this info anywhere on the dev site (maybe I just wasn't looking hard enough), but I'm curious as to what version of Visual C++ you're using for the official Chrome builds. We're still using VC2005 for our Firefox builds, and I'm seeing some weird behavior with regards to Breakpad symbols ( https://bugzilla.mozilla.org/show_bug.cgi?id=520651 ) and I was curious if you were using the same compiler, and if so if you'd seen similar problems. I've been trying to do a build with VC2008, but a PGO build consistently runs out of memory on my machine. VC2010b2 works fine, and doesn't seem to exhibit the same problems, but of course it's not out of beta yet. Thanks for any info, -Ted -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] adding packages
HI! I'm adding packages to my local repo. Since I've read the doc tutorial : http://sites.google.com/a/chromium.org/dev/chromium-os/how-tos-and-troubleshooting/add-a-new-package/package-management I'd like to suggest a modification (no WIKI ?) to the paragraph Modify the package list for the chroot dev environment by diff'ing the package repo it could be added : quote : src/scripts/list_installed_packages.sh /tmp/newpacks diff -u ~/trunk/src/package_repo/repo_list_dev.txt /tmp/newpacks repo_list_dev.diff make a backup : cp src/package_repo/repo_list_dev.txt src/package_repo/ repo_list_dev.old patch the repo list : patch -p0 src/package_repo/repo_list_dev.txt repo_list_dev.diff as made to patch the repo lists. thank you ! -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] adding packages
I think you've accidentally used the wrong mailing list. Please see http://www.chromium.org/chromium-os/discussion-groups On Tue, Nov 24, 2009 at 3:45 PM, b23prodtm tianab.rak...@gmail.com wrote: HI! I'm adding packages to my local repo. Since I've read the doc tutorial : http://sites.google.com/a/chromium.org/dev/chromium-os/how-tos-and-troubleshooting/add-a-new-package/package-management I'd like to suggest a modification (no WIKI ?) to the paragraph Modify the package list for the chroot dev environment by diff'ing the package repo it could be added : quote : src/scripts/list_installed_packages.sh /tmp/newpacks diff -u ~/trunk/src/package_repo/repo_list_dev.txt /tmp/newpacks repo_list_dev.diff make a backup : cp src/package_repo/repo_list_dev.txt src/package_repo/ repo_list_dev.old patch the repo list : patch -p0 src/package_repo/repo_list_dev.txt repo_list_dev.diff as made to patch the repo lists. thank you ! -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Flaky SessionHistoryTest.LocationReplace, fun with investigating it
On Wed, Nov 25, 2009 at 22:33, Tim Steele timste...@google.com wrote: There are only a couple places where WebCore tells the client that the title changed (looks like 3, search FrameLoader for dispatchDidReceiveTitle). There are conditionals wrapping each such call and also, in some cases, wrapping the methods that call the methods in those 3 cases. In one of *those *cases, in DocumentLoader::setTitle, I see this code: if (!trimmed.isEmpty() m_pageTitle != trimmed) { frameLoader()-willChangeTitle(this); m_pageTitle = trimmed; frameLoader()-didChangeTitle(this); } My (possibly flawed) debugging shows that when the test fails, we're not even touching that code path. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Compiler version used for official Windows builds?
On Wed, Nov 25, 2009 at 4:22 AM, Ted Mielczarek ted.mielcza...@gmail.com wrote: Hi, I couldn't find this info anywhere on the dev site (maybe I just wasn't looking hard enough), but I'm curious as to what version of Visual C++ you're using for the official Chrome builds. It's Visual C++ 2005. (The official build does whole program optimization and must be done on a 64-bit Windows machine with lots of memory.) I don't know if we'd seen similar problems with Breakpad symbols. Wan-Teh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Compiler version used for official Windows builds?
On Wed, Nov 25, 2009 at 7:42 PM, Wan-Teh Chang w...@google.com wrote: On Wed, Nov 25, 2009 at 4:22 AM, Ted Mielczarek ted.mielcza...@gmail.com wrote: Hi, I couldn't find this info anywhere on the dev site (maybe I just wasn't looking hard enough), but I'm curious as to what version of Visual C++ you're using for the official Chrome builds. It's Visual C++ 2005. (The official build does whole program optimization and must be done on a 64-bit Windows machine with lots of memory.) Lots being relative. The linker just requires the full 4 gigs of address space. Simply using /3GB on a 32 bits OS isn't sufficient. I don't know if we'd seen similar problems with Breakpad symbols. Wan-Teh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] TestShell target
Hi, Is there a way to build a TestShell target for chromium on linux? On MacOS, there is a TestShell project, I wonder if there is a TestShell target for building it on linux? Thank you. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] TestShell target
(from the right address this time) make test_shell ? On Wed, Nov 25, 2009 at 5:21 PM, n179911 n179...@gmail.com wrote: Hi, Is there a way to build a TestShell target for chromium on linux? On MacOS, there is a TestShell project, I wonder if there is a TestShell target for building it on linux? Thank you. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] PrefsService shared with OffTheRecordProfile
On Wed, Nov 25, 2009 at 11:38 AM, John Gregg john...@google.com wrote: if you whitelist an origin for popups while in incognito mode, that origin is whitelisted permanently even when you go back to normal mode. On further reflection I'm convinced persisting these changes is wrong. I have now posted a patch to fix this at http://codereview.chromium.org/434109. I have similarly updated my change to add per-host remembering of zoom levels ( http://codereview.chromium.org/437077 ) to also avoid persisting changes while off the record. 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] buildbot failure in Chromium on Modules XP (dbg), revision 33182
Automatically closing tree for net_unittests on Modules XP (dbg) http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/19681 http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29 --= Automatically closing tree for net_unittests on Modules XP (dbg) =-- Revision: 33182 Blame list: u...@chromium.org Buildbot waterfall: http://build.chromium.org/ -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev