280547 - When clicking on a URL from the email client that has arguments, the authentication window is not presented and authorization fails

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Mark Tischler]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.3) Gecko/20040920
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217

From the email client ("Mail & Newsgroups"), clicking on a URL that lives on an
Apache web server (version 1.3.29 running on UNIX Solaris 8) and that has
arguments (e.g., http://<something>?2005.01.27.001) will not present the
authentication box (an .htaccess file exists and, thus, the user is presented
with a box that asks for his/her ID and password).  It goes directly to the
screen that one gets to when one doesn't authenticate successfully.  If one
clicks on a URL without arguments, the authentication box is presented.  Then
subsequent clicks on the same link with arguments will work, because
authentication is no longer necessary for this browser session.  Interestingly,
if, instead of clicking on a URL, one copies and pastes the URL into the
Navigator's location bar, the authentication box is presented.  This problem
only happens when clicking on a URL in the email client.  That is, it does not
happen when clicking on an identical URL in the Navigator.  This was not a
problem in Mozilla 1.7.3, but appeared in Mozilla 1.7.5.  Unfortunately, there
is no URL I can give you, as we are seeing this on our company's intranet, which
is behind a firewall.

Reproducible: Always

Steps to Reproduce:
1. Click on a link that has arguments and is in or below a directory with a
.htaccess file.
Actual Results:  
Authentication failed and no authentication box was presented.

Expected Results:  
Authentication box should have been presented.

Using multiple themes.  This happened on multiple computers -- two running
Windows 2000 Pro SP4, and one running Windows XP Pro SP2.

Comment 1

[(not reading, please use [e-mail] instead)]

over to david.

david, any idea who owns the mailnews part of the seamonkey suite?

Comment 2

[David :Bienvenu]

Cc'ing Boris, as a wild stab. This might be a uri loader issue, or some security
fix in 1.7.5 might have caused this..

Comment 3

[Boris Zbarsky [:bzbarsky]]

There was a whole slew of fixes in the way dialogs of this sort are posed for
1.7.5, yes.  ccing Darin, since I think he has the best idea of what the state
of things is.

David, does mailnews treat URIs at all differently based on whether they have a
query?  I thought it just opened a browser window and passed the URI to it
instead of directly usng the URILoader... is that correct?

Comment 4

[David :Bienvenu]

I think this is a Seamonkey bug, so I think it's whatever happens in
xpfe/communicator/contentAreaClick.js

Comment 5

[Boris Zbarsky [:bzbarsky]]

Er.. no, I recall that there was some special code in mailnews to pass off the
clicks to a browser earlier (landed by Seth, iirc), because URILoader would only
do it once the server response had been received.  That's probably the first
place to look.

Comment 6

[David :Bienvenu]

you're right:

http://lxr.mozilla.org/seamonkey/source/mailnews/base/resources/content/mailWindow.js#226

but eventually, I think we call openTopBrowserWith(url), which is in the
xpfe/communicator/contentAreaUtils.js

Comment 7

[Boris Zbarsky [:bzbarsky]]

Hmm.. ok.  Then yes, this is likely tied to the docshell prompt changes that
landed on branch as security fixes...

Comment 8

[Mark Tischler]

This problem seems to have been resolved in version 1.7.6.

Comment 9

[Daniel Veditz [:dveditz]]

There were docshell changes between 1.7.5 and 1.7.6 plus a fair bit more:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_7_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-12-15&maxdate=2005-03-15&cvsroot=%2Fcvsroot

WFM per reporter.