Closed Bug 17995 Opened 25 years ago Closed 25 years ago

[DOGFOOD][BLOCKER]Browser crashes on Safe Form Fill

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: cpratt, Assigned: pollmann)

Details

(Whiteboard: [PDT+]) 

With today's mozilla build, try the following

launch mozilla
Go to the http://people.netscape.com/morse/wallet/samples/INTERVIEW.HTML link
Fill in First name and last name.
Select Edit | Wallet |Capture Form. Click OK
Relaunch the browser. Go to Edit |Wallet |Safe Form Fill. Browser crashes with
the following register information.

MOZILLA caused an invalid page fault in
module GKHTML.DLL at 0177:60239a09.
Registers:
EAX=00000000 CS=0177 EIP=60239a09 EFLGS=00010246
EBX=00000000 SS=017f ESP=0063dab0 EBP=0063dab4
ECX=60260500 DS=017f ESI=06459300 FS=4ab7
EDX=0063dab0 ES=017f EDI=00000000 GS=0000
Bytes at CS:EIP:
8b 08 52 68 30 bc 26 60 50 ff 11 a9 00 00 00 80
Stack dump:
00000000 0063dac8 60239aa4 00000000 06459300 00000000 0063dadc 6023a200 00000000
00000000 06459300 0063dafc 6023a41b 06459338 0063db04 06459300
Status: NEW → ASSIGNED
Target Milestone: M12
Yep, it sure is crashing.  Stack trace is shown below.  Looks like a regresson
in layout.  Do you know as of what build did this start crashing?

