[chromium-dev] Re: Mac ui_tests blows away from fraction of your profile.
Also, unless you do something like this, it ends up being difficult for developers to dogfood the product, or if they do try to dogfood the product, then they are strongly inscentivized not to run the ui_tests. Neither option is good. -Darin On Wed, Apr 8, 2009 at 11:21 AM, Darin Fisher da...@chromium.org wrote: Maybe this is well known, but what we did to avoid this problem on Windows is to leverage the --user-data-dir command line switch to force the chrome instance launched by the ui_tests to use a dedicated user data directory. We toss that directory prior to each test case IIRC. -Darin On Wed, Apr 8, 2009 at 11:10 AM, Scott Hess sh...@chromium.org wrote: I posted this on the irc channel yesterday, I know at least Peter noticed, but John suggested something more overt. When you run ui_tests on Mac, you will blow away some fraction of your Chromium.app profile. Things like history and bookmarks. This is a known issue, but may not be a known consequence. If anyone wants to circle back and fix profiles, that would be wonderous. I was thinking of looking at it myself, but am instead trying to figure out where my omnibox stuff is going wrong. It occurs to me that if you ran ui_tests while running Chromium.app, or two ui_tests, you may also see strange and wonderful results. -scott --~--~-~--~~~---~--~~ 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 ui_tests blows away from fraction of your profile.
Note that a NOTIMPLEMENTED() prints when the code runs that tries to abort when Chromium is already running. One thing that I think has helped us on Linux is reducing the NOTIMPLEMENTED prints to the bare minimum -- for stuff that we know is broken (like the star button on the toolbar) having it print out a warning on every page load masks important printouts like the one above. I have converted many such printouts into bugs instead (it's obvious the star button doesn't* work if you click on it). If you do the same, please be sure to tag it with the relevant OS labels if it affects more than just Mac. :) * I think ours actually does work now; just an example. On Wed, Apr 8, 2009 at 11:23 AM, Scott Hess sh...@chromium.org wrote: That would be my expectation, too. Like I said, I think this is a known issue (the Mac port's profile stuff is sort of wired together). -scott On Wed, Apr 8, 2009 at 11:21 AM, Darin Fisher da...@chromium.org wrote: Maybe this is well known, but what we did to avoid this problem on Windows is to leverage the --user-data-dir command line switch to force the chrome instance launched by the ui_tests to use a dedicated user data directory. We toss that directory prior to each test case IIRC. -Darin On Wed, Apr 8, 2009 at 11:10 AM, Scott Hess sh...@chromium.org wrote: I posted this on the irc channel yesterday, I know at least Peter noticed, but John suggested something more overt. When you run ui_tests on Mac, you will blow away some fraction of your Chromium.app profile. Things like history and bookmarks. This is a known issue, but may not be a known consequence. If anyone wants to circle back and fix profiles, that would be wonderous. I was thinking of looking at it myself, but am instead trying to figure out where my omnibox stuff is going wrong. It occurs to me that if you ran ui_tests while running Chromium.app, or two ui_tests, you may also see strange and wonderful results. -scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] MStone:Mac MStone:Linux
It helps to bucket Issues into milestones. So far we have had numbered milestones like 2 and 2.1. However, I think it makes sense to have a MStone:Mac and an MStone:Linux as well. I am moving Mac and Linux issues into these. Basically if an issue it in these buckets we would expect it to be resolved before we release to the general public. If the Issue should go out in a specific stable release like 2.0 or 2.1 then we should move them into that mstone. Also, MStone:X is the someday in the future bucket. If I put stuff in there (especially feature requests) that means I did not just reject them outright and they should be considered fodder for discussion. Jon --~--~-~--~~~---~--~~ 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 ui_tests blows away from fraction of your profile.
I can see how that's happening in pref_service_uitest.cc and memory_test.cc, but AFAICT I don't see how it's being done generally for ui_tests test cases. Perhaps it's that --user-data-dir should be passed to ui_tests itself, which means if you run ui_tests without that flag, it will still use your default profile. Or maybe I misunderstand entirely. BTW, I was just stupid when I thought that Mac was broken because of being hacked together. Some of the profile setup is certainly hacked together, but as far as I can tell, it does the right thing for --user-data-dir (though having it fall back to the default dir when the provided one doesn't exist threw me for awhile, that seems unexpected). -scott On Wed, Apr 8, 2009 at 11:23 AM, Darin Fisher da...@chromium.org wrote: Also, unless you do something like this, it ends up being difficult for developers to dogfood the product, or if they do try to dogfood the product, then they are strongly inscentivized not to run the ui_tests. Neither option is good. -Darin On Wed, Apr 8, 2009 at 11:21 AM, Darin Fisher da...@chromium.org wrote: Maybe this is well known, but what we did to avoid this problem on Windows is to leverage the --user-data-dir command line switch to force the chrome instance launched by the ui_tests to use a dedicated user data directory. We toss that directory prior to each test case IIRC. -Darin On Wed, Apr 8, 2009 at 11:10 AM, Scott Hess sh...@chromium.org wrote: I posted this on the irc channel yesterday, I know at least Peter noticed, but John suggested something more overt. When you run ui_tests on Mac, you will blow away some fraction of your Chromium.app profile. Things like history and bookmarks. This is a known issue, but may not be a known consequence. If anyone wants to circle back and fix profiles, that would be wonderous. I was thinking of looking at it myself, but am instead trying to figure out where my omnibox stuff is going wrong. It occurs to me that if you ran ui_tests while running Chromium.app, or two ui_tests, you may also see strange and wonderful results. -scott --~--~-~--~~~---~--~~ 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] Fwd: [chromium-discuss] Bookmarks - Alphabetical
Another thing you should be able to do with an extension. Note that our current proposals for a bookmark API don't have an index property (within the parent). We need to add that. - a -- Forwarded message -- From: mertoman merto...@gmail.com Date: Tue, Apr 7, 2009 at 8:03 AM Subject: [chromium-discuss] Bookmarks - Alphabetical To: Chromium-discuss chromium-disc...@googlegroups.com Hello, Is there an option to auto-sort bookmarks alphabetically or at least put the titles in alpha order when they are saved? Thanks? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] [Extensions] New API specs: bookmarks, history, downloads
Hi all, I fleshed out a few more APIs. I've put them in separate documents since the API pattern doc was getting a bit long. Below are some notes, feedback appreciated. In particular, I'd love feedback from Scott on history and from Paul on downloads. -Nick Bookmarkshttp://dev.chromium.org/developers/design-documents/extensions/api-pattern/bookmarks-api - Do we want to distinguish removeBookmark from removeFolder, or is that unnecessary? - Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? - In BookmarkItem, should fields that don't apply be null or simply not present? - In BookmarksQuery, do the root and bookmarksBar booleans make sense? - How does returning the children recursively work with updates? Can you update all these items at the same time? Downloadshttp://dev.chromium.org/developers/design-documents/extensions/api-pattern/downloads-api - Should getDownloads take a DownloadsQuery object? The current downloads page includes search. - What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? - How should we deal with progress updates? It seems like overkill to trigger an event for each change in percentage, but on the other hand extensions should be able to track this. Historyhttp://dev.chromium.org/developers/design-documents/extensions/api-pattern/history-api - I'm assuming HistoryItems are immutable, so there is no update. - The internal history structure is split between visits and urls. Visits don't contain the actual url, so we have to fetch the url object either way. I therefore merged the visit and url objects into one. Is this reasonable? - There are a number of stats (timeSpent, fromId, totalVisitCount, totalTypedCount). Do we want to expose those for v1? --~--~-~--~~~---~--~~ 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] New API specs: bookmarks, history, downloads
For downloads, do we provide a way for people to download a file without showing a UI? It'd be interesting to do that and give people the ability to register for callbacks. That might be useful for custom download manager extensions... what I mean by that are extensions that fetch every link on the page, every bit of media etc. They sometimes provide their own UI better suited to mass file downloading than our shelf. -Ben On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum nickb...@chromium.org wrote: Hi all, I fleshed out a few more APIs. I've put them in separate documents since the API pattern doc was getting a bit long. Below are some notes, feedback appreciated. In particular, I'd love feedback from Scott on history and from Paul on downloads. -Nick Bookmarks Do we want to distinguish removeBookmark from removeFolder, or is that unnecessary? Should changes to the contents of a folder trigger eventbookmarkupdated for that folder? How about the folders above it? In BookmarkItem, should fields that don't apply be null or simply not present? In BookmarksQuery, do the root and bookmarksBar booleans make sense? How does returning the children recursively work with updates? Can you update all these items at the same time? Downloads Should getDownloads take a DownloadsQuery object? The current downloads page includes search. What kind of events does clearAllDownloads trigger? do we need a separate event for this? Do we even need this in the first place? How should we deal with progress updates? It seems like overkill to trigger an event for each change in percentage, but on the other hand extensions should be able to track this. History I'm assuming HistoryItems are immutable, so there is no update. The internal history structure is split between visits and urls. Visits don't contain the actual url, so we have to fetch the url object either way. I therefore merged the visit and url objects into one. Is this reasonable? There are a number of stats (timeSpent, fromId, totalVisitCount, totalTypedCount). Do we want to expose those for v1? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
