Build ID: 2006-02-19-08, Windows XP SeaMonkey trunk. Summary: News:// URIs without default server fail to invoke Account Wizard. NOTE: Might be fallout from bug 285631. Steps to Reproduce: 1. Load http://www.mozilla.org/support/ 2. Without any news server set up, click on news://alt.fan.mozilla/ Expected Results: It should invoke the Account Wizard and prompt for the news server, etc. Actual Results: 1. news://news:119/alt.fan.mozilla is displayed in the URL bar. 2. We get the XUL Error Page, which states, "Address Not Found news could not be found. Please check the name and try again. The browser could not find the host server for the provided address." See screenshot.

Although there is some XUL/RDF weirdness, the protocol stuff can't be yours, Neil, since it occurs in a 2006-02-12-08 trunk build, which is before your landing. Sorry for the bogus implication.

This worksforme with a 2006-02-19 Linux build. Stephen, can you narrow down when this broke on Windows.

According to my (limited) testing, it's broken as far back as Mozilla 1.8a3 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040902 trunk, which really, really makes me wonder how it could've been broken that long. I have confirmation from a couple other users in #developers/#seamonkey that this is broken for them too on Windows XP trunk. http://archive.mozilla.org/pub/mozilla/nightly/ isn't useful further... The following is output from Chris Thomas (CTho) --WEBSHELL 0B2A3390 == 15 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file i:/smtrunk1/mozilla/mailnews/db/msgdb/src/nsMsgDatabase.cpp, line 167 Error loading URL news://news:119/alt.fan.mozilla : 804b001e <%CTho|away> after the error page showed up i got a bunch of warnings from nsmsgfolderdatasource.cpp:1632 WARNING: NS_ENSURE_TRUE(msgWindow) failed: file i:/smtrunk1/mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 464 WARNING: NS_ENSURE_TRUE(msgPrompt) failed: file i:/smtrunk1/mozilla/mailnews/base/util/nsMsgProtocol.cpp, line 409 ++DOMWINDOW == 40 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(result)) failed: file i:/smtrunk1/mozilla/content/xml/document/src/nsXMLContentSink.cpp, line 993 then a bunch of this: (may not be related) WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed: file i:/smtrunk1/mozilla/mailnews/base/src/nsMsgFolderDataSource.cpp, line 1632

So this appears to be Windows-only. Like I just told stephend on irc: > stephend: so someone with a debug build > stephend: who can see this > stephend: should trace this. Start with ShowErrorPage, see why we get in there > stephend: that should say which operation failed > stephend: then breakpoint in that, and trace why it fails

