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

Reply via email to