nsListControlFrame::SetProperty(nsListControlFrame * const 0x02912118,
nsIPresContext * 0x0285a810, nsIAtom * 0x010f53d0, const nsString & {"0"}) line
1915 + 20 bytes
nsComboboxControlFrame::MakeSureSomethingIsSelected(nsIPresContext * 0x0285a810)
line 203 + 41 bytes
nsComboboxControlFrame::AddOption(nsComboboxControlFrame * const 0x02912230,
nsIPresContext * 0x0285a810, int 0) line 1092
nsHTMLSelectElement::AddOption(nsHTMLSelectElement * const 0x02912e6c,
nsIContent * 0x0291bcbc) line 662 + 32 bytes
nsHTMLOptionElement::SetParent(nsHTMLOptionElement * const 0x0291bcbc,
nsIContent * 0x02912e60) line 208
nsGenericHTMLContainerElement::AppendChildTo(nsIContent * 0x0291bcbc, int 0)
line 2947
nsHTMLSelectElement::AppendChildTo(nsHTMLSelectElement * const 0x02912e60,
nsIContent * 0x0291bcbc, int 0) line 165 + 22 bytes
SinkContext::CloseContainer(const nsIParserNode & {...}) line 1217 + 30 bytes
HTMLContentSink::CloseContainer(HTMLContentSink * const 0x02868870, const
nsIParserNode & {...}) line 2547 + 15 bytes
CNavDTD::CloseContainer(const nsIParserNode & {...}, nsHTMLTag eHTMLTag_option,
int 0) line 2746 + 31 bytes
CNavDTD::CloseContainersTo(int 7, nsHTMLTag eHTMLTag_option, int 0) line 2783 +
26 bytes
CNavDTD::CloseContainersTo(nsHTMLTag eHTMLTag_option, int 0) line 2805 + 20
bytes
CNavDTD::HandleEndToken(CToken * 0x01d54ae0) line 1502 + 20 bytes
CNavDTD::HandleToken(CNavDTD * const 0x02869ee0, CToken * 0x01d54ae0, nsIParser
* 0x02868200) line 669 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x02869ee0, nsIParser * 0x02868200,
nsITokenizer * 0x028686a0, nsITokenObserver * 0x00000000, nsIContentSink *
0x02868870) line 471 + 20 bytes
nsParser::BuildModel() line 1048 + 34 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000, int 0) line 959 + 11 bytes
nsParser::Parse(const nsString & {"<option VALUE='Name.First'>Steve</option>"},
void * 0x80000001, const nsString & {"text/html"}, int 0, int 0, eParseMode
eParseMode_autodetect) line 839 + 15 bytes
nsHTMLDocument::ScriptWriteCommon(JSContext * 0x02543990, long * 0x01f44d8c,
unsigned int 1, int 0) line 1792 + 184 bytes
nsHTMLDocument::Write(nsHTMLDocument * const 0x028307b0, JSContext * 0x02543990,
long * 0x01f44d8c, unsigned int 1) line 1806
NSHTMLDocumentWrite(JSContext * 0x02543990, JSObject * 0x01f82dc8, unsigned int
1, long * 0x01f44d8c, long * 0x0012bf5c) line 1163 + 24 bytes
js_Invoke(JSContext * 0x02543990, unsigned int 1, unsigned int 0) line 672 + 26
bytes
js_Interpret(JSContext * 0x02543990, long * 0x0012c7d4) line 2247 + 15 bytes
js_Invoke(JSContext * 0x02543990, unsigned int 0, unsigned int 0) line 688 + 13
bytes
js_Interpret(JSContext * 0x02543990, long * 0x0012d008) line 2247 + 15 bytes
js_Invoke(JSContext * 0x02543990, unsigned int 0, unsigned int 0) line 688 + 13
bytes
js_Interpret(JSContext * 0x02543990, long * 0x0012d83c) line 2247 + 15 bytes
js_Invoke(JSContext * 0x02543990, unsigned int 1, unsigned int 2) line 688 + 13
bytes
js_InternalCall(JSContext * 0x02543990, JSObject * 0x01ebea58, long 32847072,
unsigned int 1, long * 0x0012d9a4, long * 0x0012d95c) line 765 + 15 bytes
JS_CallFunction(JSContext * 0x02543990, JSObject * 0x01ebea58, JSFunction *
0x027d6e60, unsigned int 1, long * 0x0012d9a4, long * 0x0012d95c) line 2707 + 32
bytes
nsJSContext::CallFunction(nsJSContext * const 0x02542170, void * 0x01ebea58,
void * 0x027d6e60, unsigned int 1, void * 0x0012d9a4, int * 0x0012d9a0) line 328
+ 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x028fd444) line 103 + 48 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012dd04, nsIDOMEvent * * 0x0012dba8, unsigned int 7, nsEventStatus &
nsEventStatus_eIgnore) line 990 + 21 bytes
GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x02541584,
nsIPresContext & {...}, nsEvent * 0x0012dd04, nsIDOMEvent * * 0x0012dba8,
unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2963
nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x02541bd4, nsIDocumentLoader *
0x02541b50, nsIChannel * 0x025420b0, unsigned int 0, nsIDocumentLoaderObserver *
0x02541bd4) line 3340 + 34 bytes
nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x02541b50, nsIChannel
* 0x025420b0, unsigned int 0) line 865
nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x02541b54, nsIChannel *
0x00000000, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 746
nsLoadGroup::SubGroupIsEmpty(unsigned int 0) line 118 + 46 bytes
nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x027ef120, nsIChannel *
0x027f02c0, nsISupports * 0x00000000, unsigned int 0, const unsigned short *
0x00000000) line 602
nsInputStreamChannel::OnStopRequest(nsInputStreamChannel * const 0x027f02c4,
nsIChannel * 0x027f0160, nsISupports * 0x00000000, unsigned int 0, const
unsigned short * 0x00000000) line 302
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x027f0500) line
322
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x027f0c20) line 169 + 12 bytes
PL_HandleEvent(PLEvent * 0x027f0c20) line 537 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00c6fb50) line 498 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x06cc03de, unsigned int 49375, unsigned int 0,
long 13040464) line 972 + 9 bytes
USER32! 77e71268()
00
Summary: [BLOCKER]Browser crasheson Safe Form Fill → [DOGFOOD][BLOCKER]Browser crasheson Safe Form Fill
Same crash occurs when displaying wallet contents for a non-empty wallet.
Steve, looking back thru old builds it appears to have broken over the weekend.

Chris, was SafeFormFill smoketested earlier in the week?

See bug 17852 for a similar crash.
Actually, this bug was opened by me...used cpratt's account....
It worked for earlier builds on MAC (which I tested)....chris knows about win
and linux
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Component: Autofill → Layout
Resolution: --- → DUPLICATE
Bug 17900 has an identical stack trace, and has been marked a dup of 17852. This
is definitely a layout bug.