Some debug info: (Stacktrace for break in nsDocShell::LoadErrorPage follows:) <mcsmurf> > docshell.dll!nsDocShell::LoadErrorPage(nsIURI * aURI=0x05388114, const unsigned short * aURL=0x00000000, const unsigned short * aErrorType=0x0012f24c, const unsigned short * aDescription=0x0012f2f4, nsIChannel * aFailedChannel=0x051d4920) Line 3013 C++ <mcsmurf> docshell.dll!nsDocShell::DisplayLoadError(unsigned int aError=2152398878, nsIURI * aURI=0x05388114, const unsigned short * aURL=0x00000000, nsIChannel * aFailedChannel=0x051d4920) Line 2989 C++ <mcsmurf> docshell.dll!nsWebShell::EndPageLoad(nsIWebProgress * aProgress=0x059893b4, nsIChannel * channel=0x051d4920, unsigned int aStatus=2152398878) Line 1099 C++ <mcsmurf> docshell.dll!nsDocShell::OnStateChange(nsIWebProgress * aProgress=0x059893b4, nsIRequest * aRequest=0x051d4920, unsigned int aStateFlags=131088, unsigned int aStatus=2152398878) Line 4658 C++ <mcsmurf> docshell.dll!nsDocLoader::FireOnStateChange(nsIWebProgress * aProgress=0x059893b4, nsIRequest * aRequest=0x051d4920, int aStateFlags=131088, unsigned int aStatus=2152398878) Line 1215 C++ <mcsmurf> docshell.dll!nsDocLoader::doStopDocumentLoad(nsIRequest * request=0x051d4920, unsigned int aStatus=2152398878) Line 848 C++ <mcsmurf> docshell.dll!nsDocLoader::DocLoaderIsEmpty() Line 745 C++ <mcsmurf> docshell.dll!nsDocLoader::OnStopRequest(nsIRequest * aRequest=0x051d4920, nsISupports * aCtxt=0x00000000, unsigned int aStatus=2152398878) Line 665 C++ <mcsmurf> necko.dll!nsLoadGroup::RemoveRequest(nsIRequest * request=0x051d4920, nsISupports * ctxt=0x00000000, unsigned int aStatus=2152398878) Line 686 + 0x2e bytes C++ <mcsmurf> msgbsutl.dll!nsMsgProtocol::OnStopRequest(nsIRequest * request=0x059da0c8, nsISupports * ctxt=0x05388110, unsigned int aStatus=2152398878) Line 409 C++ <mcsmurf> msgnews.dll!nsNNTPProtocol::OnStopRequest(nsIRequest * request=0x059da0c8, nsISupports * aContext=0x05388110, unsigned int aStatus=2152398878) Line 1244 C++ <mcsmurf> necko.dll!nsInputStreamPump::OnStateStop() Line 545 C++ <mcsmurf> necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x058f41d0) Line 369 + 0xb bytes C++ <mcsmurf> xpcom_core.dll!nsInputStreamReadyEvent::EventHandler(PLEvent * plevent=0x051d1184) Line 121 C++ <mcsmurf> xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x051d1184) Line 688 + 0xc bytes C <mcsmurf> xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00fcb348) Line 623 + 0x9 bytes C <mcsmurf> xpcom_core.dll!_md_EventReceiverProc(HWND__ * hwnd=0x002b03ea, unsigned int uMsg=49378, unsigned int wParam=0, long lParam=16560968) Line 1408 + 0x9 bytes C <bz> ok <bz> in OnPageLoad <bz> What's the channel? <bz> er, in EndPageLoad <mcsmurf> - channel 0x051d4920 {m_ProxyServer=0x00000000 <Bad Ptr> m_newsgroupList={...} m_articleList={...} ...} nsIChannel * <mcsmurf> hmm <bz> yes <bz> but what sort of object? <bz> the concrete class? <mcsmurf> + [nsNNTPProtocol] {m_ProxyServer=0x00000000 <Bad Ptr> m_newsgroupList={...} m_articleList={...} ...} nsNNTPProtocol <mcsmurf> ? <bz> ok <bz> so in nsInputStreamPump::OnStateStop <bz> mStatus is an error, right? <mcsmurf> mStatus 2152398878 unsigned int <bz> right <bz> so we need to find out what set that to error <bz> ok <bz> set breakpoints in the following places <bz> nsInputStreamPump::Cancel <bz> nsInputStreamPump.cpp line 382 <bz> line 404 <bz> line 412 <bz> line 498 <bz> line 512 <bz> ok <bz> with all those set <bz> try again <bz> which one of them do you hit? <mcsmurf> line 404 <bz> nice <bz> ok <bz> so breakpoint in nsInputStreamPump::OnStateStart <bz> and step into that Available() call <bz> where do you end up? <mcsmurf> after i clicked on the OK in the subscribe dialog? <bz> yeah <mcsmurf> nsPipeInputStream::Available <mcsmurf> mPipe->mStatus 2152398878 unsigned int <bz> grrrr <mcsmurf> mAvailable 0 unsigned int <bz> what's the callstack at this point? <mcsmurf> mAvailable 0 unsigned int <mcsmurf> err <mcsmurf> > xpcom_core.dll!nsPipeInputStream::Available(unsigned int * result=0x0012f7d8) Line 708 C++ <mcsmurf> necko.dll!nsInputStreamPump::OnStateStart() Line 402 + 0x20 bytes C++ <mcsmurf> necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x059f7d00) Line 363 + 0xb bytes C++ <mcsmurf> xpcom_core.dll!nsInputStreamReadyEvent::EventHandler(PLEvent * plevent=0x05a64dc4) Line 121 C++ <mcsmurf> xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x05a64dc4) Line 688 + 0xc bytes C <mcsmurf> xpcom_core.dll!PL_ProcessPendingEvents(PLEventQueue * self=0x00fcb348) Line 623 + 0x9 bytes C <mcsmurf> xpcom_core.dll!nsEventQueueImpl::ProcessPendingEvents() Line 419 + 0xc bytes C++ <mcsmurf> gkwidget.dll!nsWindow::DispatchPendingEvents() Line 4004 C++ <mcsmurf> gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=256, unsigned int wParam=13, long lParam=1835009, long * aRetValue=0x0012fccc) Line 4348 C++ <mcsmurf> gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00230352, unsigned int msg=256, unsigned int wParam=13, long lParam=1835009) Line 1250 + 0x1d bytes C++ <bz> I see <bz> ok <bz> set breakpoints at <bz> nsPipe::OnPipeException <bz> and other places in nsPipe3.cpp where mStatus is set <bz> which do we hit? <mcsmurf> heh this function gets called quite often ;) <bz> it does? <bz> filter for the status being set being 2152398878 ? <mcsmurf> ~15 times before even the subscribe dialog appears <bz> you don't care about status sets that are not to the error we're seeing <mcsmurf> well that error gets set multiple times <bz> what's the first time? <bz> The very first time we get an error is what we care about <mcsmurf> before or after subscribe? <bz> mmmm <bz> let's try after <bz> actually <bz> no <bz> before <bz> very first time <mcsmurf> reason 2152136706 unsigned int <mcsmurf> is no error yet? <bz> reason should be 2152398878 <bz> If it's not, you don't care <mcsmurf> ok <mcsmurf> first time is after subscribe dialog <bz> ok <bz> that makes sense <bz> what's the callstack <bz> ? <mcsmurf> > xpcom_core.dll!nsPipe::OnPipeException(unsigned int reason=2152398878, int outputOnly=1) Line 559 C++ <mcsmurf> xpcom_core.dll!nsPipeOutputStream::CloseWithStatus(unsigned int reason=2152398878) Line 1039 C++ <mcsmurf> xpcom_core.dll!nsAStreamCopier::Process() Line 357 C++ <mcsmurf> xpcom_core.dll!nsAStreamCopier::HandleContinuationEvent(PLEvent * event=0x05b9f4a8) Line 395 C++ <mcsmurf> xpcom_core.dll!PL_HandleEvent(PLEvent * self=0x05b9f4a8) Line 688 + 0xc bytes C <mcsmurf> necko.dll!nsSocketTransportService::ServiceEventQ() Line 387 + 0xa bytes C++ <mcsmurf> necko.dll!nsSocketTransportService::Run() Line 616 + 0xb bytes C++ <mcsmurf> xpcom_core.dll!nsThread::Main(void * arg=0x0100e050) Line 118 + 0x1c bytes C++ <mcsmurf> nspr4.dll!_PR_NativeRunThread(void * arg=0x0100e148) Line 436 + 0xf bytes C <mcsmurf> nspr4.dll!pr_root(void * arg=0x0100e148) Line 120 + 0xf bytes C <bz> ok <bz> in Process <bz> 356 mAsyncSink->CloseWithStatus(sourceCondition); <bz> that's the line we're at? <mcsmurf> well yes, MS VC points at the else line ;-) <mcsmurf> but that one is after the you said <bz> ok <bz> What's mAsyncSource? <mcsmurf> Sink or Source? <mcsmurf> ah there <mcsmurf> + mAsyncSource {mRawPtr=0x00000000 } nsCOMPtr<nsIAsyncInputStream> <bz> yes, but what's the actual concrete type of the stream? <bz> Also <mcsmurf> + nsIInputStream {...} nsIInputStream <bz> what's the concrete type of our nsAStreamCopier? <bz> nsIInputStream is not a concrete type <mcsmurf> + [nsStreamCopierOB] {...} nsStreamCopierOB <mcsmurf> that's for the copier now <bz> nsStreamCopierOB? <bz> What's mSink? <bz> On that object? <mcsmurf> + [nsPipeOutputStream] {mPipe=0x05b80368 mWriterRefCnt=3 mLogicalOffset={...} ...} nsPipeOutputStream * bz sighs <bz> ok <bz> attach all this to the bug, I guess? <bz> I have to go <mcsmurf> ok will do <bz> somewhere someone is closing something

