369180 - Proxy Authentication required while typing Search String

Status: RESOLVED FIXED

(Firefox :: Search, defect)

Description

[Prashant Mahajan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

Steps:
1. Start a new instance of Firefox.
2. Enter any search String.

Problem: The Proxy Authentication dialog comes in between (Before the user could click the Search button)and the search string is  entered in the User name, since the user like me is watching the keyboard.

Reproducible: Always

Steps to Reproduce:
Steps:
1. Start a new instance of Firefox.
2. Enter any search String.

Problem: The Proxy Authentication dialog comes in between (Before the user could click the Search button)and the search string is  entered in the User name, since the user like me is watching the keyboard.
Actual Results:  
Problem: The Proxy Authentication dialog comes in between (Before the user could click the Search button)and the search string is  entered in the User name, since the user like me is watching the keyboard.

Expected Results:  
The Proxy authentication should have come after the user had written the search query.

Comment 1

[Manfred H.]

We have exactly the same Problem in Corporate. But not always. I cant describe what to do, to enforce this behavior. But ALWAYS Firefox need to type username and password, by starting it, for ALL Tabs which should be opened behind proxy (squid). The only workaround to "solve" the problem is, to start Firefox with only 1 Tab. And THEN the problem with the search string doesnt appear! Apart from that its very hard going to start FF with many Tabs using a Proxy!

Manfred

Comment 2

[RNicoletto]

Confirmed on Firefox 3.0.11 - Firefox 3.5.1 and Minefield/3.6a1pre (on Windows
XP Pro SP3).

Comment 5

[Axel]

Confirmed in
Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

Comment 6

[Axel]

I should add that I would expect Firefox to show the proxy authentication dialog only once, at the beginning, when entering the first letter of the search string.

FF actually opens a connection to the search engine when typing the search query, so a proxy authentication is required here. I believe the error is that it doesn't cache the authentication information given there.

Workaround: Open any page in FF and authenticate accessing this web page. Then the authentication information given there is stored in the current FF session. After that you can enter a search term as usual. FF will use the stored authentication information to access the search engine then.

Comment 7

[Pascal Havelange]

Confirmed also in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6 (.NET CLR 3.5.30729)

A complementary note about this issue:

It seems that actually firefox does not cache the credentials at all when the proxy authentication box is triggered from the Search bar.
Indeed, if you were not yet authenticated and you type something is the ssearch bar, you will be prompted for your username & pwd; if after authentifying yourself, you add other characters to the search string, the authentication box will be prompted again.
This until you open any webpage that requires proxy authentication and authenticate yourself (in which case credentials are saved and available for the search bar too)

Comment 9

[Ben Bucksch (:BenB)]

Bug 538953 comment 7 with attachment 425220 [details] has an HTTP log where the prompt shows for keypresses, 3 times, even though the password is given each time.
Attachment 425394 [details] has another, saying "In the search bar the letter "a" was pressed 3 times. After 4 login's all work fine."

Comment 12

[Franz Pirstinger]

We sniffed network-traffic on a Client and saw that there was no login information beeing sent to the TMG-Proxy between typing the searchstring. Obviously this is the reason for not beeing authenticated with the TMG.

Firefox 4.0.1
Forefront TMG 2010

Comment 13

[Ian]

This bug still exists in FF 10.01 - in fact it's been there ever since the search bar first appeared in Firefox. It happens on both Windows & Linux platforms (I've never tried osx) and is extremely annoying and confusing for users who don't understand what is happening as it repeatedly prompts the user to login as they try to type in a search term.

Comment 14

[Marco]

This bug still exists in FF 11.0 - fully agree to Ian

Comment 15

[kir.smirnov]

Confirmed in FF 18.0
SQUID 2.7.9 with NTLM authorization.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

Is anyone CCed here still able to reproduce this problem? I have a potential patch to fix it, but I can't easily reproduce the problem to fix it. If anyone is willing to help test a patched build, please let me know.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

Attachment: potential patch

Comment 19

[Emily Bowman]

I've moved to using a transparent NTLM proxy server, but our basic authentication server is still alive, and I can easily test with it. What I can't do right now is build Firefox, unfortunately.

Comment 20

[Ben Bucksch (:BenB)]

Gavin, might this be fixed by bug 521467, maybe this is why you can't reproduce?

Comment 21

[:Gavin Sharp [email: [e-mail]]]

Joshua: that's great - assuming you can still reproduce the problem in a build of Firefox Nightly (https://nightly.mozilla.org/), I can link you to a build with my patch that you can compare it to. Which platform do you need?

Ben: I haven't reproduced locally because I don't have a proxy configured.

Comment 22

[squalou.jenkins]

I was experiencing this bug a long time ago,
disabled the "show suggestion" at the time, never reactivated it since.

I just reactivated it : it seems definitively FIXED ;-)

Comment 23

[alavaliant]

