127120 - CRASH when changing style element with display:none

Status: RESOLVED DUPLICATE of bug 105619

(Core :: Layout, defect, P1)

Description

[/\/\arcio Galli]

The talkback incident ID is 3211340.

The first crash I had with linux using latest Trunk Gecko/20020221. I also had
the  crash but without talkback (just the exception) with Win98 and latest
Mozilla  trunk. 

I will see If I can simplify the testcase. This works with Netscape 6.2.1 so
it's probably a regression.

Comment 1

[/\/\arcio Galli]

Adding Roger. 

Comment 2

[Olav Vitters]

CC: [e-mail], for talkback retrieval, please (3211340)

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

libc.so.6 + 0x87b9a (0x4054ab9a)
nsStrPrivate::StrAppend()
nsStrPrivate::StrAssign()
nsString::nsString()
nsFont::nsFont()
nsFontMetricsGTK::Init()
nsFontCache::GetMetricsFor()
DeviceContextImpl::GetMetricsFor()
nsTextFrame::Paint()
nsContainerFrame::PaintChild()
nsBlockFrame::PaintChildren()
nsBlockFrame::Paint()
nsContainerFrame::PaintChild()
nsContainerFrame::PaintChildren()
nsHTMLButtonControlFrame::Paint()
nsContainerFrame::PaintChild()
nsBlockFrame::PaintChildren()
nsBlockFrame::Paint()
nsContainerFrame::PaintChild()
nsBlockFrame::PaintChildren()
nsBlockFrame::Paint()
nsContainerFrame::PaintChild()
nsBlockFrame::PaintChildren()
nsBlockFrame::Paint()
nsContainerFrame::PaintChild()
nsBlockFrame::PaintChildren()
nsBlockFrame::Paint()
nsContainerFrame::PaintChild()
nsContainerFrame::PaintChildren()
nsHTMLContainerFrame::Paint()
CanvasFrame::Paint()
PresShell::Paint()
nsView::Paint()
nsViewManager::RenderDisplayListElement()
nsViewManager::RenderViews()
nsViewManager::Refresh()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWindow::DoPaint()
nsWindow::Update()
nsWindow::UpdateIdle()
libglib-1.2.so.0 + 0x1283d (0x4039583d)
libglib-1.2.so.0 + 0x117f3 (0x403947f3)
libglib-1.2.so.0 + 0x11dd9 (0x40394dd9)
libglib-1.2.so.0 + 0x11f8c (0x40394f8c)
libgtk-1.2.so.0 + 0x94803 (0x402a9803)
nsAppShell::Run()
nsAppShellService::Run()
netscape-bin + 0x7e89 (0x0804fe89)
netscape-bin + 0x86d7 (0x080506d7)
libc.so.6 + 0x1c177 (0x404df177) 

Comment 4

[Andrew Schultz]

Attachment: minimal testcase

Comment 5

[Andrew Schultz]

Attachment: stacktrace with symbols

stacktrace from minimal testcase.

Comment 6

[Andrew Schultz]

Forgot my build info....
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020224

Comment 7

[/\/\arcio Galli]

Attachment: Variation of testcase created by Andrew and comments.

Please see view-source: for this attachment. Notes about my recent tests using
the original testcase from Andrew:

(1) does not matter the child element of the parent (display:none) element. I
replaced the child by with P, DIV, SPAN, all crash. 
(2) does not matter the style attribute. I tested with backgroundColor, width,
height, all crash.
(3) the adjust function is called in the onload event. If you delay the
attribute setting in the adjust function. For example with an alert box, then
does not crash.

Comment 8

[/\/\arcio Galli]

This could be DOM. DOM'T you think? 

Comment 9

[Andrew Schultz]

Probably layout.  it's repainting the screen when it crashes.

Comment 10

[Andrew Schultz]

the crash occurs because nsString::nsString is attempting to create a copy of a
null string.  based on the stacktrace, the string is the name of a font
(nsFont.name).  I traced that null font name back to nsTextFrame.cpp

554       mFont = (const nsStyleFont*) sc->GetStyleData(eStyleStruct_Font);

560       nsFont* plainFont = (nsFont *)&mFont->mFont;

after this, plainFont's name is null, which eventually leads to the crash.

GetStyleData does things I don't understand! :)

So:  do we have a null font name because display was "none"?  This is probably bad.

Comment 11

[Andrew Schultz]

could be a dupe of bug 105619

you might want to change the summary to get this noticed... something like
crash when changing style element with display:none

Comment 12

[/\/\arcio Galli]

;)

Comment 13

[Andrew Schultz]

I have figured out that the TextFrame with a null font name is not the <div> or
<textarea> elements.  It's some element that should have valid font info.

Comment 14

[Andrew Schultz]

I caught Mozilla in the act of deleting the relevant font from cache, which
later gets read from cache, causing the crash.  This is a dupe of bug 105619.

Comment 15

[Andrew Schultz]

Patch in bug 105619 fixes this bug

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

As stated above...

*** This bug has been marked as a duplicate of 105619 ***