577240 - Editor replaces tab characters ('\t') with spaces

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[antonglv]

User-Agent:       Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100706 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; en-US; rv:2.0b2pre) Gecko/20100706 Minefield/4.0b2pre

Editor replaces tab characters ('\t') with spaces

Reproducible: Always

Steps to Reproduce:
1. Open attached test.xul file in the browser (Firefox 4)
2. Type some symbols, then press Tab key (or click "insert tab" button)
3. Press Backspace key
Actual Results:  
There is some spaces between typed text and cursor in the textbox.

Expected Results:  
There should not be spaces between typed text and cursor in the textbox.

Comment 1

[antonglv]

Attachment: test.xul file to reproduce the bug

Comment 2

[(no longer active)]

This bug will be fixed by my patch in bug 240933 (attachment 457572 [details] [diff] [review]).

Specifically see bug 240933 comment 36.

Comment 3

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Ehsan, I have concerns about this change:

1. not sure it's desirable for Thunderbird, please ping them about it
2. probably ok for a text/plain editor or a <textbox>
3. probably NOT ok for a HTML editor...

Comment 4

[(no longer active)]

(In reply to comment #3)
> Ehsan, I have concerns about this change:
> 
> 1. not sure it's desirable for Thunderbird, please ping them about it

Sure, thanks for bringing this into my attention.  Just as a summary, what happens right now is that the plain text editor replaces tabs with 4 spaces *unless* it's the first character ever typed in the editor (yes, you're reading this correctly!).

Blake Winton also mentioned that the text serializer that Thunderbird uses might be affected by this change.

> 2. probably ok for a text/plain editor or a <textbox>

This change only affects plain text editors.

> 3. probably NOT ok for a HTML editor...

See above.  :-)

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Personally, I like the current behavior, since it would seem to provide a higher degree of likelihood that the amount of space seen by the sender is more closely related to the amount seen by the recipients, given that there's no standard for the number of spaces represented by a tab character.

bienvenu may have some thoughts here, and ultimately, the which behavior would be most desirable for Thunderbird is probably clarkbw's call to me.  Adding them.

Comment 6

[(no longer active)]

Also, keep in mind that Thunderbird should be able to override the behavior if it desires.

Comment 7

[David :Bienvenu]

This feels like the kind of thing that no one is complaining about currently, but I suspect we'd get complaints if we change it.

Comment 8

[(no longer active)]

(In reply to comment #7)
> This feels like the kind of thing that no one is complaining about currently,
> but I suspect we'd get complaints if we change it.

So does that mean that a bug should be filed in Thunderbird to customize this behavior?

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #8)

> So does that mean that a bug should be filed in Thunderbird to customize this
> behavior?

It means the behaviour in Thunderbird is already the result of a rather long
and complex interoperability observation of main MUAs over the years and *any* change
even minor and perfectly reasonable from a *standalone* point of view can be
catastrophic from a *global* point of view. We send email to people (and
receive email from them) who do not all use the same MUA...

Have you studied what main MUAs do here? What do other browsers do in a
textbox? Is \t length in textboxes harmonized across platforms?

> This change only affects plain text editors.

Oh, so any code source editor based on nsPlaintextEditor will be affected...
I suspect that a way to control the tab/space behaviour is then absolutely
needed.

FWIW, I am not sure *at all* the current bug is a bug per se. It's an
implementation choice, dating back from the Netscape times, that the Editor
and Mail teams made together and based on excellent reasons. From my personal
point of view, it's probably a WONTFIX.

> the plain text editor replaces tabs with 4 spaces
> *unless* it's the first character ever typed in the editor (yes, you're
> reading this correctly!).

Absolutely. And I think it was done on purpose. (I think I recall a discussion
with beppe, brade, myself and mail team about this one).

Comment 10

[Bryan Clark (DevTools PM) [:clarkbw]]

Changing this behavior in Thunderbird would take a fair amount of effort, like Daniel points out, there is a micro and macro effect that would need to be investigated.  i.e. We need lots of research.

A good start in research toward this goal would be understanding the current behaviors of other systems (which may have changed since the original implementation); Web mail, and MUAs.  Also gathering existing (similar) requests for this change in bugzilla; not duping to this but referencing them here.