Testing on Linux using ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/firefox-21.0a1.en-US.linux-x86_64.tar.bz2   I can still reproduce the problem;   start up firefox,  start typing and proxy auth dialog comes up after the first character,  fill in login details and type next character and prompt comes up again etc    

I'm happy to test Gavin's patch,   Gavin if you have a Linux 64bit build I could try I can give you an answer pretty quick.   (I technically can build a firefox install with the patch applied but I've not done it for a bit so it will probably take me several days to work through all the steps again)

Comment 24

[:Gavin Sharp [email: [e-mail]]]

alavaliant: thanks for volunteering! Sorry I didn't notice your comment until now.

I've pushed a patch to try that works for me in the non-proxy case:
https://tbpl.mozilla.org/?tree=Try&rev=fe6337b1609c

The build is available here:
https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-fe6337b1609c/try-linux64/

Let me know if you can reproduce the problem you reproduced earlier in that build.

Comment 25

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

This patch blocks authentication prompts from appearing by adding an nsIAuthPromptProvider implementation to the search suggest channel's notificationCallbacks. This nsIAuthPromptProvider returns a no-op nsIAuthPrompt2 implementation.

The idea is to effectively make nsHttpChannelAuthProvider::PromptForIdentity a no-op. I can't just return null for nsIAuthPrompt2, because then it would fall back to the load group's callbacks which eventually finds the implementation in nsDocShell, I believe.

It would be nice if there was a simpler way to do this, with a flag on the channel or something.

Comment 26

[Ben Bucksch (:BenB)]

Comment on attachment 731257 [details] [diff] [review]
patch

+    this._request.channel.notificationCallbacks = new AuthPromptOverride();

I'm not sure, but wouldn't this potentially suppress SSL warnings, too?

+    return {
+      promptAuth: function () {},
+      asyncPromptAuth: function () {}
+    };

This is supposed to be an nsIAuthPrompt2, so doesn't this need a QI function at least? I assume you tested it and it works as-is, but I thought that it was supposed to implement QI.

Comment 27

[:Gavin Sharp [email: [e-mail]]]

(In reply to Ben Bucksch (:BenB) from comment #26)
> I'm not sure, but wouldn't this potentially suppress SSL warnings, too?

No, we don't have SSL-related prompts anymore (bug 799009).

> This is supposed to be an nsIAuthPrompt2, so doesn't this need a QI function
> at least?

No, XPConnect handles plain old JS objects just fine.

Comment 28

[alavaliant]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #24)
> alavaliant: thanks for volunteering! Sorry I didn't notice your comment
> until now.
> 
> I've pushed a patch to try that works for me in the non-proxy case:
> https://tbpl.mozilla.org/?tree=Try&rev=fe6337b1609c
> 
> The build is available here:
> https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/gsharp@mozilla.
> com-fe6337b1609c/try-linux64/
> 
> Let me know if you can reproduce the problem you reproduced earlier in that
> build.

Thanks for that (I'd been having very limited luck trying to make my own build,   for some reason from multiple computers/different isps my cloning of the source repo was timing out or erroring our part way through the checkout and I hadn't found any tarballs of the source modern enough to apply the patch to so).

I've tested and was unable to reproduce the problem using your supplied build;     when freshly started up typing in the search dialog box didn't bring up any proxy auth boxes,   the first one I got was when actually submitting the search result (to load the search page),  then no further prompts to login to the proxy server showed up when using the search box further  (but search suggestions started working for further searches  after the proxy login was done via the first webpage load).     So if I'm understanding the intention of the patch it appears to be working perfectly.

Comment 29

[Honza Bambas (:mayhemer)]

Gavin, I think you are on a good way here.  However, your implementation of nsIAuthPrompt2 has to be finished.  E.g. asyncPromptAuth has to call the callback with onAuthCancelled immediately, otherwise the channel hangs believing there is an auth prompt user has to accept or cancel.  onAuthCancelled is called when the dialog is canceled to continue the code path.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

Thanks, a lot for the testing, alavaliant!

I'll submit an updated patch that addresses Honza's feedback.

Comment 31

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

Comment 32

[Honza Bambas (:mayhemer)]

Comment on attachment 732386 [details] [diff] [review]
patch

Review of attachment 732386 [details] [diff] [review]:
-----------------------------------------------------------------

r=honzab

::: toolkit/components/search/nsSearchSuggestions.js
@@ +536,5 @@
> +      },
> +      asyncPromptAuth: function () {
> +        throw Cr.NS_ERROR_NOT_IMPLEMENTED;
> +      }
> +    };

If this works w/o QI then we are OK.

Comment 33

[:Gavin Sharp [email: [e-mail]]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/aaae69fde562

Comment 34

[:Gavin Sharp [email: [e-mail]]]

This got backed out, here's a try push:
https://tbpl.mozilla.org/?tree=Try&rev=4369c931e9c6

Comment 35

[:Gavin Sharp [email: [e-mail]]]

Re-landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/448765c6360b

Comment 36

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/448765c6360b