Closed Bug 986548 Opened 10 years ago Closed 10 years ago

SeaMonkey 2.25 always crashes when trying to access email

Categories

(SeaMonkey :: General, defect)

SeaMonkey 2.25 Branch
defect
Not set
normal

Tracking

(seamonkey2.26 wontfix, seamonkey2.27 wontfix, seamonkey2.28 affected, seamonkey2.29 fixed, seamonkey2.30 fixed, seamonkey2.31 fixed)

RESOLVED FIXED
seamonkey2.31
Tracking Status
seamonkey2.26 --- wontfix
seamonkey2.27 --- wontfix
seamonkey2.28 --- affected
seamonkey2.29 --- fixed
seamonkey2.30 --- fixed
seamonkey2.31 --- fixed

People

(Reporter: wade_reese, Assigned: philip.chee)

References

Details

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 (Beta/Release)
Build ID: 20140318183546

Steps to reproduce:

I attempt to access my email and SM crashes... every time. 

I downgraded back to 2.24 and SM (and email access) works just fine.

Did a second upgrade to 2.25 this morning... and I get the same crash problem. 


Actual results:

SM crashes.

SM then asks to submit a report (which I have done) and if I want to restart SM.  The same cycle repeats.  Downgrading to 2.24 is my only fix.


Expected results:

I should be able to access my email accounts... and my individual email.
This is the crash report:

AdapterDeviceID: 0x9583
AdapterVendorID: 0x1002
Add-ons: modern%40themes.mozilla.org:2.25
BuildID: 20140318183546
Comments: See Bugzilla report that I just submitted on this issue.
CrashTime: 1395419374
EMCheckCompatibility: true
Email: wade_reese@mac.com
FramePoisonBase: 7ffffffff0dea000
FramePoisonSize: 4096
InstallTime: 1395383581
Notes: AdapterVendorID: 0x1002, AdapterDeviceID: 0x9583GL Layers! GL Context? GL Context+ GL Layers+ 
ProductID: {92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
ProductName: SeaMonkey
ReleaseChannel: release
SecondsSinceLastCrash: 772
StartupTime: 1395418605
Theme: modern/1.0
Throttleable: 1
Vendor: Mozilla
Version: 2.25
useragent_locale: en-US

This report also contains technical information about the state of the application when it crashed.
Crash ID URL (about:crashes) ?

Pop or IMAP?
Not sure what you mean by "crash ID URL"?

But re: POP or IMAP, I have email accounts that are both in my SeaMonkey configuration.
(In reply to Wade Reese from comment #3)
> Not sure what you mean by "crash ID URL"?

Go to about:crashes The links there are clickable. Cut and paste the latest links (at the top of the list) and paste them here in a commant.
OK... but regarding "Go to about:crashes" where do I find this?
It's variously called the ur-lbar, location-bar. Firefox calls it the Awesomebar. The text box at the top where you type in urls like, you know, www.google.com

about:crashes calls up an internal page with all the recent crashes. This assumes that the SeaMonkey crash reporter started up after the crash and you allowed it to send the crash data to the Mozilla crash-report servers.

Other about: pages you can try: about:mozilla  about:life
Here you go:

This was from yesterday.  Let me know is you would like me to run 2.25 again (I am back to 2.24 now) and get another crash report.

==================================================================

ID: 1ffa4261-c427-4b98-b8f4-0a8812140321
Signature: nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*)

    Details
    Metadata
    Modules
    Raw Dump
    Extensions
    Correlations

Signature 	nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*) More Reports Search
UUID 	1ffa4261-c427-4b98-b8f4-0a8812140321
Date Processed	2014-03-21 16:31:09.197144
Uptime	769
Last Crash	772 seconds before submission
Install Age 	35793 since version was first installed.
Install Time 	2014-03-21 06:33:01
Product 	SeaMonkey
Version 	2.25
Build ID 	20140318183546
Release Channel 	release
OS 	Mac OS X
OS Version 	10.9.2 13C64
Build Architecture 	amd64
Build Architecture Info 	family 6 model 15 stepping 10 | 2
Crash Reason 	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address 	0x0
User Comments 	See Bugzilla report that I just submitted on this issue.
App Notes 	

