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

RESOLVED DUPLICATE of bug 180309

Status

Core Graveyard
GFX: Gtk
--
critical
RESOLVED DUPLICATE of bug 180309
14 years ago
9 years ago

People

(Reporter: dan furlani, Assigned: blizzard)

Tracking

({crash})

Trunk
x86
Linux
crash

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
Created attachment 146328 [details]
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?

Comment 3

14 years ago
testcase worksforme with linux trunk 2004041708, 1.6 and xft/trunk
Keywords: crash
(Reporter)

Comment 4

14 years ago
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.
(Reporter)

Comment 7

14 years ago
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...
(Reporter)

Comment 9

14 years ago
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?
(Reporter)

Comment 11

14 years ago
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]

Comment 13

14 years ago
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?

Comment 15

14 years ago
Any connection to bug 241324?
Possible, but we don't really know why that one happens either....
Depends on: 241324
(Assignee)

Comment 17

14 years ago
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.

Comment 18

14 years ago
do you have Microsoft .fon fonts in your fonts directories ? Does deleting (or
archiving) them prevent from crashing ? Could be bug 180309.

Comment 19

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

Comment 20

14 years ago
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
Last Resolved: 13 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.