bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Editing or saving page with some given CSS crashes Mozilla




CSS Parsing and Computation
15 years ago
15 years ago


(Reporter: Erich 'Ricky' Iseli, Assigned: dbaron)


({crash, stackwanted, testcase})

crash, stackwanted, testcase
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



15 years ago
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

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:

Comment 1

15 years ago
Created attachment 110572 [details]
Testcase (not yet fully stripped down)

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
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!)

Comment 4

15 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

Comment 5

15 years ago
Created attachment 110658 [details]
Simplified testcase to reproduce the bug

Simplified testcase as described in Comment 4
Attachment #110572 - Attachment is obsolete: true

Comment 6

15 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
Keywords: stackwanted

Comment 7

15 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

Comment 8

15 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
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)
#2  0x420124bd in nsCSSFrameConstructor::ProcessRestyledFrames (this=0x8a7ed68, 
    aChangeList=@0xbfff72bc, aPresContext=0x88100f8)
#3  0x41f960d7 in PresShell::ReconstructStyleData (this=0x8a7ee58,
#4  0x41f962e9 in PresShell::StyleSheetRemoved (this=0x8a7ee58,

Looks like bug 187671
Depends on: 187671

Comment 10

15 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

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

15 years ago
Assignee: jfrancis → dbaron
Component: Editor: Core → Style System
QA Contact: sujay → ian

Comment 12

15 years ago
Is this related to 166596?

Comment 13

15 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.

Comment 14

15 years ago
Patch in bug 123049 fixes bug 187671 and this one too.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 15

15 years ago
Verified in nightly 2003-01-21-10.


15 years ago
Depends on: 123049
You need to log in before you can comment on or make changes to this bug.