Closed
Bug 187548
Opened 22 years ago
Closed 22 years ago
Editing or saving page with some given CSS crashes Mozilla
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: Erich.Iseli, Assigned: dbaron)
References
Details
(Keywords: crash, stackwanted, testcase)
Attachments
(1 file, 1 obsolete file)
(deleted),
text/html
|
Details |
I've been trying to reproduce this bug and strip it down to a very basic
testcase. I haven't managed so far and I will still continue and attach the
testcase.
Basically there are three different situations (note that I tested this with a
local file, I don't know how it will behave as a remote file):
a) load the page (attachment) in the browser. Press Ctrl-E to edit
=> Crash
b) Open the editor with Ctrl-4 (or Window > Composer) and load the page
=> NO crash
c) Do step b and then add a space somewhere (just in order to modify the page)
then press Ctrl-S (or File > Save)
=> Crash. File was not saved. Dataloss
The talkback ID's I've sent in so far are the following:
TB15731936Z
TB15732106Y
TB15732122Q
TB15732206W
TB15732214E
TB15732260K
TB15732310W
TB15732313E
TB15732314Y
Reporter | ||
Comment 1•22 years ago
|
||
Here's the attachment I was talking about in Comment 0
However, I haven't yet been able to strip it down in order to call it a minimal
testcase.
Comment 2•22 years ago
|
||
stephend, could you get a stack?
Unfortunately, the only information Talkback is returning for any one of these
incidents is the following:
Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
(not very helpful, sorry!)
Reporter | ||
Comment 4•22 years ago
|
||
Ok, now I have a simple testcase. It was not about the double-byte characters
(hangul), I also could reproduce that with plain english text. Obviously, the
following things are needed in order to reproduce the bug:
- a simple definition list
- a css-rule for the definition term
- a css-rule for the definition term:after and generating some content.
There is no crash if the dt:after rule is not there.
There's no crash either if the dt:after is there but there's no dt selector.
Keywords: testcase
Summary: Editing or saving page containing double-byte characters (hangul) and some given CSS crashes Mozilla → Editing or saving page with some given CSS crashes Mozilla
Reporter | ||
Comment 5•22 years ago
|
||
Simplified testcase as described in Comment 4
Attachment #110572 -
Attachment is obsolete: true
Reporter | ||
Comment 6•22 years ago
|
||
With the minimal testcase, it doesn't crash any more if I'm pressing Ctrl-E to
edit the page. Only if I edit its source and try to save it, mozilla crashes.
Raising severity since there's crash and dataloss involved.
Severity: normal → critical
Updated•22 years ago
|
Keywords: stackwanted
Comment 7•22 years ago
|
||
> Trigger Reason SIGSEGV: Segmentation Fault: (signal 11)
bug 176886: linux/talkback is busted.
worksforme with linux trunk build 20030104. did Ctrl-E on the first testcase
and save the second one without crashing.
do you crash with a clean profile? what build are you using?
Keywords: dataloss
Reporter | ||
Comment 8•22 years ago
|
||
Andrew Schultz, I'm seeing this in both Mozilla 1.3a as well as in the latest
nightly (2003-01-04-04).
The exact steps to reproduce:
1. Load the attachment in the browser (new window, tab, same window - doesn't
matter)
2. Save the file locally
3. Load the local file
4. Press Ctrl-E to edit the page (can't reproduce the crash here as well)
5. Go the HTML-Source tab
6. Add a space in the source code
7. Press Ctrl-S to save
Result: Crash, file was not saved
Expected result: no crash, file should save normally
Comment 9•22 years ago
|
||
Well, I got this to crash in gdb under linux....
#0 0xdddddddd in ?? ()
#1 0x42011f5f in nsCSSFrameConstructor::StyleChangeReflow (this=0x8a7ed68,
aPresContext=0x88100f8, aFrame=0x8a93598, aAttribute=0x0)
at
/home/bzbarsky/mozilla/profile/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:10211
#2 0x420124bd in nsCSSFrameConstructor::ProcessRestyledFrames (this=0x8a7ed68,
aChangeList=@0xbfff72bc, aPresContext=0x88100f8)
at
/home/bzbarsky/mozilla/profile/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp:10333
#3 0x41f960d7 in PresShell::ReconstructStyleData (this=0x8a7ee58,
aRebuildRuleTree=1)
at
/home/bzbarsky/mozilla/profile/mozilla/layout/html/base/src/nsPresShell.cpp:5394
#4 0x41f962e9 in PresShell::StyleSheetRemoved (this=0x8a7ee58,
aDocument=0x8a5ec18,
aStyleSheet=0x8a85850)
Looks like bug 187671
Depends on: 187671
Reporter | ||
Comment 10•22 years ago
|
||
I don't know. Could be. According to this comment
http://bugzilla.mozilla.org/show_bug.cgi?id=187671#c4 it regressed between
2002092921 and 2002100104. I don't have such old nightlies and I couldn't
download anyone of these (they're no longer on the ftp server -- or did I miss
anything?).
Anyways, I could reproduce that too with my oldest build I have that is:
2002110304. Can anyone try to reproduce this bug in both 2002092921 and 2002100104?
Comment 11•22 years ago
|
||
reassigning
Assignee: jfrancis → dbaron
Component: Editor: Core → Style System
QA Contact: sujay → ian
Comment 12•22 years ago
|
||
Is this related to 166596?
Reporter | ||
Comment 13•22 years ago
|
||
I don't think this is related to bug 166596. As a matter of fact, that one
mentions problems with Netscape 7.
I've tried to reproduce this bug with Netscape 7 and 7.01
Netscape 7.0 (build ID 2002-08-23): no crash. couldn't repro
Netscape 7.01 (build ID 2002-11-20): no crash. couldn't repro
Don't forget that Netscape 7.0x is building on the 1.0 branch, so the regression
we are talking about here cannot be found there, since this regressed on the
trunk only.
Reporter | ||
Comment 14•22 years ago
|
||
Patch in bug 123049 fixes bug 187671 and this one too.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•