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)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: Erich.Iseli, Assigned: dbaron)

References

Details

(Keywords: crash, stackwanted, testcase)

Attachments

(1 file, 1 obsolete file)

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
Attached file Testcase (not yet fully stripped down) (obsolete) —
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.
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!)
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
Simplified testcase as described in Comment 4
Attachment #110572 - Attachment is obsolete: true
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
> 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
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
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
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?
reassigning
Assignee: jfrancis → dbaron
Component: Editor: Core → Style System
QA Contact: sujay → ian
Is this related to 166596?
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.
Patch in bug 123049 fixes bug 187671 and this one too.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified in nightly 2003-01-21-10.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: