Closed Bug 327510 Opened 18 years ago Closed 16 years ago

XML Parsing Error: no element found/netError.xhtml on newsgroup msg download timout

Categories

(MailNews Core :: Networking, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.9.1a2

People

(Reporter: bdl, Assigned: standard8)

References

Details

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Browsing Newsgroups. When switching from one newsgroup to another within the save news server, the following bug sometimes appears as a fullscreen display on my pc.

I have not been able to isolate it to a specific action.

XML Parsing Error: no element found
Location: jar:file:///C:/PROGRA~1/MOZILL~2/chrome/toolkit.jar!/content/global/netError.xhtml
Line Number 1, Column 1:

Reproducible: Sometimes

Steps to Reproduce:
1. Create News.softvelocity.com newscroup account
2. Subscribe to 17 + newsgroups
3. Download messages = max messages or > 2000 per newsgroup
4. Switch between newsgroups...

Bug appears randomly.




I spend 90% of my day in these newsgroups posting and reading (Software Development newsgroups)
Below Comments from a reader confirming this behaviour...
*******************

Hi!

I have the same problem as you describe in bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=327510

I have subscribed to 12 newsgroups from one server. Two of the groups never have any messages in them.

Best Regards 
I see this on Solaris as well. 
I am using Thunderbird 2.0a1, built on May 11. I may be wrong, but it 
seems to me that it happens more often on high traffic newgroups, i.e.
newgroups that have more unread messages. 

confirmed, changing OS to all based on comment 1 and comment 2
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Confirmed , using TB-3a1 under Fedora Core 5
Confirmed in TB1.5.0.7 on Windows.  I was browsing nntp.perl.org newsgroups, and the nntp server was timing out.  I'd clicked back to my inbox, since I could tell the newsgroups wouldn't respond.  It popped up the "Server not responding" message box, and when I clicked ok, it fell through to this error message display.  No keystrokes could bring the main UI back -- the menu bar was gone, Alt+Left or backspace or any other browsing "back" actions didn't work (it was a long shot, but I tried 'em), etc.  Last, when I closed the window, tb.exe didn't terminate, it just stayed in memory pegging my CPU.  Hope this additional info helps.
QA Contact: front-end
This is happenning for me too (sometimes) on Thunderbird 2.0.
I had the same problem (but the error said line 10, colum3) but it happened when I tried to read my e-mail and the Internet connection was down.

Usign Win XP SP2.

Greetings.
This tends to happen with unstable NNTP connections but is quite hard to reproduce, it started to occur in reports of people using SeaMonkey MailNews or Thunderbird when the whole netError pages mechanism landed and comes up again from time to time.
I think we have some NNTP connection error and try to display a netError page somewhere, which might make sense in the message pane, but I fear it's may even happen in the main message window somehow. The netError page has some XML error is maybe not properly set up and therefore missing some element(s) and running into this XML error display that takes away all chrome.
I just hit a "Timeout when contacting news.mozilla.org" when accessing mozilla.dev.l10n via an ADSL connection that auto-disconnected and looped to a different IP.

The SeaMonkey MailNews window was _replaced_ with
about:neterror?e=netTimeout&u=news%3A//news.mozilla.org%3A119/mozilla.dev.l10n&c=UTF-8&d=The%20operation%20timed%20out%20when%20attempting%20to%20contact%20news.mozilla.org.
(according to its .URL in DOMI)

The output it showed was that well-known message:

XML Parsing Error: no element found
Location: jar:file:///opt/seamonkey-trunk/seamonkey/chrome/toolkit.jar!/content/global/netError.xhtml
Line Number 1, Column 1:

^


It looks like there are two errors here:
1) We replace the MailNews window with the error page instead of displaying it in a pane or such
2) The error page is in some way incomplete

