Closed
Bug 448329
Opened 17 years ago
Closed 16 years ago
Browser crashes after hitting the "tab" key within Smatermail webmail app [@ nsHTMLEditor::GetCSSBackgroundColorState]
Categories
(Core :: DOM: Editor, defect, P2)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
People
(Reporter: eneerge, Assigned: MatsPalmgren_bugz)
References
Details
(4 keywords, Whiteboard: [sg:dos] null-pointer access)
Crash Data
Attachments
(5 files, 2 obsolete files)
|
10.84 KB,
text/plain
|
Details | |
|
3.05 KB,
patch
|
peterv
:
review+
peterv
:
superreview+
roc
:
approval1.9.1+
dveditz
:
approval1.9.0.9+
|
Details | Diff | Splinter Review |
|
1.45 KB,
text/html
|
Details | |
|
439 bytes,
text/html
|
Details | |
|
5.67 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008071717 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008071717 Firefox/3.0.1
I've experienced a crash 100% time whenever I hit the "tab" key whenever I am composing an e-mail message from my server's webmail interface.
The mail server is SmarterMail 5 available at www.smartertools.com. I've been able to determine that the "tab" key seems to be a good synonym for the "crash" key while I'm typing an e-mail. Everytime, Firefox just closes out completely whenever I forget and hit "tab".
Reproducible: Always
Steps to Reproduce:
1. Compose New E-mail
2. Hit tab in the body of the message
Actual Results:
Firefox shuts down and does not display any kind of error message.
Expected Results:
Hope that I would notice 5 spaces rather than a crash
If anyone needs temporary access to my mail server to see if they can reproduce the problem, I can set up a temporary account with limited access so you can access the webmail interface.
Comment 1•17 years ago
|
||
Please run Firefox in the Firefox safemode :
- http://kb.mozillazine.org/Safe_mode
If you still lget this problem you must provide a stacktrace. How you can generate a stacktarce depends on the build you are using.
Mozilla.org binary builds are coming with a crash reporter, send the report and enter about:crashes in Firefox to get the crash id.
If you are using a build from somewhere else or selfcompiled then you must use your tools from your distribution to generate a stack trace with debug symbols
| Assignee | ||
Comment 2•17 years ago
|
||
>I can set up a temporary account with limited access so you can
>access the webmail interface.
Yes, please.
| Assignee | ||
Comment 3•17 years ago
|
||
> Firefox shuts down and does not display any kind of error message.
Please start Firefox from a command line window and report if you see
any error messages there when the crash occurs.
I've tried performing an strace and also running firefox from command line. The results are similar, but the strace gave a little more information.
I'm getting a segmentation fault in terminal whenever the crash occurs. When logging firefox with strace, I notice a line near the end that gives this output:
[pid 6984] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 6984] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 7000] +++ killed by SIGSEGV +++
Process 7000 detached
[pid 7001] +++ killed by SIGSEGV +++
Process 7001 detached
[pid 7004] +++ killed by SIGSEGV +++
Process 7004 detached
[pid 7005] +++ killed by SIGSEGV +++
Process 7005 detached
[pid 7017] +++ killed by SIGSEGV +++
Process 7017 detached
[pid 6995] +++ killed by SIGSEGV +++
Process 6995 detached
[pid 6996] +++ killed by SIGSEGV +++
Process 6996 detached
Process 6984 detached
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6995 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6995 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6996 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6995 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6995 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6995 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6995 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6995 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6995 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6996 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=6984 runs in 64 bit mode. ]
[ Process PID=7007 runs in 32 bit mode. ]
[ Process PID=7006 runs in 64 bit mode. ]
I also tried running firefox in safe mode. I received the same result.
I have setup a temporary account. I've e-mail everyone in the CC list the login information. If anyone else needs the information that didn't get it, e-mail me.
| Assignee | ||
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
Flags: wanted1.9.0.x?
Keywords: crash,
regression
OS: Linux → All
Product: Firefox → Core
QA Contact: general → editor
Hardware: PC → All
Summary: Browser crashes after hitting the "tab" key within Smatermail webmail app → Browser crashes after hitting the "tab" key within Smatermail webmail app [@ nsHTMLEditor::GetCSSBackgroundColorState]
Whiteboard: [sg:nse] null-pointer access
Version: unspecified → 1.9.0 Branch
| Assignee | ||
Updated•17 years ago
|
Flags: wanted1.9.1?
| Assignee | ||
Comment 7•17 years ago
|
||
nsHTMLEditor::GetCSSBackgroundColorState
nsHTMLEditor::GetBackgroundColorState
nsBackgroundColorStateCommand::GetCurrentState
nsMultiStateCommand::GetCommandStateParams
nsControllerCommandTable::GetCommandState
nsBaseCommandController::GetCommandStateWithParams
nsCommandManager::GetCommandState
nsHTMLDocument::QueryCommandState
NS_InvokeByIndex_P
XPCWrappedNative::CallMethod
...
| Assignee | ||
Comment 8•17 years ago
|
||
The reason for 'blockParent' being null is that the selection start node
is the document node. This patch makes the code a bit more robust.
(I suspect this could also happen if the start node is <html>)
Still, there are two more problems when tabbing from this position:
1. the caret dissappears
2. the spaces are inserted at the end of the document
| Assignee | ||
Comment 9•17 years ago
|
||
| Assignee | ||
Comment 10•17 years ago
|
||
The first patch asserts with the attached testcase:
###!!! ASSERTION: we reached a null node ancestor !: 'node', file editor/libeditor/html/nsHTMLCSSUtils.cpp, line 1421
This patch avoids that assert (and fixes a "unhandled enum value in switch"
compile warning).
| Assignee | ||
Comment 11•17 years ago
|
||
Bug 371882 and/or bug 271130 could be the same crash.
| Assignee | ||
Comment 12•17 years ago
|
||
(Forgot to remove enablePrivilege('UniversalXPConnect') which isn't needed)
Attachment #331695 -
Attachment is obsolete: true
Updated•17 years ago
|
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Flags: wanted1.9.1? → blocking1.9.1+
Priority: -- → P3
Comment 13•17 years ago
|
||
Here's a reduced version of the earlier testcase. It crashes my linux mozilla-central debug build. It also fails this assertion, just before the crash:
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../dist/include/xpcom/nsCOMPtr.h, line 796
Updated•17 years ago
|
Attachment #341695 -
Attachment description: testcase 2 → testcase 2 (crashes Firefox)
Updated•16 years ago
|
Assignee: nobody → mats.palmgren
Whiteboard: [sg:nse] null-pointer access → [sg:nse] null-pointer access [has wip patch]
So why is this "wip2" work in progress and not complete? What's left to finish?
Version: 1.9.0 Branch → Trunk
| Assignee | ||
Comment 15•16 years ago
|
||
IIRC, I wanted to check all consumers of GetBlockNodeParent() that
they don't crash on null. I've done that now and it appears to be ok.
| Assignee | ||
Comment 16•16 years ago
|
||
The attached testcases as crash tests, plus a testcase that
tests some of the GetBlockNodeParent() paths in
nsHTMLEditor::SetCSSBackgroundColor().
| Assignee | ||
Updated•16 years ago
|
Attachment #331696 -
Flags: superreview?(peterv)
Attachment #331696 -
Flags: review?(peterv)
| Assignee | ||
Updated•16 years ago
|
Attachment #331687 -
Attachment is obsolete: true
| Assignee | ||
Updated•16 years ago
|
Whiteboard: [sg:nse] null-pointer access [has wip patch] → [sg:dos] null-pointer access
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
Peterv, we could use a review here --- we still really want this fix.
Actually I think we should possibly really-block on this since it's a crash regression in a real site.
Flags: blocking1.9.1- → blocking1.9.1?
Comment 18•16 years ago
|
||
Not blocking, but would take a fix, potentially even on branch.
Flags: blocking1.9.1? → blocking1.9.1-
Since we have a patch, and it is a crash regression on a real site that's easy to trigger, I really do think we should block.
Updated•16 years ago
|
Attachment #331696 -
Flags: superreview?(peterv)
Attachment #331696 -
Flags: superreview+
Attachment #331696 -
Flags: review?(peterv)
Attachment #331696 -
Flags: review+
Attachment #331696 -
Flags: approval1.9.1+
Whiteboard: [sg:dos] null-pointer access → [sg:dos] null-pointer access [needs landing]
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
Priority: P3 → P2
Keywords: checkin-needed
Mats, I'm going to check this in for you, hope that's OK.
Pushed http://hg.mozilla.org/mozilla-central/rev/2d759ec1998c and http://hg.mozilla.org/mozilla-central/rev/6953f45b3c82 for the tests.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [sg:dos] null-pointer access [needs landing] → [sg:dos] null-pointer access [needs 191 landing]
| Assignee | ||
Comment 22•16 years ago
|
||
Keywords: fixed1.9.1
Whiteboard: [sg:dos] null-pointer access [needs 191 landing] → [sg:dos] null-pointer access
| Assignee | ||
Updated•16 years ago
|
Attachment #331696 -
Flags: approval1.9.0.8?
Updated•16 years ago
|
Attachment #331696 -
Flags: approval1.9.0.8? → approval1.9.0.8+
Comment 23•16 years ago
|
||
Comment on attachment 331696 [details] [diff] [review]
wip2
Approved for 1.9.0.8, a=dveditz for release-drivers
| Assignee | ||
Comment 24•16 years ago
|
||
mozilla/editor/libeditor/html/crashtests/448329-1.html 1.1
mozilla/editor/libeditor/html/crashtests/448329-2.html 1.1
mozilla/editor/libeditor/html/crashtests/448329-3.html 1.1
mozilla/editor/libeditor/html/crashtests/crashtests.list 1.6
mozilla/editor/libeditor/html/nsHTMLCSSUtils.cpp 1.45
mozilla/editor/libeditor/html/nsHTMLEditor.cpp 1.569
Keywords: fixed1.9.0.8
Comment 25•16 years ago
|
||
Verified for 1.9.0.8 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.8pre) Gecko/2009031904 GranParadiso/3.0.8pre using testcases. 1.9.0.7 crashes reliably.
Verified for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090317 Shiretoko/3.1b4pre.
Comment 26•16 years ago
|
||
I think this also fixes http://www.milw0rm.com/exploits/8219.
Updated•14 years ago
|
Crash Signature: [@ nsHTMLEditor::GetCSSBackgroundColorState]
You need to log in
before you can comment on or make changes to this bug.
Description
•