105716 - Can't delete the input characters in the above form page

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Yuying Long]

Build: 10-17 latast 0.9.4 branch build

Steps:
1. Go http://www.steltor.com/beta/index.cfm?fuseaction=register
2. Type any thing into text field, e.g. company, name...etc.
3. Press backspace key to delete the input.

Result:
Can not delect any thing, I tried to moving mouse cursor to another place, tried
Delete and Backspace keys again , still do nothing. 

Can not reproduce on N4.7 and IE.

Comment 1

[rods (gone)]

over to kin

Comment 2

[TucsonTester3]

Platform: PC  

Operating System: Windows 95 OSR 2.5 

Build ID:  2001112603

URL: http://www.steltor.com/beta/index.cfm?fuseaction=register

Desciption: I was able to reproduce this bug in Netscape when the site was
"live" and online.  I was not able to erase what I typed unless I highlighted
text, then right clicked and then clicked on CUT.  But the interesting part
occurred when I pressed CTRL+E to import the page into Composer, then without
making any changes, saved it onto my desktop, and then opened it up into a new
Navigator window.  In this offline state I was able to type in the fields and
also delete text which I had entered on the form.  I don't know what this would
indicate, if anything, but I hope it is of some help.  

Reproducibility: Every time 

Steps to Reproduce: 
1.  Open a new Navigator window and go to:  
    http://www.steltor.com/beta/index.cfm?fuseaction=register

2.  Type any thing into text field, e.g. company, name...etc.

3.  Press backspace key to delete the input.  Notice the text does not erase.

4.  With your mouse highlight the text you entered, then right-click, and then
    click on CUT.  The text gets erased from the form.  

5.  On your keyboard press CTRL+E to import the page to Composer.

6.  Without making any changes, save the file to your Desktop.

7.  Open the saved file in a new Navigator window and repeat steps 2 and 3.  This
    time the text you entered can be erased using backspace, and/or delete.

Comment 3

[kinmoz]

Attachment: Minimal Test Case

Here's the minimal test case. HTML formatting of the source is intentional and
uses the minimal amount of whitespace necessary to reduce frame noise and still
allow reproduction of the problem while debugging.

Comment 4

[kinmoz]

Attachment: Minimal Test Case (corrected)

Whoops attatched the wrong version of the minimal test case. Here's the real
one.

Comment 5

[kinmoz]

Ok here's the dealio. There are 2 sets of frames being created for the floating 
table that contains the text widget. The first set should be getting destroyed, 
but it's not, because at the time nsBlockFrame::RemoveFrame() gets called, the 
linebox containing the floating table has a null mInlineData pointer.

FYI there are 2 sets of frames being created because apparently 
SinkContext::DemoteForm() removes the <font> tag from underneath the <form> and 
then puts it back in, triggering nsCSSFrameConstructor::ContentRemoved().

The fact that there are 2 sets of frames existing for the same text widget means
that there are 2 editors and 2 event handlers which ends up interfering with 
each other.

I think I have a fix for the leak of the first set of frames. I just need some
block code gurus to tell me if we are calling mFloaters.RemoveFrame() before
the for loop that destroys the frame, for a specific reason.

Here's the stack to where the first set should be getting destroyed:


