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.
over to david. david, any idea who owns the mailnews part of the seamonkey suite?
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..
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?
I think this is a Seamonkey bug, so I think it's whatever happens in xpfe/communicator/contentAreaClick.js
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.
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
Hmm.. ok. Then yes, this is likely tied to the docshell prompt changes that landed on branch as security fixes...
This problem seems to have been resolved in version 1.7.6.
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.