49437 - Somtimes ^K in a textarea crashes the browser

Status: VERIFIED WORKSFORME

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

Description

[David Muir Sharnoff]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD 4.0-STABLE i386; en-US; m17)
Gecko/20000815
BuildID:    000000000000000000

Two or three times I have Mozilla crash while I was trying
to submit a bug report.

This kinda discourages me from submitting bug reports so I think
this is pretty serious.

The last time this happened, I had just hit ^K when editing in the
"Steps to Reproduce" textarea.

Reproducible: Couldn't Reproduce
Steps to Reproduce:
1. Submit Mozilla bugs using Mozilla
2. Use ^K in the "Steps to Reproduce" texarea


Actual Results:  The browser crashed.

Expected Results:  The line should have been cleared to the right of the cursor.

Comment 1

[rods (gone)]

reassigning

Comment 2

[Akkana Peck]

We need a stack trace to find out what's happening.  This would be very bad
(definitely something we'd want to fix), but I'm not seeing it, so we need to
find a way to reproduce it either in debug or fullcircle builds so we can find
out where the problem lies.

Comment 3

[ckritzer (gone)]

Chaning Status to NEW

Comment 4

[rubydoo123]

on win98, I cannot get this to crash -- reporter: can you get a stack trace from 
this?

Comment 5

[David Muir Sharnoff]

I wish I could provide a stack trace.  Unfortunantly, mozilla does not
leave a core dump when it crashes on FreeBSD.  I don't have enough time
to devote to this to run mozilla under gdb.

Comment 6

[Akkana Peck]

Beth: ^K is a Unix binding, so unless you've moved the Unix XBL binding file on
top of your Windows one, you won't see this on Windows.

Comment 7

[rubydoo123]

if you can help get us a stack trace for this that would be great, marking 
future until we get additional info

Comment 8

[Blake Ross]

Adding crash keyword to all open crashers

Comment 9

[bsharma]

Updating QA contact.

Comment 10

[bsharma]

Verified on
Build: 2000092711 MN6
Platform: WinNT

Steps:
1. Load the above mentioned url.
2. Type some text in the "Steps to Reproduce" section and then press Ctrl-K.
3. The window will start scrolling up and the font size will start increasing.
4. By the time the scroll bar is at the top, a single will occupy the complete 
screen.

Reproducible: Always.

Build: 2000092909
Platform: Linux
No problem.
Behavior is as expected when pressing the Ctrl-K.

Would like to recommend a P1 priority for this bug on Windows platform.
Adding keyword "rtm".

Comment 11

[Akkana Peck]

See, however, bug 51597, which will (if approved) change the key binding for
"increase text size" to accel-+ instead of accel-k, which will eliminate the
duplicate on linux, and may help whatever problem windows is having (I can't
parse your #4 -- do you mean that it loops increasing size indefinitely?)
Cc'ing jag.

Comment 12

[lchiang]

Does the need info still apply here?  Beth asked for it on 8-21 and it sounds 
like Bindu is talking about something else?  Can I change to "rtm need info" 
since this is nominated for rtm?

Comment 13

[Peter "jag" Annema]

What bindu is seeing is definitely something else than the original report, the
ctrl-k increase font size stuff wasn't checked in till Sep 14. No idea though
what's going on there.

Comment 14

[rubydoo123]

since 51597 is now fixed, what needs to be done here?

Comment 15

[rubydoo123]

setting to future

Comment 16

[Akkana Peck]

I don't think this bug is valid any more; it covers several different problems
(the original crash, which is no longer being seen; the weird problem on
Windows, which shouldn't happen any more since it isn't on that key anyway) so
I'm closing it.

If any of these problems are still being seen, please open a new bug with a
clear summary to indicate what the current problem is.

Comment 17

[bsharma]

Build: 2000-10-24-09-MN6
Platform: WinNT

The problem does not happen any more. Akkana, you can close the bug