I guess we trigger an error page in code that wasn't designed for displaying one...
Assignee: mscott → nobody
Summary: XML Parsing Error → XML Parsing Error: no element found/netError.xhtml on newsgroup msg download timout
Component: Mail Window Front End → MailNews: Networking
Product: Thunderbird → Core
QA Contact: front-end → mailnews.networking
Version: unspecified → Trunk
I've seen this a few times, in Linux trunk Thunderbird builds. Since it replaces the messenger window with the error page, Thunderbird is rendered inoperational, and thus deserves to be critical if not a blocker.
Severity: normal → critical
Flags: blocking-thunderbird3.0a2?
Hardware: PC → All
Know of a way way to reproduce this? 
I hacked nsNntpService::DisplayMessage to always show the netError.xhtml page - that works fine (unfortunately).
I haven't tried it, but my best guess for a way to reproduce would be to combine a slowish news server with a firewall that you can quickly switch to blocking Tb. Then I'd think 1. Click newsgroup folder, 2. Block with firewall so the request will time out, 3. Click mail folder to confuse Tb about where to display, ought to trigger it, though the timing between 1 and 2 might be critical.
(In reply to comment #13)
> Know of a way way to reproduce this? 
> I hacked nsNntpService::DisplayMessage to always show the netError.xhtml page -
> that works fine (unfortunately).
> 
100% reproducable here, I have a newsgroups subsribed to that is now unavailable.
secnews.netscape.com I attempt to open the newsgroup..get cannot conect message
(that is the normal message) Now if I click on a previously downloaded header, after a time, I get the "neterror" as well as the normal message.

Back when I had cable modem service, I could make it happen just by hitting
standby on the cable modem.

(In reply to comment #13)
> Know of a way way to reproduce this? 

A while back, my ISP's news server went spotty and would drop connections, which caused the error for me. I suspect that ifconfig <interface> down would be sufficient to cause this error, although I have not tested this.
I just experienced this bug in Thunderbird 2.0.0.14.  The entire application window was replaced with the message.  I had to close it and restart Thunderbird.

I have dial-up, and multiple tabs were loading in Firefox.  I clicked on a newsgroup in TB.  Eventually it timed out (I guess because my slow connection was saturated).  I believe I got a dialog box with a timeout error, and then when I clicked ok this bug occurred.
Given that we can't repro, i wouldn't block a2.  It would be good to figure out what's going on, though...
Flags: wanted-thunderbird3.0a2+
Flags: blocking-thunderbird3.0a2?
Flags: blocking-thunderbird3.0a2-
Flags: blocking-thunderbird3+
Keywords: qawanted
From bug 44309:
Opening under Mail Window as no News component available. Opening a news
message in offline mode opens window with chrome error:

XML Parsing Error: no element found
Location:
jar:file:///C:/Program%20Files/Mozilla%20Thunderbird/chrome/toolkit.jar!/content/global/netError.xhtml
Line Number 1, Column 1:

Should be sufficient to reproduce (haven't tested, though).
(In reply to comment #20)
> From bug 44309:

I think you meant bug 444309.

> Opening under Mail Window as no News component available. Opening a news
> message in offline mode opens window with chrome error:
> 
> XML Parsing Error: no element found
> Location:
> jar:file:///C:/Program%20Files/Mozilla%20Thunderbird/chrome/toolkit.jar!/content/global/netError.xhtml
> Line Number 1, Column 1:
> 
> Should be sufficient to reproduce (haven't tested, though).

I couldn't reproduce this with simple text based messages - I get the normal this hasn't been downloaded message. Maybe it needs remote images as well?

I wonder if playing about with responses on the news fakeserver could reproduce this error (i.e. denying a response).

For reference, we probably need to fix this in a manner similar to bug 212221, but I wouldn't really want to accept/test a patch without a reliable test case first.
Product: Core → MailNews Core
This bug still exists in SeaMonkey 1.1.11 (German version). It just happened to me a few minutes ago:

XML-Verarbeitungsfehler: Kein Element gefunden
Adresse: jar:resource:///chrome/toolkit.jar!/content/global/netError.xhtml
Zeile Nr. 1, Spalte 1:

This happens to me about once daily :-(
(In reply to comment #8)
> This tends to happen with unstable NNTP connections but is quite hard to
> reproduce,

Oh, really? Is it? Sorry, but after 6 crashes this morning within 1 hour and the uncounted mass of crashes during the last few weeks, this is hard to believe.

I just have the contrary problem: It's quite hard to AVOID!

> it started to occur in reports of people using SeaMonkey MailNews or
> Thunderbird when the whole netError pages mechanism landed and comes up again
> from time to time.

Then REMOVE that f**ing new mechanism and replace it by the old one, until the new one is COMPLETELY checked and 100% error free!

Due to my SeaMonkey experience, I must say: Version 1.1.11 is the WEAKEST version that ever entered my computer :-(
Thanks to our recent fake server implementations that we've written for news, I've finally been able to consistently reproduce this.

The problem occurs when the server connection dies as we try to retrieve a message. So, what I am hoping we can do is to turn off xul error pages for the window in question. I think I know which one that is, and I'm currently trying out fixes for it, therefore taking the bug.
Assignee: nobody → bugzilla
Priority: -- → P2
Attached patch Partial Fix (obsolete) — Splinter Review
This patch fixes the netError.xhtml problem (needs a simple port to SM, but I'll do that later), we just get two connection lost dialogs instead of one. I think this may point to the real problem (not providing correct error handlers for a connection?), so I'll investigate a bit more before submitting this.
Attached patch Proposed Fix (obsolete) — Splinter Review
This patch includes fixes for SM and TB. This basically turns off error pages for the main window.

I have also included a change in nsMsgProtocol.cpp to not prompt the user on error if we are set up to use a channel because the networking code prompts for us.

This is where it was loading the error page, I've currently lost where the other prompts are generated, but they are around there somewhere.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsWebShell.cpp&rev=1.701&mark=1179-1198#1178
Attachment #333155 - Attachment is obsolete: true
Attachment #333168 - Flags: superreview?(bienvenu)
Attachment #333168 - Flags: review?(neil)
Comment on attachment 333168 [details] [diff] [review]
Proposed Fix

this looks good - but what about the stand alone message window?
Attachment #333168 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 333168 [details] [diff] [review]
Proposed Fix

Might it be nice to have this on the 1.8 branch for SeaMonkey 1.1.12?
Attachment #333168 - Flags: review?(neil) → review+
Keywords: qawanted
Target Milestone: --- → mozilla1.9.1a2
Attached patch Improved FixSplinter Review
Improved fix. Fixes the problem for the standalone message window as well. I also verified we still get the correct connection lost dialogs.
Attachment #333168 - Attachment is obsolete: true
Attachment #333202 - Flags: superreview?(bienvenu)
Attachment #333202 - Flags: review?(neil)
Attachment #333202 - Flags: review?(neil) → review+
Comment on attachment 333202 [details] [diff] [review]
Improved Fix

cool, thanks
Attachment #333202 - Flags: superreview?(bienvenu) → superreview+
Checked in, changeset id: 79:3cf247053c39. This bug is now fixed on trunk (alpha/beta builds).

I am currently trying the patch out on the 1.8 branch (TB 2.0 / SM 1.1), if it builds etc, then I will request the appropriate approvals.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
I've tried this on the 1.8 branch. TB seems to handle its errors differently (they appear in the message pane rather than the full-screen error). I couldn't get SM to talk to the newsgroup server properly to actually see the messages, I don't know why.

If anyone wants to take over getting this onto the 1.8 branch please do.
I'd love to see this on the branch, ideally on the upcoming releases, but we'd need to sneak it in quite fast for that, as FF/platform are already frozen, so I guess the release branch will be created on Monday.
I have built a branch SeaMonkey and reading news still works fine, but I have no means of triggering the error there, my connection and news servers aren't flaky enough.
(In reply to comment #22)

> This bug still exists in SeaMonkey 1.1.11 (German version).

It just happened again last week with SeaMonkey 1.1.14, so the problem is still not fixed.

But it seems that I accidentally found some kind of workaround: Some months ago (I think it was still with version 1.1.11), I removed all .msf files from all subscribed newsgroups. After that, the error was gone completely. At least for a long while.

Last week the error suddenly reappeared (after a system crash), and it did so not only once, but several times. Again, I removed all .msf files, and since then the error has not reappeared yet.

So, I think the error might be caused by some problems with the .msf files. Obviously one ore more of them were corrupted by the system crash.
(In reply to comment #36)
> It just happened again last week with SeaMonkey 1.1.14, so the problem is still
> not fixed.

It was fixed, just not on the SM 1.1/TB 2.0 (i.e., Mozilla 1.8) branch. See comment 32 and comment 33 for more information.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: