Crash on JavaScript-enhanced layer [@ nsTextFrame::PaintAsciiText]




16 years ago
16 years ago


(Reporter: ruud, Assigned: bryner)


(4 keywords)

crash, regression, testcase, topcrash+
Dependency tree / graph
Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)


(crash signature, URL)


(2 attachments, 1 obsolete attachment)



16 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030212
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3b) Gecko/20030212

Please visit the URL above and click the Notepad icon, close it, and open it
again. This will crash Mozilla 1.3b.

Reproducible: Always

Steps to Reproduce:
1. Go to
2. Click Notepad icon, the Notepad layer will appear gradually.
3. Click Hide Notepad
4. Repeat step 2.
5. When Hide Notepad is clicked, this time Mozilla will crash hard.

Actual Results:  
Mozilla crashes.

Expected Results:  

In the PC the error message "gklayout.dll" is mentioned.

Comment 1

16 years ago
In Phoenix 0.5 (Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021207
Phoenix/0.5) works fine.
Can you please attach a OS X crash log ?

Comment 3

16 years ago
Posted file Crash log (obsolete) —
The crash does NOT occur in the latest official version (1.2.1)!

Comment 4

16 years ago
WorksForMe using FizzillaMach/2003022103. Ruud, can you still reproduce this
problem using a current nightly build? If so, can you reproduce this problem
using another Mozilla user profile?
Keywords: crash
Summary: Crash on java-script enhanced layer → Crash on JavaScript-enhanced layer

Comment 5

16 years ago
It crashes on me too.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030224
Talkback ID: TB17529834Y
It took me about two-three open/hide for it to happen.

Comment 6

16 years ago
Confirmed using FizzillaMach/2003022103, generating TB177879M.
Ever confirmed: true
Summary: Crash on JavaScript-enhanced layer → Crash on JavaScript-enhanced layer [@ nsTextFrame::PaintAsciiText]

Comment 7

16 years ago
This crash report was formatted better for some reason.
Attachment #115638 - Attachment is obsolete: true

Comment 8

16 years ago
Setting All/All per comment 5.

Lots of layout stuff on the stack. Let's send this to Layout.
Assignee: rogerl → other
Component: JavaScript Engine → Layout
OS: MacOS X → All
QA Contact: pschwartau → ian
Hardware: Macintosh → All
text frame stuff; not JS.
Assignee: other → font
Component: Layout → Layout: Fonts and Text
OS: All → MacOS X
Hardware: All → Macintosh

Comment 10

16 years ago
Adding regression keyword per comment 3. Should this get fixed for 1.3 final?
Flags: blocking1.3?
Keywords: regression
Crash is at


aTextStyle.mColor is null.

Comment 12

16 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030226
DocWatson says:
Trap 0e 0000 invalid page fault

and some more, but I cant copy&paste it.
 mColor = (const nsStyleColor*) sc->GetStyleData(eStyleStruct_Color); at
is returning nsnull.
Do we want to put in a temporary wallpaper patch to prevent the crash?


16 years ago
Flags: blocking1.3? → blocking1.3-

Comment 15

16 years ago
TB17570589W Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030227
DocWatson told me it´s Mozilla 1.4a ...

Comment 16

16 years ago
adding topcrash to keywords
Keywords: topcrash

Comment 17

16 years ago
-> bryner

From comment 4, it worked up to 2003 02 21. Might be a regression from bryner's
deCOMtamination which landed thereafter on Feb 21. There have been other hiccups
that have since been fixed as well. Let see what he thinks.
Assignee: font → bryner
Component: Layout: Fonts and Text → Style System
OS: MacOS X → All
Hardware: Macintosh → All

Comment 18

16 years ago
Note that my comment 4 was in error. I failed to repeat the operation. Once I
did repeat it, FizzillaMach/2003022103 crashed per my comment 6.

Comment 19

16 years ago
Feb 21 was also the day when the tree branched for m1.3, and the deCOMtamination
didn't land on the branch. To narrow the window, can somebody who can test a
build from the branch tell us if they see the bug?

Comment 20

16 years ago
The bug was introduced between 1.2.1 (comment 3) and 2003-02-12 (comment 0).

Comment 21

16 years ago
OK, I see. But that window [feb/12/2003 - dec/2002] is still too large though.
It has been my experience that these null style pointers (or dead references)
can be very hard to track down and fix. It would help if the window could be
shrinked to a day. (Actually, one of my radar shows that
nsTextFrame::PaintAsciiText is just paying the price. The style color pointer
becomes null at some earlier stage in the absolute container block, but since
nobody needs the color there...)

Here are the checkins between feb/12/2003 - dec/02/2002, just too much to make
any sense of them. (BTW, I tested that the bug didn't come from any of mine)
Keywords: qawanted

Comment 22

16 years ago
On further experimentation, my comment 20 is in error. This problem was
introduced between 2002-10-30-11-trunk and 2002-11-08-08-trunk.

1.2 probably branched before this happened, which is why 1.2.1 doesn't crash.

Comment 23

16 years ago
regression between trunk builds 2002110508 and 2002110604


16 years ago
Keywords: qawanted

Comment 25

16 years ago
Could this be glazman's checkin to nsCSSDeclaration.cpp, for bug 172199?  I'm
pretty sure I'm not the right owner for the bug.
Unlikely.... That just changed what the DOM shows, not what the computed style
data is.

This could also be something like bug 74951, I guess.

In any case, I suspect that whatever checkin caused this merely uncovered a
problem -- the problem that we're clearing away style data and then not
necessarily recreating it.  With the patch for bug 171830 I don't crash....
Depends on: 171830

Comment 27

16 years ago
Making this topcrash+ and adding testcase keyword since it is easily
reproducible with the steps mentioned in comment #0.
Keywords: topcrash → testcase, topcrash+

Comment 28

16 years ago
Posted file testcase
now there's a testcase...

Comment 29

16 years ago
looks like a dupe of 190558

Comment 30

16 years ago
Marking fixed now that bug 171830 has landed and has resolved the problem.

Noted however that nsBrowserStatusHandler.js::endDocumentLoad() is dumping this
curious message: Error loading URL javascript:openNotepad(); : 805303f5
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 31

16 years ago
I don't know if this was supposed to have been fixed in 1.3 final but with the
OS X version released today I still experience the crash as originally described.
Resolution: FIXED → ---

Comment 32

16 years ago
> I don't know if this was supposed to have been fixed in 1.3 final

it wasn't.  bug 171830, which fixed this, was never checked into the 1.3 branch.

re-resolving as FIXED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 33

16 years ago
checked the url testcase (comment 0) on winXP, macosX and linux on the latest
trunk nightlies.
no crash see.
Marking verified.
Crash Signature: [@ nsTextFrame::PaintAsciiText]
You need to log in before you can comment on or make changes to this bug.