595778 - Tab conversion to spaces is dependent on font-family

Status: RESOLVED DUPLICATE of bug 577240

(Core :: DOM: Editor, defect)

Description

[Waldir Pimenta]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9

This seems to be a special case of Bug 577240, in that it only manifests (in Linux) if the font-family of a textarea element is set to monospace.

Reproducible: Sometimes

Steps to Reproduce:
Using the testcase attached, copy and paste the tabs in the textareas.
Actual Results:  
In Linux, bug 577240 manifests only in the textarea with monospace font-family. In Windows, it manifests always, though in a slightly different way: the tabs are converted unless they are the *first* *tab character* *pasted* *at the end* of the current line (at least this was the pattern I was able to reproduce).

Expected Results:  
Tabs should be always pasted as tabs, not converted into spaces!

Comment 1

[Waldir Pimenta]

Attachment: testcase with five textarea elements with different font-family definitions

Each textarea already has a tab character on them, for convenience

Comment 2

[(no longer active)]

I don't really understand this bug report.  I tested the testcase on Linux, and the tab was not modified in any of the textareas.  Please note that the tab character does have different widths based on the font used to render it.  Is that the problem that you're talking about?

Comment 3

[Waldir Pimenta]

No, it's not about the font-based tab width. Pasted tabs *do* get replaced by spaces in all the textareas on Windows, under the conditions I specified above (specifically, if you paste only once and at the end of the line, the tab gets correctly pasted and not converted to spaces), and in Linux (can't test it right now, but this was the result I got last time I tried it in the other computer) pasted tabs would be replaced by spaces only in the font-family:monospace textarea, according to the conditions of bug 577240 (i.e. always, unless the pasted tab is the first character of the line it's being pasted on)

I hope this clarifies things a bit.

Comment 4

[(no longer active)]

(In reply to comment #3)
> No, it's not about the font-based tab width. Pasted tabs *do* get replaced by
> spaces in all the textareas on Windows, under the conditions I specified above
> (specifically, if you paste only once and at the end of the line, the tab gets
> correctly pasted and not converted to spaces), and in Linux (can't test it
> right now, but this was the result I got last time I tried it in the other
> computer) pasted tabs would be replaced by spaces only in the
> font-family:monospace textarea, according to the conditions of bug 577240 (i.e.
> always, unless the pasted tab is the first character of the line it's being
> pasted on)
> 
> I hope this clarifies things a bit.

What I need is a set of exact steps to reproduce this...  Here's what I did for example:

1. Opened the test case.
2. Clicked in every text area, and used the arrow keys to verify that there is a tab character inside them.

Also, can you test this with the latest nightly (which should have bug 577240 fixed)?

Comment 5

[Waldir Pimenta]

Ehsan, I am kind of a newbie here so I'm trying to be as helpful as I can, but I gotta be honest, you seem not to be reading my comments. I specifically said in my first comment: "Steps to Reproduce: Using the testcase attached, COPY AND PASTE the tabs in the textareas." Granted, I didn't specify how many times you'd have to paste, but I added detailed information on my following comment when you requested it.

Yet, you say that to test the problem, you didn't even try to paste anything in the text areas. I did add a tab in each text area, but as I said in the attachment comment, those were there only for your convenience (so you wouldn't have to fire up some other editor to get the tabs needed to do the copy-paste), because *there's no way to insert a tab into a text area*!

I understand that as a developer you might have lots of things to do and I should provide information in a clear way to help you optimize your time, but I'm trying to help here, too, and skipping through my comments is really not the coolest thing to do (they weren't *that* vague).</rant>

In any case, this bug doesn't occur in the latest nightly on Windows (I'll have to test it later in Linux, but I assume it is fixed there, too), so the above is probably irrelevant now.

Last thing: as a user, and supporter of the FOSS movement, I am grateful for the time and expertise you dedicate to the project. Please take my comments above as constructive criticism.

Comment 6

[(no longer active)]

Waldir, I'm so sorry for missing copy and pasting in your original comment.  Please don't take it personally, I just read too many bug reports on any given day, and sometimes I'm careless and miss important stuff.  I totally understand that it should be frustrating to think that I haven't been paying enough attention to your comments, so please accept my apologies.

About the bug in question, I tested it on the most recent nightlies on Mac, Windows and Linux, and the problem seems to have been fixed.  I'm going to mark it as a dupe of bug 577240, but please reopen if you still see the problem on recent nightlies.

And keep up the good work with bug reporting and testing, your contribution is very much appreciated!  :-)

Comment 7

[Waldir Pimenta]

Please, no need to apologize :) I'm glad you took it positively -- I was afraid my rant was a bit too harsh. Anyway, the important thing is that the bug is fixed now :D (I'll make sure to point out any problems I might find related to it, but hopefully I won't have to). Cheers!