339975 - Ctrl+clicking a textarea in a table and then typing puts text outside the textarea. Can lead to crash [@ nsTextInputSelectionImpl::ScrollSelectionIntoView] [@ nsTextInputListener::EditAction]

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Ryan Jones-Ward [:sciguyryan]]

First a note: I have tried reducing the page(es) to a testcase but to no avail, having problems reducing it down.

If you copy something (anything, does not matter what) then paste into the textbox/textarea (using CTRL+V) and at the same time click into the textbox/textarea and the content will be pasted outside it. Please see screen shot attached as it shows the effect.

Comment 1

[Ryan Jones-Ward [:sciguyryan]]

Attachment: Showing the problem after pasting.

Comment 2

[Régis Caspar]

Not easy to reproduce but I can confirm: http://img501.imageshack.us/img501/7255/screenshot0017ud.png

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060601 Minefield/3.0a1 ID:2006060105 [cairo]

Comment 3

[Ryan Jones-Ward [:sciguyryan]]

(In reply to comment #2)
> Not easy to reproduce but I can confirm:
> http://img501.imageshack.us/img501/7255/screenshot0017ud.png
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060601
> Minefield/3.0a1 ID:2006060105 [cairo]
> 

Still trying to make a reduced testcase. Looks like its something related to the tables because when they are removed it seems work as it should. 

Comment 4

[Régis Caspar]

(In reply to comment #3)
> Still trying to make a reduced testcase. Looks like its something related to
> the tables because when they are removed it seems work as it should. 
Probably I already saw this issue a few times on f.m.o and some other pages (like 3- 4times)

 -> Core / Layout: Form Controls ??

Comment 5

[Ryan Jones-Ward [:sciguyryan]]

(In reply to comment #4)
>  -> Core / Layout: Form Controls ??

Seems fitting. Would be easier to deicide if it were possible to pin this down to two elements.

Comment 6

[Ria Klaassen (not reading all bugmail)]

The only thing I see here is that it deletes all text that is already present in the input field.

Comment 7

[Régis Caspar]

Attachment: testcase

Comment 8

[Régis Caspar]

If even crash sometimes, when the textarea magically disappears during the paste operation. TB19381542E

Comment 9

[Ryan Jones-Ward [:sciguyryan]]

(In reply to comment #8)
> If even crash sometimes, when the textarea magically disappears during the
> paste operation. TB19381542E
> 

Can reproduce that too sometimes. Not every time though - seems more random.

Comment 10

[Adam Guthrie]

Incident ID: 19381542
Stack Signature	nsTextInputSelectionImpl::ScrollSelectionIntoView 2590cf55
Product ID	FirefoxTrunk
Build ID	2006060105
Trigger Time	2006-06-01 10:35:11.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (00206c59)
URL visited	Bug 339975 - testcase
User Comments	the textarea disappeared then crash
Since Last Crash	915 sec
Total Uptime	6763 sec
Trigger Reason	Access violation
Source File, Line No.	c:\builds\tinderbox\fx-trunk-cairo\winnt_5.2_depend\mozilla\layout\forms\nstextcontrolframe.cpp, line 657
Stack Trace 	
nsTextInputSelectionImpl::ScrollSelectionIntoView   nsEditor::ScrollSelectionIntoView   nsEditor::EndPlaceHolderTransaction   nsAutoPlaceHolderBatch::~nsAutoPlaceHolderBatch   

Comment 11

[Ryan Jones-Ward [:sciguyryan]]

*** Bug 344154 has been marked as a duplicate of this bug. ***

Comment 12

[Mats Palmgren (inactive)]

Attachment: stack for the [@ nsTextInputListener::EditAction] crash

Comment 13

[Ryan Jones-Ward [:sciguyryan]]

*** Bug 361924 has been marked as a duplicate of this bug. ***

Comment 14

[Ryan Jones-Ward [:sciguyryan]]

Attachment: Possible crash fix v1

Possible crash fix v1

* Looks like calling |nsFrameSelection::ScrollSelectionIntoView| could return a |NS_ERROR_NULL_POINTER| error. Still searching for the incorrect paste problem.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I don't really know this code, so I don't think I can review it in a reasonable way.  I suggest getting review from someone who's reviewed serious changes to the edit listener stuff in the past, whoever that is...

Comment 16

[Ryan Jones-Ward [:sciguyryan]]

(In reply to comment #15)
> I don't really know this code, so I don't think I can review it in a reasonable
> way.  I suggest getting review from someone who's reviewed serious changes to
> the edit listener stuff in the past, whoever that is...
> 

OK, thanks! I've assigned this to myself so I don't forget to work on it but if anyone else wants to work on it themselves please re-assign it :)

Comment 18

[Jesse Ruderman]

Attachment: clearer testcase from bug 382768

Comment 19

[Uri Bernstein]

This WFM with

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008032104 Minefield/3.0b5pre ID:2008032104

Comment 20

[Jesse Ruderman]

WFM (Mac trunk debug) too.  It would be great if someone using Windows could retest too.

Comment 21

[Régis Caspar]

WFM on Windows 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032204 Minefield/3.0b5pre ID:2008032204

Comment 22

[Boris Zbarsky [:bzbarsky]]

Can we get a testcase in for this?

Comment 24

[[:Aleksej]]

This issue (or issues related to it) has never disappeared completely: you can always (on linux-i686) make a field in some testcases disappear.


See bug 424627, bug 451009, bug 462970, bug 483951, bug 504749, bug 522815.


bug 462970 has a good testcase attachment 368203 [details]


bug 522815 has a testcase for different steps to reproduce (see https://bugzilla.mozilla.org/show_bug.cgi?id=522815#c0). In some builds (e.g. between 2008 and 2009-09, or since 20100305), I cannot reproduce using those steps once, but still can if I perform them twice:
1. Hold Ctrl.
 2. Mousedown in the lower field.
 3. Drag outside.
 4. Mouseup.
 5. Paste.
6. Mousedown in the lower field _after the text_.
 7. Drag outside (preferably to the bottom-left).
 8. Mouseup.
 9. Paste.
Result: the field disappears.