Is it only that one capability that broke? The changes to caps itself during that interval look totally benign: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fcaps&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-07-05&maxdate=2007-07-13%2012:00&cvsroot=%2Fcvsroot would it be possible to narrow down the regression range to a single day? I won't be able to do it myself for about a week.
I wouldn't ask someone to help patch my roof, and then refuse to pass the hammer. Narrowing regression range: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070618 Thunderbird/3.0a1pre ID:2007061803 works as expected Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070619 Thunderbird/3.0a1pre ID:2007061903 Regressed
Not that the query in comment 1 is wrong. It's going from July 5, whereas the range given was from May 4. The one-day range in question is: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-18+03&maxdate=2007-06-19+03&cvsroot=%2Fcvsroot Chances are, this is one of my changes. I'll be happy to debug if you can point me to a way to test (a newsgroup message to load, in particular).
Happy to provide you with one BZ news://news.mozilla.org:firstname.lastname@example.org
But that's also been the case for a while now, as I recall. I seem to recall it coming up in a bug a while back...
Yeah, so the port comes from nsNNTPProtocol::Initialize which sets it on the channel's URI; then GetChannelPrincipal ends up with that URI. I really don't see why this would have regressed in the given range, since I see no changes to nsNNTPProtocol in there either, and GetChannelPrincipal has not changed in a while... ccing mscott and bienvenu, in case they have any ideas. But double-check the port thing?
OK thanks for looking into this bz, So in modifying the sites line to include the port like this: user_pref("capability.policy.jsok.sites", "news://news.mozilla.org:119 news://secnews.netscape.com"); seems to work fine, and I will pass that on to other users, but maybe whatever happened in tbird to produce this "refinement" may have some other side effects. If it stays as-is at least an update to the caps info page will be needed. Thanks again bz
Your assumption would be correct: In tbird builds 20070618 and prior including the port does not work,the domain name without the port does work. 20070619 and after: you must include the port, otherwise caps ignores the directive.
OK, I know what happened here. The new code clones the mailnews URIs, which cannot be made immutable. The point is that cloning them actually sets up the inner URI correctly(!). The problem without that is that SetPort() currently doesn't correctly update the state of an nsStandardURL, so that calling GetHostPort() after calling SetPort() just gets the host, not the port. The clone is reparsed from a string, so the problem goes away. So given the mailnews code the port needs to be there in the security prefs. I've filed bug 388281 on the SetPort() issue.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.