On Mon, Dec 21, 2009 at 10:10 AM, Drew Wilson <atwil...@chromium.org> wrote:
> I don't think we can do a browser_test btw, since I believe browser_tests > run in one process, precluding the testing of workers. > > No, a browser_test just runs the browser process and test code in the same process. The resultant executable still spawns child processes. > As for making NeedsAuth() detect the current state of the login prompt, > that'd be cool, if possible. I don't see any way to do this other than the > current approach (registering an observer for a LoginNotification), though, > and I'm not certain what the implications are of having the automation > observers continue to be registered even after the initial notification is > complete. > > So it seems like the safest approach is to roll my own observer for my > test. > > I admit I haven't studied the NeedsAuth implementation in detail, but it seems to me that when a tab is showing a login prompt, a flag could be set that the automation system could read. This seems like the right approach to me. -Darin > -atw > > > On Sat, Dec 19, 2009 at 11:06 AM, Darin Fisher <da...@chromium.org> wrote: > >> It seems like TabProxy::NeedsAuth could (should) be modified to just >> return true if the corresponding TabContents is showing a login prompt. >> >> -Darin >> >> >> On Fri, Dec 18, 2009 at 5:25 PM, Drew Wilson <atwil...@chromium.org>wrote: >> >>> Following up on this - it doesn't look like there's any way to detect if >>> a page displays an HTTP Auth dialog for an action taken after the page is >>> loaded (basically TabProxy::NeedsAuth() only returns true if an auth dialog >>> is displayed in response to a navigation request like NavigateToURL or >>> GoBack. Since workers perform their loads asynchronously, this means that it >>> doesn't appear possible to check if an auth dialog is displayed via the >>> automation framework (a quick scan of the code shows that AutomationProvider >>> only listens for the appropriate login events while navigating). >>> >>> Is there another way to do it? Perhaps ui_test should register its own >>> NotificationObserver with the AutomationProvider framework? Or is that a >>> bogus approach? >>> >>> -atw >>> >>> >>> On Thu, Dec 17, 2009 at 10:56 AM, Drew Wilson <atwil...@chromium.org>wrote: >>> >>>> Thanks - turns out that just removing the #ifdef from the file did the >>>> trick. Apparently the automation folks already added support for this >>>> behind >>>> the scenes. >>>> >>>> I'll submit a patch to turn these tests on. >>>> >>>> -atw >>>> >>>> >>>> On Wed, Dec 16, 2009 at 10:40 PM, Paweł Hajdan, Jr. < >>>> phajdan...@chromium.org> wrote: >>>> >>>>> On Thu, Dec 17, 2009 at 03:22, Drew Wilson <atwil...@chromium.org> >>>>> wrote: >>>>> > The closest thing I found to what I want is the LoginPromptTest >>>>> ui_tests, >>>>> > but these seem only to work on Windows because the automation >>>>> framework >>>>> > doesn't yet support NotificationType::AUTH_NEEDED on anything but >>>>> windows: >>>>> > >>>>> ERROR:/Volumes/source/chrome.git/src/chrome/browser/automation/automation_provider_observers.cc(192)] >>>>> > Not implemented reached in virtual void >>>>> > NavigationNotificationObserver::Observe(NotificationType, const >>>>> > NotificationSource&, const NotificationDetails&) >>>>> > I could just enable this test only on Windows, but I'd rather have it >>>>> > working on other platforms as I don't have a good windows dev system >>>>> - >>>>> > anyone know how much work it would be for me to implement the missing >>>>> > functionality in the automation framework? >>>>> >>>>> It may be possible to just remove the #ifdef from the file. If it >>>>> compiles, it should be working. >>>>> >>>>> > I don't think there's any other way to test the http auth >>>>> functionality without it. >>>>> >>>>> Just a note: you wrote "the closest thing". If the LoginPromptTest >>>>> automation kind of doesn't fit, please consider developing a browser >>>>> test first (you need to do less plumbing), and then, as you identify >>>>> automation needs, "port" it to the automation framework. It has worked >>>>> for me in the past. >>>>> >>>> >>>> >>> -- >>> 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