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.
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. -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