Oh, and this seems to be windows-only, fwiw.

*** Bug 327554 has been marked as a duplicate of this bug. ***

I hope this may be useful: I have the same problem with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060127 SeaMonkey/1.0 Mnenhy/0.7.3.0 running on a Powerbook G4 under Mac OS X 10.3.9. I also tested that with Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.3.1) Gecko/20030723 wamcom.org (a modified version of Mozilla by wamcom.org) with Classic mode (emulating Mac OS 9.2.2), and everthing works fine. news://alt.fan.mozilla is inserted in the account I use the most after the do you want to subscribe to... dialogue box (without summoning the account wizard though).

Stephen, on a debug trunk windows TB build, I get an alert about the url not being valid and thus can't be loaded. Are you seeing something different on SM?

David, it's a little different. Even if the newsgroup is already subscribed to, it complains "'news' could not be found, please check the name and try again." I know we've got bugs on auto-subscribe, but this is a clear regression--albeit one that's been around a long, long time (over a year). I tried chasing it down farther back in time, but the mozilla archive ftp server wasn't helpful. It seems that this problem essentially boils down to us not being able to find the default NNTP server, or that it thinks, in a URI such as "news://netscape.public.mozilla.mailnews" that the "news" portion (which as you know is really just the protocol) is in fact the server name. What further complicates this issue is that in testing this, "news" gets added as a server, and attempts to remove it succeed per session, but on restart it's added back (the Account Wizard does indeed get invoked, but only when you switch to the Mail window; it used to come up on its own).

