Closed Bug 240757 Opened 20 years ago Closed 20 years ago

Setting CSS style on INPUT elements causes crash when text entered [@ GetNormalLineHeight]

Categories

(Core Graveyard :: GFX: Gtk, defect)

Product:
Core Graveyard
Component:
GFX: Gtk
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 180309

People

(Reporter: dan.furlani, Assigned: blizzard)

References

Details

(Keywords: crash, Whiteboard: needed-aviary1.0)

Crash Data

Attachments

(1 file)

Reporter's testcase
157 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225 Firefox/0.8

If CSS style is specified for INPUT element, entering text in a textbox causes a
browser crash.  If the style is not included in the header there is no problem.

If the textbox already has text in it (value="a"), all the user has to do is
click in the field to cause the browser to crash.  If the field is the only
thing on the page and has a preset value, it may crash on load.

This was discovered on amazon's site; problem also exists on target's site, when
entering username/password to checkout.

Reproducible: Always
Steps to Reproduce:
1. Make a page with the code below.
2. Enter text into the field.

<html>
<head>
<style type="text/css"><!--
INPUT { font-family: fixed; }
--></style>
</head>
<body>
<form>
  <input type="text">
</form>
</body>
</html>

Actual Results:  
Browser crashed.
Attached file Reporter's testcase — 
I don't see a crash on this with a current trunk seamonkey build (no xft, gtk1)
on Linux.
dan, can you run mozilla -g to try and get a stack backtrace?
testcase worksforme with linux trunk 2004041708, 1.6 and xft/trunk
Keywords: crash
Mea culpa
I hastily enter a bug and then go on vacation for a week.
This is a Firefox bug, not a Mozilla bug.  What do I do now?
Don't worry, layout is the same on both anyway.
Dan, the best thing you can do is reproduce in a build with talkback and report
the talkback ID here.
I reproduced the bug and hit "Send" on the talkback form.  It closed after a few
seconds.  Is anything else supposed to happen?

When I click "Details" on the talkback form it immediately closes (crashes?).

I don't know how to get the talkback ID you mention...
Run components/talkback/talkback (from the directory where Mozilla is installed)
and that should list the incidents and their IDs...
Cool.  TB31207M
Fun stuff.  No line numbers in the stack; I wonder why....

Relevant part of stack is:

GetNormalLineHeight(nsIFontMetrics*)()
ComputeLineHeight(nsIPresContext*, nsIRenderingContext*, nsStyleContext*)()
nsHTMLReflowState::CalcLineHeight(nsIPresContext*, nsIRenderingContext*,
nsIFrame*)()
nsBlockReflowState::nsBlockReflowState[in-charge](nsHTMLReflowState const&,
nsIPresContext*, nsBlockFrame*, nsHTMLReflowMetrics const&, int)()
nsBlockFrame::Reflow(nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState
const&, unsigned&)()
nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState&, nsIPresContext*,
nsHTMLReflowMetrics&, nsHTMLReflowState const&, unsigned&, int, int, int, int,
int)()
nsBoxToBlockAdaptor::DoLayout(nsBoxLayoutState&)()
nsBox::Layout(nsBoxLayoutState&)()
nsScrollBoxFrame::DoLayout(nsBoxLayoutState&)()
nsBox::Layout(nsBoxLayoutState&)()
nsContainerBox::LayoutChildAt(nsBoxLayoutState&, nsIBox*, nsRect const&)()
nsGfxScrollFrameInner::Layout(nsBoxLayoutState&)()
nsGfxScrollFrame::DoLayout(nsBoxLayoutState&)()
nsBox::Layout(nsBoxLayoutState&)()
nsBoxFrame::Reflow(nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLReflowState
const&, unsigned&)()
nsGfxScrollFrame::Reflow(nsIPresContext*, nsHTMLReflowMetrics&,
nsHTMLReflowState const&, unsigned&)()
IncrementalReflow::Dispatch(nsIPresContext*, nsHTMLReflowMetrics&, nsSize
const&, nsIRenderingContext&)()

Dan, what does about:buildconfig say for your build?
The talkback is from a firefox nightly i downloaded yesterday (or was it this
morning?)

about:buildconfig

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.3.3 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.3.3 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe

Configure arguments
--disable-ldap --disable-mailnews
--enable-extensions=cookie,xml-rpc,xmlextras,pref,transformiix,universalchardet,typeaheadfind,webservices,inspector,gnomevfs
--enable-crypto --disable-composer --disable-profilesharing --disable-debug
'--enable-optimize=-Os -freorder-blocks -gstabs+' --disable-tests
--enable-official-branding --enable-default-toolkit=gtk2 --enable-xft
--enable-static --disable-shared 
OK, ccing some fonts and xft folks.

One way this crash could happen (the only one I see, in fact) is if
GetNormalLineHeight() is passed a null nsIFontMetrics.  The only way that can
happen is if GetMetricsFor() returns null (or failure; the return value is never
checked in ComputeLineHeight()).

There are several reasons GetMetricsFor() could return null:

1)  DeviceContextImpl::CreateFontCache returns failure (OOM, essentially).
2)  nsFontCache::CreateFontMetricsInstance fails (again, OOM).
3)  Something goes very wrong in nsFontCache::GetMetricsFor (nothing in
    mFontMetrics and Init() failed?)

In this case, #3 would be the thing I'd blame (though the caller should totally
be doing an error-check and bailing....)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Setting CSS style on INPUT elements causes crash when text entered → Setting CSS style on INPUT elements causes crash when text entered [@ GetNormalLineHeight]
WFM on Win2K.  I wonder if the stack trace is not out of sync.

OOM when getting a smallish font object (no load yet) is nearly improbable at
that stage -- the whole system would have died, and there wouldn't have been
other memory to fire the largish talback, etc.
> I wonder if the stack trace is not out of sync.

Possible, what with the lack of line numbers...  chofmann?  Thoughts?
Any connection to bug 241324?
Possible, but we don't really know why that one happens either....
Depends on: 241324
This stack trace looks familiar.  Search a bit, and you'll probably find dups.

I can't reproduce it here.  It's probably one of the usual suspects - .fon
files, incorrect permissions or an older xft that has one of the bugs that we
stumble over.
do you have Microsoft .fon fonts in your fonts directories ? Does deleting (or
archiving) them prevent from crashing ? Could be bug 180309.
Crashes with similar signatures are showing up as ffox 0.9 topcrashers. Do we
know the cause, and is there any chance of a fix for the 1.7/aviary branch?
Whiteboard: needed-aviary1.0
the known crashers that are still active for GetNormalLineHeight are almost
completely outside Mozilla code (Xft bugs, invalid config).  The Xft bugs I know
of are fixed in recent versions.  That was one of the main things keeping Xft
out of default builds.
Assignee: dbaron → blizzard
Component: Style System (CSS) → GFX: Gtk

*** This bug has been marked as a duplicate of 180309 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
Crash Signature: [@ GetNormalLineHeight]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: