1534311 - Allow auth prompt for "save link as" and just stop the timer that would cancel the initial request

Status: NEW

(Toolkit :: Downloads API, enhancement, P3)

Description

[:Gijs (he/him)]

See bug 1529901.

In https://searchfox.org/mozilla-central/rev/2f1020dc4176d38dd5f3d0496f3c46849862ee0b/browser/base/content/nsContextMenu.js#1169,1171 , we try to follow a link to get content type headers. If the link requires authentication, we stop trying to connect.

This is because there is a fallback here, where if the initial connection doesn't respond within 4 seconds ( https://searchfox.org/mozilla-central/rev/2f1020dc4176d38dd5f3d0496f3c46849862ee0b/browser/app/profile/firefox.js#353 ) we time out the request to get the content type headers ( https://searchfox.org/mozilla-central/rev/2f1020dc4176d38dd5f3d0496f3c46849862ee0b/browser/base/content/nsContextMenu.js#1187 ).

In bug 597374, Honza fixed this so that if we require auth, we cancel the timer and immediately start the "back up" version, which will first prompt for a filename and then do the request, prompt for auth etc.

From bug 597374, I don't really understand why we decided to fix this this way. That is, why can't we instead prompt for auth normally and cancel the "backup" timer - the auth prompt can function as the user's "it worked" UX feedback, ie we tried to follow the link to save it, and now we're prompting for auth. Honza, can you check if I'm missing something?

Comment 1

[Honza Bambas (:mayhemer)]

I think it was "too complex": [1] We could somewhat adapt one part of patch v1 from that bug that was r-'ed [2].

that patch cancels the timer when auth is requested, allows the prompt, but doesn't renew the timer (so the bug would be there again) after credentials were entered.

if we wrap the nsIPromptFactory object the callbacks impl returns from getInterface with our own and let it then wrap the |callback| argument of asyncPrompAuth (called from [3]) with an intermediary implementation of nsIAuthPromptCallback, we could restart the timer from the call to onAuthAvailable after the user accepted the credentials.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=597374#c27
[2] https://bugzilla.mozilla.org/page.cgi?id=splinter.html&ignore=&bug=597374&attachment=478561
[3] https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#1185