AdapterVendorID: 0x1002, AdapterDeviceID: 0x9583GL Layers! GL Context? GL Context+ GL Layers+ 

Processor Notes 	sp-processor09_phx1_mozilla_com.16777:2012; HybridCrashProcessor
EMCheckCompatibility 	

True

Winsock LSP 	

Adapter Vendor ID 	

0x1002

Adapter Device ID 	

0x9583

Bugzilla - Report this bug in SeaMonkey Core Plugins Toolkit
Related Bugs

    976449 RESOLVED DUPLICATE Seamonkey crashes immediately if there is no mail window open, and you click on a 'New Mail' alert pop-up
    964182 NEW --- After landing of Bug 920725 fix SM, Thunderbird and Firefox still crashing with same signature
    920725 VERIFIED FIXED crash in nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*)

Crashing Thread
Frame 	Module 	Signature 	Source
0 	XUL 	nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*) 	parser/html/nsHtml5StreamParser.cpp
1 	XUL 	nsHtml5StreamParser::SetupDecodingAndWriteSniffingBufferAndCurrentSegment(unsigned char const*, unsigned int, unsigned int*) 	parser/html/nsHtml5StreamParser.cpp
2 	XUL 	nsHtml5StreamParser::SniffStreamBytes(unsigned char const*, unsigned int, unsigned int*) 	parser/html/nsHtml5StreamParser.cpp
3 	XUL 	nsHtml5StreamParser::DoDataAvailable(unsigned char const*, unsigned int) 	parser/html/nsHtml5StreamParser.cpp
4 	XUL 	nsHtml5StreamParser::CopySegmentsToParser(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) 	parser/html/nsHtml5StreamParser.cpp
5 	XUL 	nsInputStreamTee::WriteSegmentFun(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) 	xpcom/io/nsInputStreamTee.cpp
6 	XUL 	nsPipeInputStream::ReadSegments(tag_nsresult (*)(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) 	xpcom/io/nsPipe3.cpp
7 	XUL 	nsHtml5StreamParser::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long long, unsigned int) 	parser/html/nsHtml5StreamParser.cpp
8 	XUL 	nsStreamListenerTee::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long long, unsigned int) 	netwerk/base/src/nsStreamListenerTee.cpp
9 	XUL 	mozilla::net::nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long long, unsigned int) 	netwerk/protocol/http/nsHttpChannel.cpp
10 	XUL 	nsInputStreamPump::OnStateTransfer() 	netwerk/base/src/nsInputStreamPump.cpp
11 	XUL 	nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) 	netwerk/base/src/nsInputStreamPump.cpp
12 	XUL 	nsInputStreamReadyEvent::Run() 	xpcom/io/nsStreamUtils.cpp
13 	XUL 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
14 	XUL 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp
15 	XUL 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp
16 	libnss3.dylib 	_pt_root 	
17 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x1899 	
18 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x172a 	
19 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x5fc9 	
20 	libnss3.dylib 	null_signal_handler 	

Show/hide other threads
Linked: https://crash-stats.mozilla.com/report/index/1ffa4261-c427-4b98-b8f4-0a8812140321

Three related:

Bug 976449 is DUP'd to 964182
Bug 964182

Bug 920725 marked as Fixed

So probably ought to DUP this to 964182 ?
Hi... I don't think this is the same as the other ticket as the other ticket is old and this problem just started with 2.25 (just the other day).  I upgraded from 2.24 to 2.25.  Produced another crash report for your review.

Here is a new crash report:


Mozilla Crash Reports
Search

    Product:
    Select Version:
    Report:

Advanced Search - Super Search
SeaMonkey 2.25 Crash Report [@ nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*) ]
Search Mozilla Support for Help
ID: 1d9edd9b-0bb7-43dd-86ec-92ca82140324
Signature: nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*)

    Details
    Metadata
    Modules
    Raw Dump
    Extensions
    Correlations