Thanks for bringing up this issue, it had never occurred to me before reading this.

Comment 11

[(no longer active)]

(In reply to comment #9)
> It means the behaviour in Thunderbird is already the result of a rather long
> and complex interoperability observation of main MUAs over the years and *any*
> change
> even minor and perfectly reasonable from a *standalone* point of view can be
> catastrophic from a *global* point of view. We send email to people (and
> receive email from them) who do not all use the same MUA...

By "customize the behavior" I meant revert back to converting tabs to spaces when bug 240933 lands.

> Have you studied what main MUAs do here?

No.

> What do other browsers do in a
> textbox?

None of them convert tabs to spaces (and for that matter, any character to any other character).

> Is \t length in textboxes harmonized across platforms?

If by length you mean the number of spaces that replace it in text editors, then absolutely not.  But most (all?) text editors have options to customize that number.

> > This change only affects plain text editors.
> 
> Oh, so any code source editor based on nsPlaintextEditor will be affected...

Yes.

> I suspect that a way to control the tab/space behaviour is then absolutely
> needed.

The contents of the textarea can always be manipulated like any regular DOM text node.

> FWIW, I am not sure *at all* the current bug is a bug per se. It's an
> implementation choice, dating back from the Netscape times, that the Editor
> and Mail teams made together and based on excellent reasons. From my personal
> point of view, it's probably a WONTFIX.

As far as <textarea> elements on the web go, it is definitely a bug.  As far as Thunderbird goes, it may be WONTFIX; *but*, in that case, Thunderbird needs to override the behavior.

> > the plain text editor replaces tabs with 4 spaces
> > *unless* it's the first character ever typed in the editor (yes, you're
> > reading this correctly!).
> 
> Absolutely. And I think it was done on purpose. (I think I recall a discussion
> with beppe, brade, myself and mail team about this one).

Looking at the code, this definitely doesn't seem intentional at all.  Here is the responsible check:

http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/text/nsTextEditRules.cpp#767

Here, when the editor is empty, |selNode| is actually the anonymous DIV, for which nsEditor::IsPreforatted returns false, but it doesn't mean that the node is not preformatted!  (In fact, it is _always_ preformatted).

Comment 12

[(no longer active)]