nsBlockFrame::RemoveFrame(nsBlockFrame * const 0x02d80458, nsIPresContext * 
0x017cf510, nsIPresShell & {...}, nsIAtom * 0x0162ec60, nsIFrame * 0x02d80758) 
line 4816
nsFormFrame::RemoveFrame(nsFormFrame * const 0x02d80458, nsIPresContext * 
0x017cf510, nsIPresShell & {...}, nsIAtom * 0x0162ec60, nsIFrame * 0x02d80758) 
line 229
FrameManager::RemoveFrame(FrameManager * const 0x0182f160, nsIPresContext * 
0x017cf510, nsIPresShell & {...}, nsIFrame * 0x02d80458, nsIAtom * 0x0162ec60, 
nsIFrame * 0x02d80758) line 946
DeletingFrameSubtree(nsIPresContext * 0x017cf510, nsIPresShell * 0x02d7dcd0, 
nsIFrameManager * 0x0182f160, nsIFrame * 0x00000000) line 9036
nsCSSFrameConstructor::ContentRemoved(nsCSSFrameConstructor * const 0x02d91a78, 
nsIPresContext * 0x017cf510, nsIContent * 0x02dbad10, nsIContent * 0x02dbaec8, 
int 0) line 9403 + 31 bytes
StyleSetImpl::ContentRemoved(StyleSetImpl * const 0x01836140, nsIPresContext * 
0x017cf510, nsIContent * 0x02dbad10, nsIContent * 0x02dbaec8, int 0) line 1440
PresShell::ContentRemoved(PresShell * const 0x02d7dcd8, nsIDocument * 
0x02e0b498, nsIContent * 0x02dbad10, nsIContent * 0x02dbaec8, int 0) line 5203 + 
53 bytes
nsDocument::ContentRemoved(nsDocument * const 0x02e0b498, nsIContent * 
0x02dbad10, nsIContent * 0x02dbaec8, int 0) line 1776
nsHTMLDocument::ContentRemoved(nsHTMLDocument * const 0x02e0b498, nsIContent * 
0x02dbad10, nsIContent * 0x02dbaec8, int 0) line 1209
nsGenericHTMLContainerElement::RemoveChildAt(nsGenericHTMLContainerElement * 
const 0x02dbad10, int 0, int 1) line 3944
SinkContext::DemoteForm(const nsIParserNode & {...}) line 1862 + 18 bytes
HTMLContentSink::CloseForm(HTMLContentSink * const 0x02d79dc8, const 
nsIParserNode & {...}) line 3366 + 18 bytes
CNavDTD::CloseForm(const nsIParserNode * 0x0012fbac) line 3226 + 31 bytes
CNavDTD::CloseContainer(const nsCParserNode * 0x0012fbac, nsHTMLTag 
eHTMLTag_form, int 0) line 3520 + 12 bytes
CNavDTD::HandleEndToken(CToken * 0x02dc06f0) line 1913 + 18 bytes
CNavDTD::HandleToken(CNavDTD * const 0x02d6a1a8, CToken * 0x02dc06f0, nsIParser 
* 0x02de3cf8) line 887 + 12 bytes
CNavDTD::BuildModel(CNavDTD * const 0x02d6a1a8, nsIParser * 0x02de3cf8, 
nsITokenizer * 0x02d96018, nsITokenObserver * 0x00000000, nsIContentSink * 
0x02d79dc8) line 520 + 20 bytes
nsParser::BuildModel() line 1978 + 34 bytes
nsParser::ResumeParse(int 1, int 0) line 1844 + 11 bytes
nsParser::OnDataAvailable(nsParser * const 0x02de3cfc, nsIRequest * 0x02dd3cf8, 
nsISupports * 0x00000000, nsIInputStream * 0x02e0cca0, unsigned int 0, unsigned 
int 207) line 2467 + 19 bytes
nsDocumentOpenInfo::OnDataAvailable(nsDocumentOpenInfo * const 0x02db0810, 
nsIRequest * 0x02dd3cf8, nsISupports * 0x00000000, nsIInputStream * 0x02e0cca0, 
unsigned int 0, unsigned int 207) line 241 + 46 bytes
nsFileChannel::OnDataAvailable(nsFileChannel * const 0x02dd3d00, nsIRequest * 
0x02d77f84, nsISupports * 0x00000000, nsIInputStream * 0x02e0cca0, unsigned int 
0, unsigned int 207) line 508 + 49 bytes
nsOnDataAvailableEvent::HandleEvent() line 193 + 70 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x0174072c) line 116
PL_HandleEvent(PLEvent * 0x0174072c) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01654aa8) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000f049a, unsigned int 49492, unsigned int 0, 
long 23415464) line 1071 + 9 bytes
USER32! 77e12e98()
USER32! 77e130e0()
USER32! 77e15824()
main(int 2, char * * 0x00a97280) line 172 + 11 bytes
mainCRTStartup() line 338 + 17 bytes

Comment 6

[kinmoz]

Attachment: Patch Rev 1 (Possible Fix in nsBlockFrame::RemoveFrame())

dbaron, attinasi, waterson -- what do you think of this patch?

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 60875 [details] [diff] [review]
Patch Rev 1 (Possible Fix in nsBlockFrame::RemoveFrame())

r=dbaron, except
>+    if (mFloaters.RemoveFrame(aOldFrame))
>+      aOldFrame->Destroy(aPresContext);
can be simplified to
mFloaters.DestroyFrame(aOldFrame);

Comment 8

[Chris Waterson]

Comment on attachment 60875 [details] [diff] [review]
Patch Rev 1 (Possible Fix in nsBlockFrame::RemoveFrame())

Looks good. sr=waterson

Comment 9

[kinmoz]

Fix checked into the TRUNK with dbaron's suggestion:

    mozilla/layout/html/base/src/nsBlockFrame.cpp  revision 3.476

Fix should be in QA builds after 12/10/01 7am PST.

We may want this for the 0.9.4 branch ... will nominate after QA verifies the fix.

Comment 10

[Chris Petersen]

Verified in the 2002-01-14-23-0.9.4ec.

Comment 11

[rubydoo123]

per comment #10, marking verified