Closed
Bug 127120
Opened 23 years ago
Closed 23 years ago
CRASH when changing style element with display:none
Categories
(Core :: Layout, defect, P1)
Tracking
()
RESOLVED
DUPLICATE
of bug 105619
People
(Reporter: mgalli, Assigned: attinasi)
References
()
Details
(Keywords: crash)
Attachments
(3 files)
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.
Reporter | ||
Comment 1•23 years ago
|
||
Adding Roger.
Comment 2•23 years ago
|
||
CC: stephend@netscape.com, for talkback retrieval, please (3211340)
Severity: normal → critical
Keywords: crash
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)
Updated•23 years ago
|
Priority: -- → P1
Comment 4•23 years ago
|
||
Comment 5•23 years ago
|
||
stacktrace from minimal testcase.
Comment 6•23 years ago
|
||
Forgot my build info....
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020224
Reporter | ||
Comment 7•23 years ago
|
||
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.
Reporter | ||
Comment 8•23 years ago
|
||
This could be DOM. DOM'T you think?
Comment 9•23 years ago
|
||
Probably layout. it's repainting the screen when it crashes.
Comment 10•23 years ago
|
||
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•23 years ago
|
||
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
Reporter | ||
Comment 12•23 years ago
|
||
;)
Summary: CRASH with this page - need better summary → CRASH when changing style element with display:none
Comment 13•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Patch in bug 105619 fixes this bug
Comment 16•23 years ago
|
||
As stated above...
*** This bug has been marked as a duplicate of 105619 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•