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)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 180309
People
(Reporter: dan.furlani, Assigned: blizzard)
References
Details
(Keywords: crash, Whiteboard: needed-aviary1.0)
Crash Data
Attachments
(1 file)
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.
Comment 1•20 years ago
|
||
I don't see a crash on this with a current trunk seamonkey build (no xft, gtk1) on Linux.
Comment 2•20 years ago
|
||
dan, can you run mozilla -g to try and get a stack backtrace?
Comment 3•20 years ago
|
||
testcase worksforme with linux trunk 2004041708, 1.6 and xft/trunk
Keywords: crash
Reporter | ||
Comment 4•20 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?
Comment 5•20 years ago
|
||
Don't worry, layout is the same on both anyway.
Comment 6•20 years ago
|
||
Dan, the best thing you can do is reproduce in a build with talkback and report the talkback ID here.
Reporter | ||
Comment 7•20 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...
Comment 8•20 years ago
|
||
Run components/talkback/talkback (from the directory where Mozilla is installed) and that should list the incidents and their IDs...
Reporter | ||
Comment 9•20 years ago
|
||
Cool. TB31207M
Comment 10•20 years ago
|
||
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•20 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
Comment 12•20 years ago
|
||
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•20 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.
Comment 14•20 years ago
|
||
> I wonder if the stack trace is not out of sync.
Possible, what with the lack of line numbers... chofmann? Thoughts?
Comment 15•20 years ago
|
||
Any connection to bug 241324?
Comment 16•20 years ago
|
||
Possible, but we don't really know why that one happens either....
Depends on: 241324
Assignee | ||
Comment 17•20 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•20 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•20 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•20 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
Closed: 20 years ago
Resolution: --- → DUPLICATE
Updated•15 years ago
|
Product: Core → Core Graveyard
Updated•13 years ago
|
Crash Signature: [@ GetNormalLineHeight]
You need to log in
before you can comment on or make changes to this bug.
Description
•