*** This bug has been marked as a duplicate of 17852 ***
Yep I know it's a layout bug.  But I'm on the verge of a very simple test case.
Let me know if you still want it or if I should abandon what I'm doing?
Status: RESOLVED → VERIFIED
Status: VERIFIED → REOPENED
Not a dup, my bad.  :)
Assignee: morse → pollmann
Status: REOPENED → NEW
Status: NEW → ASSIGNED
Resolution: DUPLICATE → ---
I'm taking a look at this one.  As noted on bug 17852, here is a reduced test
case:

<html>
 <body>
   <select>
<script>dump('block parser to cause crash\n');</script>
    <option VALUE='first'>steve</option>
   </select>
 </body>
</html>
See also bug 17900
I had problems debugging the above test case, but this one is easy:
<html>
 <body>
  <select>
   <script>document.write('<option>steve')</script>
  </select>
 </body>
</html>

This is the result of a reframing of the select - perhaps the option is being
added to the old list control that was destroyed?
Summary: [DOGFOOD][BLOCKER]Browser crasheson Safe Form Fill → [DOGFOOD][BLOCKER]Browser crashes on Safe Form Fill
Whiteboard: [PDT+]
Putting on PDT+ radar.
This does appear to be what's happening.  First combo and list frames A are
created, then both are destroyed.  Next, combo and list frames B are created.
Then the content tries to add an option.  It calls GetPrimaryFrame on the
content and gets back frame A, tries to add an option to the frame, which was
freed, then...  *crash*  (I set breakpoints in combo and list constructors,
destructors and nsHTMLSelectElement::AddOption)
Oops, my analysis was off.  GetPrimaryFrame is working fine.

First frame A are created, then an option is added.  In the course of adding the
option, we (I) call MakeSureSomethingIsSelected, which changes the selected
state of an option, which causes nsCSSFrameConstructor::RecreateFramesForContent
to be called, destroys frame A recreates frame B, then when we unwind to
HTMLSelectElement::AddOption, we have a stale pointer to frame A.

Rod, your fix for the similar bug 17852 was to remove the Reset call from
nsListControlFrame's AddOption.

Would it be reasonable for me to remove the MakeSureSomethingIsSelected call
from nsComboboxControlFrame's AddOption?  Or is there some way to change an
option's selected state without causing a reframe of the whole select?
Target Milestone: M12 → M11
PDT+ Crasher, so this should be considered for M11, marking as such.
Just checked in this fix.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Blocks: 18471
Status: RESOLVED → REOPENED
Reopening bug. Observed the same crash on Windows commercial build
(1999-11-10-08) for today.
Following ae the register details :

MOZILLA caused an invalid page fault in
module GKHTML.DLL at 0177:00d9ae17.
Registers:
EAX=00e608f0 CS=0177 EIP=00d9ae17 EFLGS=00010216
EBX=01ea8be0 SS=017f ESP=0063d190 EBP=0063d194
ECX=00000582 DS=017f ESI=01e54db0 FS=116f
EDX=0063d1b8 ES=017f EDI=0063d248 GS=0000
Bytes at CS:EIP:
8b 49 28 eb f4 8b 45 fc c9 c3 55 8b ec 51 56 8b
Stack dump:
00000582 0063d1a0 00df50bd 01ea8c14 0063d1c0 00df690f 0063d1b8
0063d248 01ea8be0 01e54db0 01e54db0 01e54db0 0063d1dc 00df69ca
00000031 01ea8be
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen of this bug.
Curiously enough, I don't see the crash on today's mozilla build (win32
platform) but the dialog that comes up is incorrect.  In particular I have a
value entered in the name field.  But the form shows a name field but with no
value.  However if I click on OK, the value that I had entered does indeed get
prefilled.
OK, I see that bug 18479 has already been filed on the blank name field problem
I just described.
I don't see the crash on Linux today's build either, updating my Win NT and
Solaris trees.  Shrirang, which test case caused the crash for you?  Would it be
possible to add a stack trace?  Thanks.
I don't see the crash, either, using a Linux Commercial build from this morning.
I do crash pulling down the Edit - Wallet - Samples menu item, but that is
probably related to all the other hoarkage today.