(In reply to comment #10)
> Changing this behavior in Thunderbird would take a fair amount of effort, like
> Daniel points out, there is a micro and macro effect that would need to be
> investigated.  i.e. We need lots of research.
> 
> A good start in research toward this goal would be understanding the current
> behaviors of other systems (which may have changed since the original
> implementation); Web mail, and MUAs.  Also gathering existing (similar)
> requests for this change in bugzilla; not duping to this but referencing them
> here.
> 
> Thanks for bringing up this issue, it had never occurred to me before reading
> this.

OK.  I expect this patch to land on mozilla-central next week, but I'll make sure to implement whatever Thunderbird needs in order to customize this behavior by the time that Gecko 2.0 is going to be shipped.

Comment 13

[Waldir Pimenta]

(In reply to comment #4)
> the plain text editor replaces tabs with 4 spaces
> *unless* it's the first character ever typed in the editor
Actually (in my case at least) it replaces tabs with spaces unless the tab is the first character ever typed on that line. If you press enter and paste a tab, it gets pasted correctly.

(In reply to comment #7)
> This feels like the kind of thing that no one is complaining about currently,
> but I suspect we'd get complaints if we change it.
FWIW, I am complaining about it currently :) If I copied a tab character, having it replaced by spaces automatically when I paste is to me an unwanted intrusion.

Also, might be worthy of checking: if I change (via firebug) a textarea's "font-family" css property to any other font (well, I haven't tested all of them, of course, but I did for several), the tab replacement ceases happening. I'm not sure why changing the font has this effect, but I thought it could be worth a look as well.

Comment 14

[(no longer active)]

(In reply to comment #13)
> (In reply to comment #4)
> > the plain text editor replaces tabs with 4 spaces
> > *unless* it's the first character ever typed in the editor
> Actually (in my case at least) it replaces tabs with spaces unless the tab is
> the first character ever typed on that line. If you press enter and paste a
> tab, it gets pasted correctly.

Yeah, that seems like a side effect that I hadn't thought about.

> (In reply to comment #7)
> > This feels like the kind of thing that no one is complaining about currently,
> > but I suspect we'd get complaints if we change it.
> FWIW, I am complaining about it currently :) If I copied a tab character,
> having it replaced by spaces automatically when I paste is to me an unwanted
> intrusion.

I believe that Bienvenu was talking about Thunderbird there!

> Also, might be worthy of checking: if I change (via firebug) a textarea's
> "font-family" css property to any other font (well, I haven't tested all of
> them, of course, but I did for several), the tab replacement ceases happening.
> I'm not sure why changing the font has this effect, but I thought it could be
> worth a look as well.

I can't think of why that would happen, but I'd appreciate if you can file a new bug for that with a test case attached.

Comment 15

[Waldir Pimenta]

(In reply to comment #14)
> I can't think of why that would happen, but I'd appreciate if you can file a
> new bug for that with a test case attached.

Bug 595778

Comment 20

[flying sheep]

it didn’t become clear to me if the patch prevents the replacement now or not. does it?

if not:
when i *paste* a tab character, it should never ever be converted to something other without the ability to disable this “feature”. if i want a tab character in there, nobody should be able to prevent me from doing so.

Comment 21

[(no longer active)]

The patch prevents the conversion.  Anything you paste into the text field should be pasted verbatim.

Comment 23

[Bizzlebin]

I haven't been using tabs in my e-mails until a short time ago, but I have noticed that the behavior of Thunderbird is still not correct, despite this issue being marked "RESOLVED FIXED". Running Thunderbird 31.0 on Windows XP SP3, I am unable to insert tab characters manually, either in the "Write" window or the "Insert HTML" window; the "Write" window changes my tabs to spaces while the "Insert HTML" window simply changes focus to the "Insert" button (I will assume that at least this behavior is expected).

Cutting and pasting tabs still doesn't work either, though. None of the built-in formatting presets (Body Text, Paragraph, Heading 1–6, etc.) allow me to paste a tab into the "Write" window, except for "Preformat". This preset, however, prevents automatic line wrapping; I do not want that behavior, only the ability to use a basic ASCII character in my message. Pasting larger compositions (not just individual tabs) into the "Write" window gives me the same problem: any tabs are auto-converted to spaces.

Things get even weirder when I paste blocks of text from a webpage (with "white-space:pre-wrap" set)in a largely standards-compliant browser (at this point, I mean something running the "Blink" engine) into Thunderbird. Everything *looks* fine before I send it, but after it goes through, both the original message and the sent version are changed completely: tabs are removed, an arbitrary line length is set (at which point my text not only wraps, but wraps with an indent at all subsequent lines), lists get list markers (numbers or bullets) arbitrarily added to them and began wrapping, indenting, and showing blank lines in strange ways, etc. Even the plaintext version in my message's source was mangled. (This is actually the same behavior I see when I cut and paste from Firefox into plaintext, so I have a feeling that this particular instance of the problem is mostly a Gecko issue and may have to be addressed elsewhere). In fact, here is part of the original of one of the messages I sent to myself as a test:

<blockquote>	This paragraph is indented. But will it wrap to the next line like in the first test e-mail? And why is there a blank line I cannot get rid of?
Testing (line 2).</blockquote>

And here is what Thunderbird sent (and turned my original into after hitting "Send"):

<blockquote>
This paragraph is indented. But will it wrap to
            the next line like in the first test e-mail? And why is
            there a blank line I cannot get rid of?

            Testing (line 2).
</blockquote>

Note the blank lines and 12-space hanging indent. As seen in the real original, only the first paragraph even had a tab, and a single one at that.

So, while I am quite grateful to the person who got us to the point where we are actually closer to basic ASCII (not even Unicode) character support in Thunderbird, sometimes, under some conditions, if the bits and bytes are correctly aligned in the recesses of the e-mail client, I do not think this issue is by any means fixed; not even close.