|
Sort Order:
Here is how I reproduced it: 1) I setup a site asking for a login/password in its Windows domain (WORKGROUP should not work). It may be possible to simply check the Windows Authentication in the IIS properties. The bug appears when using SeleniumRC on this site with IE: it won't be able to connect, and you'll get an authentication error. But if you change the buggy line, SeleniumRC will be able to run. Okay, here is how to setup the site with IIS (I'm using Vista, but XP or 2003 should be easier). Create a website from any folder. Check this site with IE, it should connect without asking a login/password. Now, try to run SeleniumRC on this site. Clearly the "first" bug (else clause with no if statement) isn't appropriate. Weirdly, it does appear to work OK. As for the "second" bug, I'm a little more nervous about that. I don't really remember why, but I intentionally returned undefined in that case in revision 1193: http://svn.openqa.org/fisheye/changelog/selenium-rc?cs=1193 "If no proxy was specified, do not add an 'else' clause... this shouldn't be necessary, but seems to fix a bug in IE6's PAC handling" I'd pushed off dealing with this bug in more detail because I didn't have time to investigate it in more detail; I'll make an effort to do so before 0.9.2 ships. What is the planned timeline for this bug fix (and for 0.9.2)? There is no schedule per se for any of the bugs or the release, but there is an ongoing effort to resolve all the gating problems and get release out the door. I think everyone agrees that getting the release out is very important, so the focus is on testing and solving problems (as opposed to adding functionality, etc.). If I have time, I may able to provide a Nant script to reproduce this bug. FYI, it's a lot easier for me to test basic authentication than it is for me to test Windows Authentication. Do you see this problem with Basic Authentication as well as Windows Authentication, or only on Windows Authentication? Frankly, I don't know. At my job, we are using a website administrator that requires Windows authentication, and that's how I can test it easily. "Fixed our long broken Firefox 2 browser launcher" was one of the points of the 0.9.2 release, yet I'm still seeing the corrupted proxy file mentioned above and therefore firefox can't be launched without using a *custom and a custom, working profile. Is this correct? The corrupted proxy file happens with Internet Explorer. The "long broken FF2 browser launcher" was totally busted in 0.9.0; FF2 would refuse to start altogether, no matter WHAT your proxy settings were. That was bug This bug, however, is still open in 0.9.2. Part of the reason for that was because I'd thought that the "malformed" PAC file still seemed to work OK; indeed it does in IE, but doesn't work correctly in FF. The basic auth problem is separate, though, and I'm not so sure about it. I'm going to break this "bug" up into two bugs and fix one of them (hanging else clause); the other one will have to wait until I can get a reproducible case; I can't seem to make it break on my machine, and we made a conscious decision not to return undefined for non-selenium URLs in revision 1193. If we can find a reproducible case (ideally one with basic authentication instead of Windows authentication?) I'll fix the "other" bug also. Re-filed part of this bug as |
|||||||||||||||||||||||||||||||||||
Bug
Open
Major
IE6 Windows authentication doesn't work because proxy.pac returns undefined
I bet we need to fix this, but without a test, we'll have no way if we're doing more harm than good. How can we test this?