Signature 	nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*) More Reports Search
UUID 	1d9edd9b-0bb7-43dd-86ec-92ca82140324
Date Processed	2014-03-24 21:47:19.238377
Uptime	172
Last Crash	220 seconds before submission
Install Age 	314015 since version was first installed.
Install Time 	2014-03-21 06:33:01
Product 	SeaMonkey
Version 	2.25
Build ID 	20140318183546
Release Channel 	release
OS 	Mac OS X
OS Version 	10.9.2 13C64
Build Architecture 	amd64
Build Architecture Info 	family 6 model 15 stepping 10 | 2
Crash Reason 	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address 	0x0
User Comments 	This goes with (URL removed)
App Notes 	

AdapterVendorID: 0x1002, AdapterDeviceID: 0x9583GL Layers! GL Context? GL Context+ GL Layers+ 

Processor Notes 	sp-processor07_phx1_mozilla_com.8623:2012; HybridCrashProcessor
EMCheckCompatibility 	

True

Winsock LSP 	

Adapter Vendor ID 	

0x1002

Adapter Device ID 	

0x9583

Bugzilla - Report this bug in SeaMonkey Core Plugins Toolkit
Related Bugs

    976449 RESOLVED DUPLICATE Seamonkey crashes immediately if there is no mail window open, and you click on a 'New Mail' alert pop-up
    964182 NEW --- After landing of Bug 920725 fix SM, Thunderbird and Firefox still crashing with same signature
    920725 VERIFIED FIXED crash in nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*)

Crashing Thread
Frame 	Module 	Signature 	Source
0 	XUL 	nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*) 	parser/html/nsHtml5StreamParser.cpp
1 	XUL 	nsHtml5StreamParser::SetupDecodingAndWriteSniffingBufferAndCurrentSegment(unsigned char const*, unsigned int, unsigned int*) 	parser/html/nsHtml5StreamParser.cpp
2 	XUL 	nsHtml5StreamParser::SniffStreamBytes(unsigned char const*, unsigned int, unsigned int*) 	parser/html/nsHtml5StreamParser.cpp
3 	XUL 	nsHtml5StreamParser::DoDataAvailable(unsigned char const*, unsigned int) 	parser/html/nsHtml5StreamParser.cpp
4 	XUL 	nsHtml5StreamParser::CopySegmentsToParser(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) 	parser/html/nsHtml5StreamParser.cpp
5 	XUL 	nsInputStreamTee::WriteSegmentFun(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*) 	xpcom/io/nsInputStreamTee.cpp
6 	XUL 	nsPipeInputStream::ReadSegments(tag_nsresult (*)(nsIInputStream*, void*, char const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) 	xpcom/io/nsPipe3.cpp
7 	XUL 	nsHtml5StreamParser::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long long, unsigned int) 	parser/html/nsHtml5StreamParser.cpp
8 	XUL 	nsStreamListenerTee::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long long, unsigned int) 	netwerk/base/src/nsStreamListenerTee.cpp
9 	XUL 	mozilla::net::nsHttpChannel::OnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long long, unsigned int) 	netwerk/protocol/http/nsHttpChannel.cpp
10 	XUL 	nsInputStreamPump::OnStateTransfer() 	netwerk/base/src/nsInputStreamPump.cpp
11 	XUL 	nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) 	netwerk/base/src/nsInputStreamPump.cpp
12 	XUL 	nsInputStreamReadyEvent::Run() 	xpcom/io/nsStreamUtils.cpp
13 	XUL 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
14 	XUL 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp
15 	XUL 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp
16 	libnss3.dylib 	_pt_root 	
17 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x1899 	
18 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x172a 	
19 	libsystem_pthread.dylib 	libsystem_pthread.dylib@0x5fc9 	
20 	libnss3.dylib 	null_signal_handler 	

Show/hide other threads
Mozilla Crash Reports - Powered by Socorro - All dates are UTC

    Server Status
    API Documentation
    API Tokens
    Project Info
    Source Code
    Breakpad Wiki
    Privacy Policy

    Sign in
Wade, next time just post the link like:  https://crash-stats.mozilla.com/report/index/https://crash-stats.mozilla.com/report/index/1d9edd9b-0bb7-43dd-86ec-92ca82140324

OK?
Crash Signature: [@ nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*) ]
And if you revert back to SeaMonkey 2.24, does that work properly?
http://www.seamonkey-project.org/releases/2.24
Yes, reverting back to 2.24 eliminates the crash.

