User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2) Gecko/20100105 Firefox/3.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2) Gecko/20100105 Firefox/3.6 When using a proxy to connect to the network, and a proxy that asks for a password, the search bar becomes fairly unusable in FF 3.6 RC1 when first starting the browser. What happens : - open a fresh firefox showing a blank page (usefull inside a corporate network) - hit ctrl K or lick in search bar - start typing => first, after some keys, thet "proxy password" popup shows up. This is also true in previous versions of firefox (and also boring) - then enter the password (or accept, if password storage is on) - continue typing in the bar ... - the popup shows up again - and again, and again - until the search is properly launched, and resultst are displayed. From then on, everything is right, no more apssword asked. Reproducible: Always Steps to Reproduce: 1 use a proxy with password authentication 2 open a fresh firefox showing a blank page (usefull inside a corporate network) 3 hit ctrl K or lick in search bar 4 start typing 5 ... get annoyed ;-) Actual Results: multiple "proxy" authentification asked, in the middle of typing. Expected Results: Either back to "3.5" comportement : asks once and for all the password, Or better : when using proxy, only launch the search when "enter" (or click on search icon) is entered, in order to ask for the proxy password at the best moment.
You have auto-suggest enabled for this particular search engine? Are you using a master password?
I don't use master password. I must admit I didn't know how to enable/disable the auto-suggest ability. It is enabled. (never thought about disabling it either) I just tried this : now works just fine for me. (some users would miss the suggestion ability) Still : there's a minor bug compared to 3.5, regarding the fact that the proxy password is asked multiple times, when suggestions is "on".
Justin, you know why we are asking multiple times for the proxy password when having auto-suggests enabled for the search bar? I wonder which is the right component for this particular issue. I can't confirm it because I don't have a proxy server with authentication available. But I wonder if there should be already a bug filed on it - cannot find one at the moment.
I have the same problem ... FF 3.6 RC1. Search toolbar, proxy with authentication. After typing one letter, password dialog occur. After typing second letter, dialog occur. In FF 3.5 only first dialog occur, then all was OK.
Search suggestions for the string entered as you type are pulled from the network, so if the code is just trying to cancel the previous request and open a new one (ie, as if the network was just slow), then it could very well be triggering a prompt for each new request. Though that almost sounds like a Necko bug; it shouldn't be kicking off a new auth prompt when there's already one outstanding. Hard to say, someone will need to debug exactly what's going on.
If someone find time please check the following page how to create a HTTP log: https://developer.mozilla.org/en/HTTP_Logging.
Created attachment 425196 [details] HTTP log requested. sorry for the delay. Log obtained with latest nightly from Minefield : - start firefox - type some letters in search bar (with show suggestion On) - validate the proxy user/password - type some letters again -> popup appears, validate again - ... 3 times. Then close the browser.
Created attachment 425220 [details] HTTP log (from squalou) Lets attach the log as plain text.
Attachment #425196 - Attachment is obsolete: true
Created attachment 425394 [details] http log FF3.6 WindowsXP In the search bar the letter "a" was pressed 3 times. After 4 login's all work fine.
squalou, demidov, thanks for your logs. However, could you please also add "timestamp," to the NSPR_LOG_MODULES variable? Personally, I cannot reproduce this bug locally. It's visible in the logs that a request to google suggestion server is made, in response we get 407, ask for user credentials asynchronously and after that the current request is canceled as another letter(s) has(ve) been typed. Looks like from some reason the coalescing code is not working when a waiting request is canceled...
This also happens on Firefox 3.6.10 on Ubuntu 10.10 Also, Bug 369180 seems similar.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 369180
You need to log in before you can comment on or make changes to this bug.