*** Bug 277423 has been marked as a duplicate of this bug. ***

Any ideas on what the fix is? Should we try for 1.9a1?

(In reply to comment #3) > According to my (limited) testing, it's broken as far back as Mozilla 1.8a3 > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040902 trunk, > which really, really makes me wonder how it could've been broken that long (...) > According to my (limited) testing, it's broken as far back as Mozilla 1.8a3 > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040902 trunk, > which really, really makes me wonder how it could've been broken that long. I found back one of my first posts on Usenet in which I had copied and pasted a newsgroup name using Mozilla, and the result was news://fr.reseaux.telecoms.operateurs.mobiles and not news:fr.reseaux.telecoms.operateurs.mobiles . I remember it because another contributor had explained me that I was mistaken, and at that time, I had thought I was right because I was using the default settings of Moz. How could I have done a mistake by simply copying and pasting? Probably because this bug already existed at that time, when I was a newbie. (I'm an eternal newbie, anyway). So this bug might be much older than what you initially supposed. HTH. Additional info: Message-ID : news:bq12k9$jds$1@news-reader1.wanadoo.fr Date: Wed, 26 Nov 2003 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.5) Gecko/20031007

Note that if you open a new 3-pane window , you'll see a news account called "news" and the Wizard will run. However, if you do the same thing with the fully-qualified news://news:19/alt.fan.mozilla the wizard won't run, altho the bogus account will be created. xref bug 201721.

I'm not sure if this is a regression, but I was testing some other related bug a while ago and ended up with the bogus 'news' account -- and I can't get rid of that thru the UI. I go to Account Settings, select the account, click Remove, and it disappears -- until the next time a 3-pane window is opened. This happened after I clicked several news: URLs in succession -- looking in prefs, I had entries for server13, server14, server15. I had only seen one account called 'news' in the folder pane at any given time, and server11 existed previously for a valid account, so I'm thinking I clicked the URLs four times. Then, I assume the first time I attempted to remove a server, it took server12 away -- but I tried removing several more times and that never affected the remaining server entries. Also, a bogus identy was spawned for each of the accounts; it looks like the first bogus identity was removed along with server12. I finally got rid off all this stuff by going into config editor and deleting all the prefs with those server IDs in them and all the prefs with the identity ids in them and then fixing mail.accountmanager.accounts. (It probably would have been faster to edit prefs.js directly, but I wanted to check if doing it thru about:config was possible.) The other thing I noticed is, after the bogus "news" account is created, if I open a compose window, the Account Wizard is run (on top of a compose window that is only partially filled in). After the first time I deleted that 'news' account, this no longer occurred. This behavior means that anyone *trying* to get Mozilla to handle an unqualified news: URL ends up with no useful results and various annoying symptoms -- unwanted (or late) wizards and then bogus and unremovable entries in the lists of accounts and identities. The other issue that this bug doesn't exactly address is: a wizard isn't necessarily what you need. Instead, a URL without a server ID should be putting up a box to select from the list of existing news servers, with a "Create new News account" action that invokes the Wizard. Ideally, that box remains in place while it checks the server for the existence of the newsgroup, and reports back if not found. (A really cool whistle for this would be to have a button that directs the search for the newsgroup off to Google Groups.)

This bug has been reproduced on Linux and OS/2, see bug 426868, hence All/All.

It is the case with explicit messages as well: see e.g. http://en.wiktionary.org/wiki/SOL, where the news link doesn’t work for me either. It refers directly to a message. Both on generic WinXP and openSUSE 11.0 with TB as default news handler.

I think this is the duplicate of bug 617287.