FYI, I upgraded back from 2.24 to 2.25 this morning and had mail crash again. I saved the link this time.  Here you go:  

https://crash-stats.mozilla.com/report/index/906227eb-8c6d-463c-9c50-7cd7d2140325
Thanks. No need to post any more links. I'm pretty certain it's Bug 964182 - After landing of Bug 920725 fix SM, Thunderbird and Firefox still crashing with same signature
Depends on: 964182
OK.

But just to be clear... I have never seen this in 2.24 or earlier builds.

As it is, 2.25 is unusable for me.  I will just stick with 2.24.

Regards,

Wade
Dear Sirs,

Is this ticket closed now or are you guys still working on it?

Regards,

Wade
(In reply to Wade Reese from comment #16)
> Is this ticket closed now or are you guys still working on it?

This ticket is still open. The SeaMonkey team is not working on it. It is a core bug so the Core::HTLM::Parser developers are looking into it in Bug 964182 and/or Bug 960519. Those are the bugs to follow (or complain in) if you want to track the progress.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hi
i have exactly the same problem with Seamonkey 2.25 : impossible to consult the mail boxes.
It's crash everytime. Back to 2.24 !
Hi Philip,

I see that there is another Bug that is to be tracked... but I have a question.

That Bug goes back to 1/14.  I never had the my bug then.  This one only started with 2.25 (in 3/14).  Do you really think that they are the same bug?

Regards,

Wade
(In reply to Wade Reese from comment #19)

> That Bug goes back to 1/14.  I never had the my bug then.  This one only
> started with 2.25 (in 3/14).  Do you really think that they are the same bug?

I'm not sure. Several different bugs can have the same crash signature. We can only hope.
FYI... As of yesterday:

I just tried 2.26 and the mail potion of that release still crashes.  I, again, reverted back to 2.24.  Everything was fine in 2.24 after the downgrade.

Just thought that you should know.

Regard,

Wade
I confirm, 2.26 is unusable for me and still crashes when i open Mail.
I can use only the version 2.24. Is anyone working for fixing this ?
Comment22... good question.
2.26.1 has the same problem (Mail crashes the app).  

Hoping that 2.27 will finally fix this.  Probably not so good to be stuck in 2.24.

Here is the crash report:

AdapterDeviceID: 0x9583
AdapterVendorID: 0x1002
Add-ons: modern%40themes.mozilla.org:2.26.1
BuildID: 20140612182257
CrashTime: 1403204123
EMCheckCompatibility: true
Email: wade_reese@brandx.net
FramePoisonBase: 7ffffffff0dea000
FramePoisonSize: 4096
InstallTime: 1403203930
Notes: AdapterVendorID: 0x1002, AdapterDeviceID: 0x9583GL Layers! GL Context? GL Context+ GL Layers+ 
ProductID: {92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}
ProductName: SeaMonkey
ReleaseChannel: release
SecondsSinceLastCrash: 83
StartupTime: 1403204056
Theme: modern/1.0
Throttleable: 1
Vendor: Mozilla
Version: 2.26.1
useragent_locale: en-US

This report also contains technical information about the state of the application when it crashed.
Similar problem to the above comments.  Upgraded 2.24 this morning to 2.26.1 and two times while trying to open message in preview pane Mail crashed.

Here are the two crash reports that were filed before I uninstalled 2.26.1 and reverted to 2.24, which appears to be functioning normally as it did before the upgrade.

http://crash-stats.mozilla.com/report/index/bp-0cbee1ad-ea8e-4f33-a9ca-1b4272140626

http://crash-stats.mozilla.com/report/index/bp-2bd984f2-aae9-4a27-a760-a325c2140626
I can confirm that the issue still exists as of today (7/14/14).

Is this still on someone's radar screen?
(In reply to Wade Reese from comment #27)
> Is this still on someone's radar screen?
It's hard to fix something if the developers are not able to reproduce the crash locally.

Related Bugs

Bug 986548 NEW --- SeaMonkey 2.25 always crashes when trying to access email
Bug 976449 REOPENED --- Seamonkey crashes immediately if there is no mail window open, and you click on a 'New Mail' alert pop-up
Bug 964182 NEW --- After landing of Bug 920725 fix SM, Thunderbird and Firefox still crashing with same signature
Bug 920725 VERIFIED FIXED crash in nsHtml5StreamParser::WriteStreamBytes(unsigned char const*, unsigned int, unsigned int*)
Hi Philip,

I get that.  Is there something that I can do to help the developers reproduce the crash?  Glad to try.

Regards,

Wade

PS, is this bug rare?  I have been wondering that for a while, because I figure that if it were common every Seamonkey user would be going nuts.  Makes 2.25-2.26 unusable for anything but browsing.
IIRC A lot of SeaMonkey users use SM for browsing and TB for mail & newsgroups.
Possible workaround. bug 976449 Comment 12
See Also: → 976449
I see.  Interesting.  I would have thought that the sole reason to use SM was to have a single browser/email client, and folks that use Thunderbird would just move to Firefox for browsing.  Shows what I know.  ;-)
I did have the same problem with a previous version -- I think it was 2.23 and I did not report, I just uninstalled and went back to 2.22.  When 2.24 came out the problem was gone -- until 2.25, 2.26 and 2.26.1, so this latest incarnation is not new to me.  And yes, I use SM because of the integration of browser, email client and composer.  SM is a most valued tool for me and I await the solution to this bug.  I am not that bright about software but will contribute to the solution if I am able.
To those working on the problem, thank you.
Hi Phil,

I just read comment 12 in that other bug report and I am confused.  Here it is:

"Probably my final word on this for a bit, since I have found a workaround. Seamonkey DOES NOT CRASH if there is no mail window open, and I have the message pane enabled, and I click on an e-Mail alert:

IFF the preference

mailnews.start_page.enabled = false

Since I don't care about the start_page (described above as 'flannel') I don't consider this to be an inconvenience.

I deduce that the alert-handling code knows about a problem displaying to a pane for the first time, but incorrectly assumes that the pane has been used already if mailnews.start_page.enabled = true, when the mail window hasn't been opened before the alert is clicked.

If no one responds, I will eventually investigate this hypothesis myself."

I have to admit, I am having a hard time following the above instructions.  Also, My problem is on a Mac so I am not sure that this applies.  Can you maybe say the above in another way so that I can try the fix?

Thanks,

Wade
OK, I will have another go.

Enter about:config in the address bar.

Click "I'll be careful, I promise" if asked by a warning page.

Enter 'mailnews.start_page.enabled' into the search box.

If it displays 'true', there is hope. Right click on the line, and select toggle.

Launch mail, and see what happens.

The other thing that works for me is disabling the message pane in the three pane view, but I did that using the View->Layout->Message Pane menu toggle in the Mail window. If you can't even get the Mail window up, I don't know how, if at all, you can do this with about:config.

I am using Linux rather than a Mac, but the nature of the bug on Linux (trying to render HTML without first specifying the character set to use) seems quite likely not to be OS-specific.
Thanks David, I can follow that rewrite above.  I will give that a try.
SUCCESS!

I upgraded to 2.26.1 and followed the steps above through "...and select toggle."  NO CRASH upon opening mail.  Perfect.

Thanks a million.

One question.  Will I need to do this for each update from now on?  If so, I want to keep these instructions in a safe place.  Thanks again. 

Regards,

Wade
Usually you won't need to re-do it after an upgrade. If you look in the file

~/.mozilla/seamonkey/*.default/prefs.js

you will find a line

user_pref("mailnews.start_page.enabled", false);

Other lines there define your SMTP connection. The SMTP settings are usually preserved from release to release, so I would expect the above preference to be preserved as well.

However, sometimes a new release changes the valid preferences so radically that things that you set disappear. You can protect the line from ever being over-ridden by putting

user_pref("mailnews.start_page.enabled", false);

in the file user.js in the same directory. No new release ever changes anything in user.js.
David, I upgraded 2.24 with 2.26.1 as per your instructions on Comment #35.  After installing SM using the full-installer file, I launched SM Mail (no browser open), clicked on the inbox for the first profile and SM crashed immediately.
I then reopened SM browser, used your instructions to change 'mailnews.start_page.enabled' to False and now the mail works, except of course, the pre-view pane no longer works.
To expand on Comments 37 & 38, when this is fixed will we have to manually change the preference back to regain the functionality?  It is helpful but not essential to how I use SM.
And finally, I'll see Wades million thank yous and raise another million.
This is the url for the crash I experienced this morning: https://crash-stats.mozilla.com/report/index/fdabd4e2-f05c-4b49-9bad-d2c242140723
SUCCESS TOO !

Thank you for this solution !!!
I upgraded with success from 2.24 to 2.26.1

For info, if you want to try to reproduce the bug :
Before this solution, i had an external default start page for mails : http://www.yopmail.com/
(In reply to bugzilla from comment #40)
> For info, if you want to try to reproduce the bug :
> Before this solution, i had an external default start page for mails :
> http://www.yopmail.com/

Thanks; the setting of an external start page is necessary to reproduce the bug, because internal pages are always UTF-8.

The cause in SeaMonkey is something that used to work, but internal expectations changed and nobody told us.

Back in 2001 (!) in bug 59787, the start page needed to clear the forced charset on the document viewer. It did this by setting the charset to the empty string. Then in 2004 in bug 258447, Thunderbird backed out that change from its fork.

Later in 2004 in bug 253807, mailnews use of the forced charset was then briefly changed to the default charset, then the hint charset.

Unlike the forced charset, which needed to be non-empty to take effect, the hint charset always takes effect. Now somewhere along the line I assume someone used to check the hint charset too, but now it never gets checked, and the empty value propagates down into the HTML5 parser which fails to create a decoder.
(In reply to comment #41)
> The cause in SeaMonkey is something that used to work, but internal
> expectations changed and nobody told us.

So, prior to bug 919935, if the hint charset was empty, the HTML5 parser would fall back to windows-1252. Now it just crashes.
Depends on: 919935
In which case, can we propose that, when provided with the empty string, the parser substitutes UTF-8? Or at the very least, crashes out at that point? We currently have the worst of all possible worlds. The parser currently follows a course of action that guarantees that it will crash, but postpones the crash until an indeterminate time after the action (providing an empty string character set) that is the root cause of the crash, thus allowing this really serious bug to hang around for months and months.
I tested Thunderbird with http://www.yopmail.com/ and TB doesn't crash. Could we do what TB did back then and back out bug 59787?
(In reply to Philip Chee from comment #44)
> I tested Thunderbird with http://www.yopmail.com/ and TB doesn't crash.
> Could we do what TB did back then and back out bug 59787?

Seems to be the easiest thing to try, and unlikely to cause any regressions given that Thunderbird's been running like that for years.
Don't clear the charset.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Attachment #8464252 - Flags: review?(neil)
No longer depends on: 964182
Attachment #8464252 - Flags: review?(neil) → review+
(In reply to David Edwards from comment #43)
> In which case, can we propose that, when provided with the empty string, the
> parser substitutes UTF-8?

No, that would hide bugs.

> Or at the very least, crashes out at that point?

I'd be OK with making the parser MOZ_ASSERT non-emptiness of mCharset early.
The field platform should be changed : I have this bug on Linux i686 (PAE).
(In reply to Stéphane Grégoire (yamo) from comment #51)
> The field platform should be changed : I have this bug on Linux i686 (PAE).
Done. If you have CANCONFIRM privileges I think you can do that yourself.
OS: Mac OS X → All
Hardware: x86 → All
Comment on attachment 8464252 [details] [diff] [review]
Patch v1.0 Proposed fix

[Triage Comment]
a=me
Attachment #8464252 - Flags: approval-comm-release+
Attachment #8464252 - Flags: approval-comm-beta+
Attachment #8464252 - Flags: approval-comm-aurora+
Pushed to comm-central comm-aurora comm-beta
http://hg.mozilla.org/comm-central/rev/f4fb90bd05f7
http://hg.mozilla.org/releases/comm-aurora/rev/97fa08976704
http://hg.mozilla.org/releases/comm-beta/rev/ca9a5b1ec62e
Callek says he'll merge beta to release so the fix will propagate to -release
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.31
You need to log in before you can comment on or make changes to this bug.