54734 - tabs in textarea widgets cause assertions

Status: RESOLVED WORKSFORME

(Core :: DOM: Editor, defect, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

FreeBSD 4.1 20000928xx

Tabs (0x09) in textarea widgets cause assertions.  The assertions happen often
(such as every time the window gets focus).  The data in question was pasted
into a bugzilla description with a line that begins with a tab followed by some
text.  Deleting the tab solves the problem.

This appears to be due to a line having a single '\t' on it confusing
the line-splitter in the editor (nsHTMLToTXTSinkStream::AddToLine).  I think
there's a problem with the logic in that function.

#1  0x281adae4 in nsDebug::PreCondition (aStr=0x2a059285 "aPos > aLen",
    aExpr=0x2a059278 "aPos <= aLen",
    aFile=0x2a05912b "nsJISx4501LineBreaker.cpp", aLine=448) at nsDebug.cpp:396

See attachment for full backtrace and structure dumps.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: backtrace and structure dump

Comment 2

[rubydoo123]

assigning to anthonyd for review and debugging

Comment 3

[anthonyd]

I cant reproduce this at all with the newest build.  Maybe this was fixed by 
noXIF landing? Hmmm, Reporter, can you try and repro?  Till then I am marking as 
WORKSFORME.

anthonyd

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Still there.  Note that the assertion doesn't fire until the text area loses and
regains focus (move the mouse out to some other window, then back over the
mozilla window), as per the original note.
FreeBSD 4.1 20001012xx

Comment 5

[anthonyd]

Rendell,

I'm sorry man but I cannot reproduce this, are you only trying this on BSD (per 
your comment)?  I need some more information, and also, have you tested this 
with a newer build, or just PR3?

anthonyd

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

I tested it using a trunk pull, pulled and built yesterday afternoon.
I'm repulling as I type and will recheck.

Have you tested under GTK/Linux?  Your WFM didn't specify OS, trunk or branch,
what build(!) etc.  _please_ always specify where it WORKSFORME when marking a
bug in such a way.

If you need a BSD build to test, check with [e-mail]; he has a BSD
box that last I knew was open for people to test on.

Comment 7

[anthonyd]

Randell,

The bug report says platform PC, os ALL.  As for what I tested on, I always test 
with a fresh Trunk build and for this bug I tested it on Windows.
Let me know how your new test goes, and if this bug is BSD only, the report 
needs to be marked as such.

anthonyd

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Retested with FreeBSD 20001013xx.  Still there.

Setting OS=freeBSD - Note, not because I've tested under anything else, but
because you WFM'd from  Win32 (I assume).  I assume this will apply to Linux as
well, but I don't have a linux setup, and even if I did there's no "gtk" or "all
unixes" entry.  I would like to see it re-tested under Win32; and from looking
at the code I see no reason to believe the bug is Unix-only (but it may be
harder to provoke under others).

Again, here's the simple sequence:
Go to a new bug entry page in bugzilla.
In Description, type "This is a test" and a return.
The type a Tab and "test" and return
Then click outside the description widget.

Poof, assertion.
We could use Linux testing from someone, and I'd like to see retesting under
win32.

Comment 9

[anthonyd]

I just tried to test this with today's build (pulled this morning) on win32 and 
could not reproduce it.

anthonyd

Comment 10

[Fabian Guisset]

Please see comments on bug 58303.
Fabian.

Comment 11

[anthonyd]

ok, there is a problem here when there is only a tab(s) in a textfield.  There 
is a problem calculating the offset with the tab, and then placing the caret.  
adding joe francis to the cc list, so hopefully can get some expert whitespace 
help from joe.

anthonyd

Comment 12

[anthonyd]

moving to 0.9.1

Comment 13

[anthonyd]

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

Comment 14

[Kathleen :Brade]

moving to milestone mozilla1.0; add helpwanted
This bug might be moved to Future at another time since it's not easy for users 
to get just a "tab" character into a textarea anymore.

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

Retested with mozilla 20010417xx.  Assertion is still there.  Tabs can be
entered by pasting test (select some text with a tab in some other window, go to
a bugzilla textfield and paste.  Assertions.  Probably also a problem if the
textfield is initialized with a tab in it.

Comment 16

[anthonyd]

moving to 0.9.3. per beppe (assert here)

anthonyd

Comment 17

[rubydoo123]

--> kin

Comment 18

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 19

[Shotaro Kamio]

It seems to me that the problem in calculating the offset of the tab is related
to Bug 58712.

Comment 20

[Shotaro Kamio]

I got similar message from my *debug build* as follows:
----
###!!! ASSERTION: aPos > aLen: 'aPos <= aLen', file nsJISx4501LineBreaker.cpp,
line 465
###!!! Break: at file nsJISx4501LineBreaker.cpp, line 465
----

Steps to reproduce:
(Try in debug build.)
1. open new text mail message composer.
2. Type TAB.
3. do "Save As Draft"
You'll see this assertion.

In addition, if you use my experimental patch for Bug 144188,
this assertions are gone.

(I have no idea whether my patch fixes this bug(54734) also or not.)

Comment 21

[Martijn Wargers (dead)]

Is this still an issue?

Comment 22

[Mihai Morar, (:MihaiMorar)]

Is this still reproducing on latest versions using New Profile and in Safe Mode?

Comment 23

[Martijn Wargers (dead)]

Let's just resolve->WFM this bug, there was no activity > 11 years.