I'll work with Shrir to try to figure this out.
I did not see any crash on LINUX. The commercial build for Windows
(1999-11-10-09-M12) causes a crash.The register details have been added in my
earlier comment. On Linux, I can see the Form Screen appear after I select the
Safe Form Field option in Edit|Wallet menu. The problem there is the contents of
the pull dowm list are not seen. I have already opened bug 18479 for that...
Status: REOPENED → ASSIGNED
I duplicated this on a windows tip build from 10am. It can be duplicated by:

1. Going to http://people.netscape.com/morse/wallet/samples/INTERVIEW.HTML
2. Filling something in for first name
3. Selecting Edit - Wallet - Capture Form
4. Going to http://http://people.netscape.com/morse/wallet/samples/amazon.html
5. Selecting Edit - Wallet - SafeFormFill

here is the trace:


   0x02930c37


   nsTableFrame::GetCellInfoAt

[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 4082]

   BasicTableLayoutStrategy::AssignPreliminaryColumnWidths

[d:\builds\seamonkey\mozilla\layout\html\table\src\BasicTableLayoutStrategy.cpp,
line 745]

   BasicTableLayoutStrategy::Initialize

[d:\builds\seamonkey\mozilla\layout\html\table\src\BasicTableLayoutStrategy.cpp,
line 112]

   nsTableFrame::BalanceColumnWidths

[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 2882]

   nsTableFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableFrame.cpp, line 1291]

   nsContainerFrame::ReflowChild

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line
428]

   nsTableOuterFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\table\src\nsTableOuterFrame.cpp, line
904]

   nsBlockReflowContext::ReflowBlock

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
252]

   nsBlockFrame::ReflowBlockFrame

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3227]

   nsBlockFrame::ReflowLine

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2619]

   nsBlockFrame::ReflowDirtyLines

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2426]

   nsBlockFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1490]

   nsBlockReflowContext::ReflowBlock

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
252]

   nsBlockFrame::ReflowBlockFrame

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3227]

   nsBlockFrame::ReflowLine

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2619]

   nsBlockFrame::ReflowDirtyLines

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2426]

   nsBlockFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1490]

   nsBlockReflowContext::ReflowBlock

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line
252]

   nsBlockFrame::ReflowBlockFrame

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3227]

   nsBlockFrame::ReflowLine

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2619]

   nsBlockFrame::ReflowDirtyLines

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2426]

   nsBlockFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 1490]

   nsAreaFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsAreaFrame.cpp, line 294]

   nsContainerFrame::ReflowChild

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line
428]

   RootFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 335]

   nsContainerFrame::ReflowChild

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line
428]

   nsScrollFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsScrollFrame.cpp, line 622]

   nsContainerFrame::ReflowChild

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line
428]

   ViewportFrame::Reflow

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 514]

   nsHTMLReflowCommand::Dispatch

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp, line
140]

   PresShell::ProcessReflowCommands

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1617]

   ReflowEvent::HandleEvent

[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1526]

   PL_HandleEvent
                                                          [plevent.c, line 538]

   PL_ProcessPendingEvents
                                                          [plevent.c, line 499]

   _md_EventReceiverProc
                                                          [plevent.c, line 976]
I see the crash, but I think this is going to have to wait for m12.
Target Milestone: M11 → M12
Actually, it's unclear to me if this occurs on M11 branch or not. This
particular bug was found on M12 build from today. We will be get M11 builds soon
- I will update bug. I agree that this is M12 material anyway, so I'm moving.
The second stack trace is completely different, indicating that this may be a
different bug.  It's in tables now instead of the listbox, so I'm CC'ing Chris.
Chris, can you take a look?
I have a fix for a similar table stack but it isn't checked in yet.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Do you have a bug number?  Since this is a separate bug (tables), I'm re-closing
bug 17995 (listbox).
Status: RESOLVED → VERIFIED
verified with 11/29 builds
No longer blocks: 18471
You need to log in before you can comment on or make changes to this bug.