Closed Bug 106461 Opened 23 years ago Closed 22 years ago

header pane disappears in three-pane window (caused by corrupt abook.mab)

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: 3.14, Assigned: sspitzer)

References

Details

(Keywords: dataloss)

Attachments

(3 files, 1 obsolete file)

Screenshot showing defective header pane
108.68 KB, image/png
Details
An address book that's about to die.
11.26 KB, text/plain
Details
Avoid corrupt addressbook breaking message header pane
1.87 KB, patch
Details | Diff | Splinter Review
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 (three-pane window) Under unclear conditions. The header pane completely disappears for e-mail messages. The message body shows up, but that's it. I could not find out to what under which curcumstances this happens. It has not happened to me in 0.9.4. To get the header pane back I have to minimize the body section and bring it back. pi
probably the condition reported in bug 79802 *** This bug has been marked as a duplicate of 79802 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
verified as a duplicate
Status: RESOLVED → VERIFIED
Reopening and verifying as new. This bug is a 10/24 new regression. The conditions for it to happen are unclear but certainly different than in bug 79802. In my case it is 3-pane, Mozilla 2001102403, WindowsME. Changing component to Mail Window Front End.
Status: VERIFIED → UNCONFIRMED
Component: Mail Back End → Mail Window Front End
Resolution: DUPLICATE → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> All/All
OS: Linux → All
Hardware: PC → All
Deleting of component.reg in Mozilla directory solved the problem to me. This probably makes the bug INVALID but I will leave it to others to decide.
BTW, you need to delete component.reg when Mozilla is swithed off!
*** Bug 106665 has been marked as a duplicate of this bug. ***
I see this bug in my 200110309 build, and nothing that's mentioned in this bug makes the header pane come back, *really* annoying. Marking dogfood, catfood, all kinds of foods. Please please fix this regression ASAP.
Severity: normal → critical
Keywords: mozilla0.9.6, nsCatFood, nsdogfood
After reopening, what I wrote at the not duplicate: Here is one situation in which the header pane disappeared: 1) I read e-mail in one folder, deleted all messages. Did something else (including using the browser). 2) I came back, a new message was there. I clicked on it. The body did appear, the header pane not. I haven't done anything to the mail window in the meantime. I'll check if the solution works, but since I have no way to reproduce the problem, it will take a while to see if nothing happens. pi
I had the same problem without deleting all the messages. Maybe we have a few similar but different problems. From one of the (non)dups: deleting XUL.mfl solved the problem for some. BTW in Linux/Unix the file has a ifferent name (a longer extension).
>Deleting of component.reg in Mozilla directory solved >the problem to me. This probably makes the bug INVALID >but I will leave it to others to decide. OK, when we delteted /usr/lib/mozilla/component.reg, mozilla did not start: /usr/bin/mozilla: [: ==: binary operator expected Segmentation fault pi
Another way of getting the header pane back: Go to another folder, come back, klick on the message. pi
Linux Build 2001103108 Neither deleting XUM.mfasl nor switching between folders helps.
As to deleting component.reg, after you delete it Mozilla needs to recreate it. So you need to run Mozilla as a user that has write permissions to its installation directory. On Linux, you usually have to: 1. su root 2. run Mozilla 3. close Mozilla However, in my case it didn't solve the problem. Neither did minimizing message body and restoring it. I'm running Mandrake Linux 8.1. To summarize: - I can't display message headers in _any_ way (when I start up mailnews and click any message, it has no headers) - none of the workarounds that were mentioned here work for me - opening a message in a separate window doesn't help either - messing with View->Headers doesn't help
Sorry for spam. Mine is probably bug 107707.
Unchanged for Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120. pi
Yes, I still see this with recent builds on WinME. It's hard to reproduce but happens once ot twice a day.
In 0.9.8 I cannot reproduce this problem as described in Comment #9. Fixed? pi
I experienced this problem on 0.9.8, after creating a new profile. First there was only one profile and everything worked. Then I created a new profile (importing from Netscape 4.79). When I run mozilla using the new profile: no header pane. Closing and opening the message pane worked for me though.
This seems to be back in Mozilla 1.2.1. Again, no clear steps to reproduce this, but 3 users out of 18 are reporting this already. Deleting XUL.mfl does not help. This is really a big trouble!
Flags: blocking1.3b+
Just to indicate how serious this is: user cannot handle incoming e-mail attachments because the attachments cannot be selected (no header pane) and also File-Attachements-indicates no attachments when they are actually present (forwarding a message, however, includes the attachment). To me it seems (this is very similar to NV4.7*) an option of displaying e-mail (body with reduced headers) but no attachement icon.
ver 1.1 on the same profile displays the headers pane. so temporary solution is to downgrade. so only 1.2 and 1.3.a has the same error. if anybody wishes screenshots, preference files, or some tests, let me know.
kaidoloor, don't set flags if you don't know how. Thanks.
Flags: blocking1.3b+
I encountered this bug when using Mozilla 1.1 and 1.21. Deleting components.reg and XUL.mfl and all the methods mentioned here didn't help. Creating a new profile solved the problem. It had happened twice on me since I started to use Mozilla 1.1. I am not sure if it is related: I was using the "Little Mozilla" scheme. Now just to be safe, I am using the modern scheme. Until now I haven't seen the problem again, but it may happen one day...
Sorry, forgot to mention that I am using Win98 second edition (Tradtional Chinese version). The Mozilla version is the English version.
Thanks Asa, sorry about flags. Btw, we are also on modern scheme, so this does not help.
I'm pretty sure this screenshot depicts what's going on.
*** Bug 191563 has been marked as a duplicate of this bug. ***
Can you please all rename the file "abook.mab" (Mozilla Adressbook) in your mozilla-profile for a test ? (if you still have the problem)
*** Bug 191906 has been marked as a duplicate of this bug. ***
Re: Additional Comment #29 From Matti (Matthias "hating marquee" Versen) renaming abook.mab worked for me, thanks.
Renaming abook.mab worked. I looked through the file and noticed a lot of junky data at the bottom. Deleted it, named it back to abook.mab and the fixed stayed working, but I got my address book back, too! Looks like maybe the next installer should check the .mab files and make sure they're not corrupted or anything.
Keywords: nsCatFood, nsdogfood → dataloss
Summary: header pane disappears in three-pane window → header pane disappears in three-pane window (caused by corrupt abook.mab)
I'm seeing the same problem as in Comment #27. But it wasn't fixed after renaming abook.mab. I also changed all of my other address books (Business.mab, Quicklist.mab and Unfiled.mab synced from my palm), but it still didn't work. Any more ideas?
I have been able to track when abook.mab occurs for me. I'm using nightly build of 8th Feb 2003. Upon starting browser and mail/news with a clean abook.mab, the corruption occurs the moment I preview the first email. The corruption (after '</RDF:RDF>' ) contains content similar to the following, but with the email address of the previewed email. It seems there is one block for each previewed email (starting with @$${XX{@ and ending with @$$}XX}@, where XX is a number). @$${33{@ <(61D=139)(618=XXXX)(619=XXXXX)(61A=XXXX XXXXX)(61B=XXXXXXXXXXXXXXXXX) (61C=XXXXXXXXXXXXXXXXX)> {1:^80 {(k^AD:c)(s=9)} [-137(^83^618)(^84^619)(^CB=)(^CC=)(^85^61A)(^86=)(^87^61B)(^88^61C) (^89=)(^BB=)(^BC=)(^8A=0)(^8B=)(^8C=)(^8D=)(^8E=)(^8F=)(^BD=)(^BE=) (^BF=)(^C0=)(^C1=)(^90=)(^91=)(^92=)(^93=)(^94=)(^95=)(^96=)(^97=) (^98=)(^99=)(^9A=)(^9B=)(^9C=)(^9D=)(^9E=)(^C2=)(^C3=)(^C4=)(^C5=) (^C6=)(^C7=)(^C8=)(^C9=)(^9F=)(^A0=)(^A1=)(^A2=)(^A3=)(^A4=)(^A5=) (^A6=)(^A7=)(^A8=)(^A9=0)(^AA=139)]} [1:^82(^AC=139)] @$$}33}@ @$${34{@ <(622=13a)(61E="XXXXXX)(61F=XXXXXX")(620="XXXXXX XXXXXX")(621 =XXXXXXXXXXXXXXXXXXXX)> {1:^80 {(k^AD:c)(s=9)} [-138(^83^61E)(^84^61F)(^CB=)(^CC=)(^85^620)(^86=)(^87^621)(^88^621) (^89=)(^BB=)(^BC=)(^8A=0)(^8B=)(^8C=)(^8D=)(^8E=)(^8F=)(^BD=)(^BE=) (^BF=)(^C0=)(^C1=)(^90=)(^91=)(^92=)(^93=)(^94=)(^95=)(^96=)(^97=) (^98=)(^99=)(^9A=)(^9B=)(^9C=)(^9D=)(^9E=)(^C2=)(^C3=)(^C4=)(^C5=) (^C6=)(^C7=)(^C8=)(^C9=)(^9F=)(^A0=)(^A1=)(^A2=)(^A3=)(^A4=)(^A5=) (^A6=)(^A7=)(^A8=)(^A9=0)(^AA=13a)]} [1:^82(^AC=13a)] @$$}34}@ @$${35{@ @$$}35}@
*** Bug 194350 has been marked as a duplicate of this bug. ***
*** Bug 192523 has been marked as a duplicate of this bug. ***
Is it possible that this is fixed by 1.3.final? What can be done to facilitate this?
This is an address book created by mozilla (names have been changed to protect the innocent) after collecting addresses for a bit. If I open mozilla with it then everything is fine. But when I close mozilla, a tiny bit is added to the end: @$${1F{@ @$$}1F}@ And the next time mozilla is opened the address book doesn't work, headers don't display properly and when you open a message in it's own window the message doesn't display. This works (doesn't work?) constently on 1.3b on Linux and Windows on the machines I've tried it on.
Flags: blocking1.3?
*** Bug 196315 has been marked as a duplicate of this bug. ***
As the poster of bug 196315, I didn't add it as a duplicate becasue I could not get the header/attachment bit back by resizing the window(s).
Flags: blocking1.3? → blocking1.3-
*** Bug 199588 has been marked as a duplicate of this bug. ***
I actually like the behavior, since it gives me more reading area.
*** Bug 197536 has been marked as a duplicate of this bug. ***
Eugene, although you may like the look, it is still unintended, and i believe impossible to receive attachements
my bugs were cured (thanks to Mattie) by deleting my address book which had rogue data (entered by a Palm sync) at the end of the address book.
*** Bug 199640 has been marked as a duplicate of this bug. ***
Any corrupt bookmark will cause ------- snip -------- var abAddressCollector = Components.classes[abAddressCollectorContractID].getService(Components.interfaces.nsIAbAddressCollecter); ------- snap -------- in line 70 in msgHdrViewOverlay.js to fail with ------- snip -------- Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: chrome://messenger/content/msgHdrViewOverlay.js :: <TOP_LEVEL> :: line 70" data: no] ------- snap -------- Since the error occurs on the file's main level, the entire remaining content of the file is ignored, resulting in the missing header pane. A try...catch block around the line will prevent this. The corrupt addressbook will not be used in this program run (and hence stay corrupt). (See patch)
The patch guards the request for the addressbook-service with a try...catch block. The addressbook stays corrupt, though.
Comment on attachment 120898 [details] [diff] [review] Avoid corrupt addressbook breaking message header pane Seth: What Do you think about this ? This will not fix this bug (corrupt adressbook) but the mail header pane, single message view and offline synch will work after this patch with a corrupt abook.mab or history.mab
Attachment #120898 - Flags: superreview?(sspitzer)
*** Bug 195374 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b?
a stack, to why a bad abook.mab file causes the header pane to fail. NTDLL! 77f9180c() nsDebug::Assertion(const char * 0x034b8d3c, const char * 0x034b8ffc, const char * 0x034b8fc8, int 57) line 270 + 13 bytes mork_assertion_signal(const char * 0x034b8d3c) line 57 + 31 bytes morkEnv::NewError(const char * 0x034bad9c) line 405 + 19 bytes morkParser::FindGroupEnd(morkEnv * 0x02fe0728) line 1184 morkParser::ReadGroup(morkEnv * 0x02fe0728) line 1212 + 12 bytes morkParser::ReadAt(morkEnv * 0x02fe0728, unsigned char 0) line 1255 morkParser::ReadContent(morkEnv * 0x02fe0728, unsigned char 0) line 1440 + 16 bytes morkParser::OnPortState(morkEnv * 0x02fe0728) line 1474 + 14 bytes morkParser::ParseLoop(morkEnv * 0x02fe0728) line 1532 + 12 bytes morkParser::ParseMore(morkEnv * 0x02fe0728, int * 0x0012e230, unsigned char * 0x02fe1834, unsigned char * 0x02fe1835) line 1571 morkThumb::DoMore_OpenFileStore(morkEnv * 0x02fe0728) line 480 morkThumb::DoMore(morkEnv * 0x02fe0728, unsigned int * 0x0012e2a8, unsigned int * 0x0012e2a0, unsigned char * 0x0012e2ac, unsigned char * 0x0012e2a4) line 400 + 12 bytes morkThumb::DoMore(morkThumb * const 0x02fe1824, nsIMdbEnv * 0x02fe0754, unsigned int * 0x0012e2a8, unsigned int * 0x0012e2a0, unsigned char * 0x0012e2ac, unsigned char * 0x0012e2a4) line 195 nsAddrDatabase::OpenMDB(nsAddrDatabase * const 0x02fe0160, nsFileSpec * 0x02fe3e80, int 1) line 652 + 35 bytes nsAddrDatabase::Open(nsAddrDatabase * const 0x02fe3c58, nsFileSpec * 0x02fe3e80, int 1, nsIAddrDatabase * * 0x02fe390c, int 1) line 565 + 20 bytes nsAddressBook::GetAbDatabaseFromURI(nsAddressBook * const 0x02fe3bc8, const char * 0x02fe3a88, nsIAddrDatabase * * 0x02fe390c) line 259 + 44 bytes nsAbAddressCollecter::SetAbURI(const char * 0x02fe3a30) line 337 + 75 bytes nsAbAddressCollecter::Init() line 300 + 59 bytes nsAbAddressCollecterConstructor(nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012e568) line 100 + 125 bytes nsGenericFactory::CreateInstance(nsGenericFactory * const 0x017193b8, nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012e568) line 86 + 21 bytes nsComponentManagerImpl::CreateInstance(nsComponentManagerImpl * const 0x00ee51e8, const nsID & {...}, nsISupports * 0x00000000, const nsID & {...}, void * * 0x0012e568) line 1924 + 24 bytes nsComponentManagerImpl::GetService(nsComponentManagerImpl * const 0x00ee51ec, const nsID & {...}, const nsID & {...}, void * * 0x0012e644) line 2118 + 50 bytes nsServiceManager::GetService(const nsID & {...}, const nsID & {...}, nsISupports * * 0x0012e644, nsIShutdownListener * 0x00000000) line 78 nsJSCID::GetService(nsJSCID * const 0x02fe3288, nsISupports * * 0x0012e820) line 877 + 48 bytes XPTC_InvokeByIndex(nsISupports * 0x02fe3288, unsigned int 11, unsigned int 1, nsXPTCVariant * 0x0012e820) line 102 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_METHOD) line 2023 + 42 bytes XPC_WN_CallMethod(JSContext * 0x01595498, JSObject * 0x01676d78, unsigned int 1, long * 0x02fd4028, long * 0x0012eafc) line 1284 + 14 bytes js_Invoke(JSContext * 0x01595498, unsigned int 1, unsigned int 0) line 843 + 23 bytes js_Interpret(JSContext * 0x01595498, long * 0x0012f9a0) line 2834 + 15 bytes js_Execute(JSContext * 0x01595498, JSObject * 0x00f6f6a0, JSScript * 0x02f90f88, JSStackFrame * 0x00000000, unsigned int 0, long * 0x0012f9a0) line 1038 + 13 bytes JS_ExecuteScript(JSContext * 0x01595498, JSObject * 0x00f6f6a0, JSScript * 0x02f90f88, long * 0x0012f9a0) line 3373 + 25 bytes nsJSContext::ExecuteScript(nsJSContext * const 0x015a3720, void * 0x01676980, void * 0x00f6f6a0, nsAString * 0x00000000, int * 0x00000000) line 868 + 42 bytes nsXULDocument::ExecuteScript(JSObject * 0x01676980) line 3434 + 33 bytes nsXULDocument::LoadScript(nsXULPrototypeScript * 0x02f8fa90, int * 0x0012fb84) line 3208 + 15 bytes nsXULDocument::ResumeWalk() line 2990 + 19 bytes nsXULDocument::CachedChromeStreamListener::OnStopRequest(nsXULDocument::CachedChromeStreamListener * const 0x02e43330, nsIRequest * 0x016086b8, nsISupports * 0x00000000, unsigned int 0) line 4371 nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x01609740, nsIRequest * 0x016086b8, nsISupports * 0x00000000, unsigned int 0) line 252 nsCachedChromeChannel::HandleStopLoadEvent(PLEvent * 0x02e38f10) line 477 PL_HandleEvent(PLEvent * 0x02e38f10) line 659 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00eee3b8) line 592 + 9 bytes _md_EventReceiverProc(HWND__ * 0x002c059a, unsigned int 49506, unsigned int 0, long 15655864) line 1395 + 9 bytes USER32! 77e3a244() USER32! 77e145e5() USER32! 77e1a792() nsAppShellService::Run(nsAppShellService * const 0x015a0010) line 479 main1(int 2, char * * 0x00270070, nsISupports * 0x00f5fde0) line 1268 + 32 bytes main(int 2, char * * 0x00270070) line 1647 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77ea847c()
Assignee: mscott → sspitzer
the error, from inside mork, for the abook attached to this bug is: "expected '}' after @$$" working on making us handle corrupt abook more gracefully. the fix attached to the bug will fix the header problem, but without a PAB, a bunch of other things will be broken.
Status: NEW → ASSIGNED
ok, working on a fix to move aside the corrupt mab file. with a PAB, there's going to be a lot of badness.
still a work in progress. because the fix for #198303 is still in progress, this isn't ready yet.
Flags: blocking1.4b?
Flags: blocking1.4b-
Flags: blocking1.4?
fix, the patch is in bug #198303 you'll now get alerting if your PAB is corrupt (assuming we can tell, which we normally can), that we renamed it, and that a new one is created for you.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Attachment #121503 - Attachment is obsolete: true
Attachment #120898 - Flags: superreview?(sspitzer)
Are we ignoring the fact that it's Mozilla that's corrupting the address book in the first place and just having to live with the fact that we'll lose out address books every so often?
Ignoring the problem, which is what Spitzer's fix does, is no fix! I cannot tell my folks that their AB can potentially become unusable trash, why not either fix the bug or create a routine whereby when corruption is detected, an AB rebuild occurs recovering the data...
James, Barry, this bug is not about the address book getting broken (even though it is the cause of the problem). So please do not spam this bug, but search the appropriate bug for that issue. Thanks. Verifying as reporter per comment 55. pi
Status: RESOLVED → VERIFIED
Flags: blocking1.4?
This is a fix because this adds a better error handling. There are possible different reasons fur such a corruption (fs error after a crash..) and you can file a new bug for the real cause of such a corruption if you know how this happend (I never saw this myself). The old AB is not lost, it will renamed and you can fix it with an editor.
*** Bug 196266 has been marked as a duplicate of this bug. ***
*** Bug 202556 has been marked as a duplicate of this bug. ***
*** Bug 203700 has been marked as a duplicate of this bug. ***
*** Bug 200123 has been marked as a duplicate of this bug. ***
*** Bug 206526 has been marked as a duplicate of this bug. ***
*** Bug 204263 has been marked as a duplicate of this bug. ***
This is probably going to seem like a very stupid question, but could someone give those of us who are non technical the exact fix for this problem? What to delete and how to use the patch etc? Or which version to go forward to or regress to? It would be appreciated. Thanks Carolyn
1.4b conatins this fix. Mozilla will rename your abook file. You can do that yourself if you close mozilla and rename the file abook.mab in your mozilla profile directory (see the 1.3.1 Release notes for the Profile path on your OS) You can try to fix your abook.mab with a text-editor (could be some corruption at the end of the file) and after that rename it back.
This was probably not a bug. The problem is usually caused by a corrupt abook.mab file, or in my case, I accidently had the "READ ONLY" properties flag checked for the abook.mab file. When in this problem mode, Compress folders and Empty trash choices under File in mail are grayed out. In addition, if you receive an email with attachment(s), the special window pane will not open [display] to show the received attachment(s). If you have this problem, you might first check the properties on the abook.mab file, and if okay, open the abook.mab file with an editor and see if you can find any corruption in the address book and correct it. Reference bug reports 206526 and 206527.
*** Bug 207170 has been marked as a duplicate of this bug. ***
*** Bug 209259 has been marked as a duplicate of this bug. ***
*** Bug 209500 has been marked as a duplicate of this bug. ***
*** Bug 190186 has been marked as a duplicate of this bug. ***
*** Bug 191218 has been marked as a duplicate of this bug. ***
*** Bug 213217 has been marked as a duplicate of this bug. ***
*** Bug 196303 has been marked as a duplicate of this bug. ***
*** Bug 206745 has been marked as a duplicate of this bug. ***
*** Bug 192960 has been marked as a duplicate of this bug. ***
*** Bug 199411 has been marked as a duplicate of this bug. ***
*** Bug 198816 has been marked as a duplicate of this bug. ***
*** Bug 178844 has been marked as a duplicate of this bug. ***
*** Bug 103812 has been marked as a duplicate of this bug. ***
Is this really fixed? I found this bug in Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040901; (FreeBSD 5.2.1-RELEASE-p9). I've encountered this even in Mozilla under win32 (bug #242395), but there is a bit better behaviour - the attachment box is rendered empty and after pressing the down key, attachments are shown. In my opinion this is related to the e-mail source client, I have problems with emails sent from Outlook.
*** Bug 186295 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: