If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in mozilla0.9.7

Status

()

Core
Layout: Form Controls
P3
normal
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Yuying Long, Assigned: kinmoz)

Tracking

(Blocks: 1 bug)

Trunk
mozilla0.9.7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [EDITORBASE] [CANDIDATE_094], URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

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

16 years ago
over to kin
Assignee: rods → kin
Summary: Can not delect the input characters in the above form page → Can not delect the input characters in the above form page

Comment 2

16 years ago
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.
(Assignee)

Comment 3

16 years ago
Created attachment 60167 [details]
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.
(Assignee)

Comment 4

16 years ago
Created attachment 60171 [details]
Minimal Test Case (corrected)

Whoops attatched the wrong version of the minimal test case. Here's the real
one.
Attachment #60167 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Blocks: 108120
Status: NEW → ASSIGNED
Priority: -- → P3
Summary: Can not delect the input characters in the above form page → Can't delete the input characters in the above form page
Whiteboard: EDITORBASE
Target Milestone: --- → mozilla0.9.7
(Assignee)

Comment 5

16 years ago
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
(Assignee)

Comment 6

16 years ago
Created attachment 60875 [details] [diff] [review]
Patch Rev 1 (Possible Fix in nsBlockFrame::RemoveFrame())

dbaron, attinasi, waterson -- what do you think of this patch?
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);
Attachment #60875 - Flags: review+

Comment 8

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

Looks good. sr=waterson
Attachment #60875 - Flags: superreview+
(Assignee)

Comment 9

16 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Whiteboard: EDITORBASE → [EDITORBASE] [CANDIDATE_094]

Comment 10

16 years ago
Verified in the 2002-01-14-23-0.9.4ec.
Keywords: verified0.9.4

Updated

16 years ago
QA Contact: madhur → tpreston

Comment 11

15 years ago
per comment #10, marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.