I promise I'm not back to my antics of suggesting we stick to the "one profile per process" model, but I hit a little snag trying to write a test where I want to create a different profile. I'm wondering what I'm doing wrong / how this was originally intended to work in the "multiple profile per process" world... willing to fix things if need be. It's an InProcessBrowserTest, so I've got a standard Browser object already up and running with the Default profile for the test user data directory. I then use ProfileManager to CreateProfile; so far so good. As soon as you try and do anything with this profile that touches HistoryService (for example), we choke because the lazy-initializer for the second profile's HistoryService wants to create a ChromeThread::HISTORY, which already exists. This is something we don't hit with incognito because it reuses the same service, but I think a long, long time ago when we had some notion of true multi-profile support this must have worked. I assume the original intent was to re-use the same history thread for multiple profiles. Not sure how to make that work at the moment, ChromeThread is pretty tight-lipped from an API standpoint. Naively it feels like we could just check-if-exists-and-reuse-else-create in this case. Is that sane? Tim
--~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
