Closed
Bug 1193153
Opened 10 years ago
Closed 9 years ago
Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines) since plain text editor uses "white-space: pre-wrap" - Caused by bug 1174452
Categories
(MailNews Core :: Composition, defect)
Tracking
(thunderbird40 wontfix, thunderbird41 wontfix, thunderbird42 wontfix, thunderbird43 wontfix, thunderbird44 wontfix, thunderbird45 fixed, thunderbird_esr38 affected, seamonkey2.39 affected, seamonkey2.41?, seamonkey2.42?, seamonkey2.43?, seamonkey2.44 affected)
RESOLVED
FIXED
Thunderbird 45.0
Tracking | Status | |
---|---|---|
thunderbird40 | --- | wontfix |
thunderbird41 | --- | wontfix |
thunderbird42 | --- | wontfix |
thunderbird43 | --- | wontfix |
thunderbird44 | --- | wontfix |
thunderbird45 | --- | fixed |
thunderbird_esr38 | --- | affected |
seamonkey2.39 | --- | affected |
seamonkey2.41 | ? | --- |
seamonkey2.42 | ? | --- |
seamonkey2.43 | ? | --- |
seamonkey2.44 | --- | affected |
People
(Reporter: RainerBielefeldNG, Assigned: jorgk-bmo)
References
Details
(Keywords: regression, Whiteboard: [regression:TB38])
Attachments
(1 file)
17.67 KB,
image/png
|
Details |
Steps how to reproduce with SeaMonkey en-US 2.39a1 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0 from official download area) Gecko/20100101 Firefox/42.0 Build 20150806070100 (Classic Theme) on German WIN7 64bit:
1. In MailNews client click inbox of a POP3 account with default
“compose messages as plain text”.
2. Click 'Compose ( → compose in Plain Text)'
» Mail Composer windows appears
3. Copy/paste 4 lines starting with a dot and trailing empty line
from “Test paragraphs” below to
Mail composer
» Looks like below
4. ' <control+a> → rightclick → copy'
5. 'click into trailing empty line → rightclick → paste
Expected: pasted lines identical to source
Actual (bug): all lines with dots have the same length, only 1 single
space between the dots
--- Test paragraphs ---
. . . . . . . . 1 Space
. . . . . . . . 2 spaces
. . . . . . . . 3 spaces
--- Test paragraphs ---
Additional information
a) Under conditions I currently do not understand in mail source code
I find all repeated space characters replaced by unbreakable spaces
“ ” (Web pages Composer seems to do that always), but that
currently is not reproducible for me in e-mail composer and I do not
know
whether this might be related
b) Web Page composer is not affected, copy/paste due to steps 1 … 5
leads to an identical copy
c) This problem has been observed by user Gerd Steffens at
de.comm.software.mozilla.nightly-builds in thread
“Composer - Tabs geändert?”
Reporter | ||
Comment 1•10 years ago
|
||
d) OS = ALL due to confirmation for Linux by user Hartmut Figge at
de.comm.software.mozilla.nightly-builds in thread
“Composer - Tabs geändert?”
e) Also REPRODUCIBLE with EN-US SeaMonkey 2.35(γ) (Windows NT 6.1; WOW64;
rv:38.0) Gecko/20100101 Build 20150807220800 (Classic Theme)
on German WIN7 64bit
f) by user Hartmut Figge at
de.comm.software.mozilla.nightly-builds in thread
“Composer - Tabs geändert?”:
Last good: 2015-04-09 15:26:00 PDT c-c:a0cba0d60fcd m-c:dd32e3ff3717
First bad: 2015-04-15 09:19:00 PDT c-c:fe7caa9e9426 m-c:379a89a9fb95
d) in <https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=DUPs1193153&sharer_id=41036>
I found possible DUP "Bug 1160880 - Selecting text & replying in plain text
eats spaces in some situations"
e) New due to confirmatin by user Hartmut Figge
Status: UNCONFIRMED → NEW
status-seamonkey2.39:
--- → affected
Ever confirmed: true
OS: Unspecified → All
Version: SeaMonkey 2.39 Branch → SeaMonkey 2.35 Branch
Reporter | ||
Comment 2•10 years ago
|
||
f) Also reproducible with TB 42.0a1 (2015-08-09)
g) copy/past is THE feature in editing, so MAJOR
h) Also might be related: "Bug 1167926 - Copy-pasted text with moz-txt-link-abbreviated link omits preceding space, breaks mailinglist-confirmation"
Severity: normal → major
Component: MailNews: Composition → Composition
Product: SeaMonkey → MailNews Core
Version: SeaMonkey 2.35 Branch → unspecified
Reporter | ||
Comment 3•10 years ago
|
||
d): appearance of problems in Bug 1160880 and Bug 1167926 match with
Last "goood / first bad" here and also are concerning something with
space character, but currently I am not sure whether they really are DUPs
(special cases of this one); currently I doubt.
See Also: → 1160880
Comment 4•10 years ago
|
||
Can you determine the regression range?
Flags: needinfo?(RainerBielefeldNG)
Keywords: regressionwindow-wanted
Reporter | ||
Comment 5•10 years ago
|
||
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #4)
Not more exactly than comment 1 f) by Hartmut Figge
Flags: needinfo?(RainerBielefeldNG)
Comment 6•10 years ago
|
||
Ideally we would have a one day regression range, i.e. works on date N, fails on date N+1
Comment 7•10 years ago
|
||
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #6)
> Ideally we would have a one day regression range, i.e. works on date N,
> fails on date N+1
Of course. Difficult to obtain though in a period where a build is not possible due to bustages. ;)
Assignee | ||
Comment 8•10 years ago
|
||
I think you're busily reporting duplicates of bug 1174452.
Your bug here is in the wrong product, this is not a TB bug, it's a Mozilla Core editor problem.
The regression was caused by:
https://hg.mozilla.org/mozilla-central/rev/47d62ded4e5f
on 10th April 2015.
As you've said in comment #1:
Last good: 2015-04-09 15:26:00 PDT
First bad: 2015-04-15 09:19:00 PDT
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Comment 9•10 years ago
|
||
@JorgK Can you elaborate why this is a dup of bug 1174452? I thought 1174452 was about HTML, this here is about plain text. However, you might be right that both bugs are caused by the same regression.
In any case, for Thunderbird 38.1 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0) I could verify today that this is very likely a duplicate of bug 1187476.
Assignee | ||
Comment 10•10 years ago
|
||
It's a common misunderstanding that there is something like a plain text editor. There is not. It's all HTML (with some stuff hidden). You can simulate all TB editing in a <div contenteditable> in Firefox.
Also, if it's a M-C core problem, which this is, you need to reproduce the problem in Firefox, since the M-C people are not interested in Thunderbird. This is what I've done in the other bug.
Assignee | ||
Comment 11•10 years ago
|
||
FYI: The TB "plain text" mode is nothing but a HTML editor where everything has this CSS style:
font-family: -moz-fixed; white-space: pre-wrap; width: 72ch;
Comment 12•10 years ago
|
||
I think we can better track the open issue (and users will recognize it better when searching bugzilla) if instead we make this blocked by bug 1174452, even though it is indeed the same bug
Status: RESOLVED → REOPENED
Depends on: 1174452
Keywords: regressionwindow-wanted
Resolution: DUPLICATE → ---
Whiteboard: [regression:TB38]
Updated•10 years ago
|
status-thunderbird40:
--- → affected
status-thunderbird41:
--- → affected
status-thunderbird_esr38:
--- → affected
tracking-thunderbird_esr38:
--- → ?
Assignee | ||
Comment 13•10 years ago
|
||
OK, we can use this bug to land the M-C patch on the TB ESR 38 release branch.
Summary: Copy paste steals multiple spaces (blanks) → Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines) - Duplicate of bug 1174452
Comment 14•9 years ago
|
||
Closing as dup of bug 1174452. If duping is wrong, please re-open.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
No longer depends on: 1174452
Resolution: --- → DUPLICATE
Assignee | ||
Comment 15•9 years ago
|
||
This was meant to be left open as per comment #12.
Updated•9 years ago
|
Assignee: nobody → mozilla
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Updated•9 years ago
|
Summary: Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines) - Duplicate of bug 1174452 → Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines) - Caused by bug 1174452
Updated•9 years ago
|
Summary: Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines) - Caused by bug 1174452 → Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines is lost by Copy when "white-space: pre;", No problem with "white-space: pre-wrap" used in HTML mode) - Caused by bug 1174452
Comment 20•9 years ago
|
||
Added "white-space: pre;" in bug summary for ease of search and understanding bug.
Updated•9 years ago
|
Summary: Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines is lost by Copy when "white-space: pre;", No problem with "white-space: pre-wrap" used in HTML mode) - Caused by bug 1174452 → Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines is lost by Copy when "white-space: pre;", No problem with "white-space: pre-wrap" ofin HTML mode) - Caused by bug 1174452
Updated•9 years ago
|
Summary: Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines is lost by Copy when "white-space: pre;", No problem with "white-space: pre-wrap" ofin HTML mode) - Caused by bug 1174452 → Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines is lost by Copy when "white-space: pre;", No problem with "white-space: pre-wrap" of HTML mode) - Caused by bug 1174452
Assignee | ||
Updated•9 years ago
|
Summary: Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines is lost by Copy when "white-space: pre;", No problem with "white-space: pre-wrap" of HTML mode) - Caused by bug 1174452 → Copy/paste from a plain text editor loses white-space (multiple spaces/blanks, tabs, newlines) since plain text editor uses "white-space: pre-wrap" - Caused by bug 1174452
Assignee | ||
Comment 21•9 years ago
|
||
Can we please leave the summary alone now. As explained in comment #11: A so-called "plain text editor" is just a normal editor using CSS "white-space: pre-wrap; width: 72ch;".
Assignee | ||
Comment 22•9 years ago
|
||
I talked to Ehsan and he told me that bug 1174452 is too hard to fix for me.
So the only option to make this work would be to back out the changeset which caused the regression on the TB 38 release branch:
https://hg.mozilla.org/mozilla-central/rev/47d62ded4e5f
Kent, what do you think?
Flags: needinfo?(rkent)
Comment 23•9 years ago
|
||
What is the plan for m-c with respect to that patch? Changes on THUNDERBIRD_38_VERBRANCH have so far only been pushing changes already landed on m-c into m-esr38 a little faster than the FF folk were comfortable with.
I'm mostly relying on your judgement, Jorg, of the correct things to do in editor. But trying to maintain a permanent difference between m-c and whatever Thunderbird compiles with is a major step that would require a pretty serious issue.
If Thunderbird is much more affected than FF we could consider changes in TB 38 but only if there is an understanding of the long-term plan to get us resynced with m-c.
Flags: needinfo?(rkent)
Assignee | ||
Comment 24•9 years ago
|
||
(In reply to Kent James (:rkent) from comment #23)
> What is the plan for m-c with respect to that patch? Changes on
> THUNDERBIRD_38_VERBRANCH have so far only been pushing changes already
> landed on m-c into m-esr38 a little faster than the FF folk were comfortable
> with.
Understood.
> I'm mostly relying on your judgement, Jorg, of the correct things to do in
> editor. But trying to maintain a permanent difference between m-c and
> whatever Thunderbird compiles with is a major step that would require a
> pretty serious issue.
I believe that many people who use "plain text" e-mail (internally "white-space: pre-wrap; width: 72ch;") are affected. There are four duplicates.
> If Thunderbird is much more affected than FF we could consider changes in TB
> 38 but only if there is an understanding of the long-term plan to get us
> resynced with m-c.
Yes, TB is more affected than FF. However, there is no medium-term plan to fix this in M-C. Once M-C fixes it, we would resync. Landing this on the TB 38 release branch is simple, it's more interesting what we do, when TB 45 comes around. Do we do another TB 45 release branch? We did for TB 38, since we wanted to land editor changes early. For TB 45 it might not be necessary.
So maybe we ask Wayne. I think he has got something to say about this bug. Is this important enough to land something special for TB which will not get resynced with M-C in the foreseeable future?
Flags: needinfo?(vseerror)
Assignee | ||
Comment 25•9 years ago
|
||
Ignore what I said altogether. Backing out
https://hg.mozilla.org/mozilla-central/rev/47d62ded4e5f
would have no effect as it would put code back into a spot which is not compiled for TB (#ifndef MOZ_THUNDERBIRD):
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDocumentEncoder.cpp#1434
This was put in there in bug 1125956 and there is also a follow-up to fix it properly: bug 1141786.
Flags: needinfo?(vseerror)
Assignee | ||
Comment 26•9 years ago
|
||
OK, I created a new bug to implement a Thunderbird specific hack: Bug 1214377.
I detected that in the exact spot that needed to be touched, there was already Thunderbirds specific code with a #ifndef MOZ_THUNDERBIRD added by Ehsan. So I am lobbying making the conditional compilation work better until a real solution is implemented.
Yes, it's a hack, but the hack was already there, so why not change it to be useful.
Comment 27•9 years ago
|
||
This will be solved by bug 1214377 right? If so, it should probably be a dup.
Assignee | ||
Comment 28•9 years ago
|
||
Right for the first part of your statement.
Comment #8 made it a duplicate of bug 1174452.
Comment #12 undid that.
Comment #14 made it a duplicate of bug 1174452.
After comment #15 this was undone again.
Since there is no fix for bug 1174452 in sight, I created a hack in bug 1214377 (which will land any minute now).
To land some M-C change on the TB 38 release branch we need a bug à la "Take bug so-and-so to TB 38.x". This is what this bug is useful for, see comment #13. You agree?
Comment 29•9 years ago
|
||
OK, so this bug will morph into a request to take a patch in our branch. Yes it fine to leave open for that.
Assignee | ||
Comment 30•9 years ago
|
||
status-thunderbird42:
--- → wontfix
status-thunderbird43:
--- → wontfix
status-thunderbird44:
--- → wontfix
status-thunderbird45:
--- → fixed
Hardware: Unspecified → All
Target Milestone: --- → Thunderbird 45.0
Assignee | ||
Comment 31•9 years ago
|
||
Actually:
Fixed by bug 1214377: https://hg.mozilla.org/mozilla-central/rev/42627d5369b3
Assignee | ||
Comment 33•9 years ago
|
||
Since this has landed recently on M-C trunk, I did some testing on a TB daily.
I can confirm that this bug is fixed and that bug 1125956 hasn't regressed.
So until the M-C people shake it up again, we are cool.
Assignee | ||
Comment 34•9 years ago
|
||
Damn, I've been using TB 45 (daily) in "production" now and it looks like bug 1125956 *HAS* indeed regressed. Looks like I got the M-C patch wrong. I'll look into it further. For the time being, there is nothing to land in TB 38.x. Sorry!
Assignee | ||
Comment 35•9 years ago
|
||
OK, finally we have this fixed on TB 45 (daily).
The first attempt was
https://hg.mozilla.org/mozilla-central/rev/42627d5369b3 (comment #31, bug 1214377 comment #12)
That wasn't quite right and has now been corrected:
https://hg.mozilla.org/mozilla-central/rev/c9bc8f46ac3e (bug 1214377 comment #25)
You need to land both patches, since the second one corrects the first one.
This could be uplifted to the TB38 release branch.
Assignee | ||
Comment 36•9 years ago
|
||
Fixed by bug 1214377.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 38•9 years ago
|
||
Still REPRODUCIBLE with inofficial (from <http://seamonkey.callek.net/contrib/>) en-US SeaMonkey 2.44a1 Mozilla/5.0 (Windows NT 6.1; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Build 20160208090255 (Default Classic Theme) on German WIN7 64bit - what ever that might mean.
status-seamonkey2.44:
--- → affected
tracking-seamonkey2.41:
--- → ?
tracking-seamonkey2.42:
--- → ?
tracking-seamonkey2.43:
--- → ?
Reporter | ||
Updated•9 years ago
|
Version: unspecified → 38
Assignee | ||
Comment 39•9 years ago
|
||
I'm not sure what you're doing. All works for me on TB 45 beta, since my fix landed on Gecko 45, see comment #35. I've also tried current trunk, TB 47. SM 2.44 is build with Gecko 47 so it should work.
The following works for me:
Copy the following six lines from here (Bugzilla) into a plaintext e-mail:
--- Test lines ---
1) . . . . . . . . 1 Space
2) . . . . . . . . 2 spaces
3) . . . . . . . . 3 spaces
--- Test line ---
In the plaintext e-mail select lines 1) 2) and 3) and copy them to the empty line following line 3), or add more lines at the end and copy them there. You can also "select all" <ctrl a>, then copy and paste.
In the plaintext e-mail select lines 1) 2) and 3) and copy them to Notepad.
All works!
Comment 40•9 years ago
|
||
Here is the result of testing my current SM-Trunk, built with GTK2.
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/2016020900 SeaMonkey/2.44a1-h
After copying the first three lines into the compose window, these three lines were selected together and then pasted below the text.
Comment 41•9 years ago
|
||
Jorg K,
Your test is a straw man. Of course it works since each line begins with a non-space character.
Try this real test...
Enter these three (non-blank) text lines into a plaintext message:
Dear Correspondent,
I am indenting this first line of my paragraph
because that's how I want my paragraph to be formatted.
and then copy them and paste them in again. Anytime I do that I get:
Dear Correspondent,
I am indenting this first line of my paragraph
because that's how I want my paragraph to be formatted.
That is a failure. Copy/paste from a plain text editor loses white-space.
The status for this bug should be: unresolved and unfixed.
I am running Thunderbird 38.5.1 which I'm told is the release channel version.
-Peter Langston
Assignee | ||
Comment 42•9 years ago
|
||
(In reply to Hartmut Figge from comment #40)
> Here is the result of testing my current SM-Trunk, built with GTK2.
Sorry, of course. There is conditional compilation at work, the fix is only compiled for Thunderbird!
https://dxr.mozilla.org/comm-central/source/mozilla/dom/base/nsDocumentEncoder.cpp#1443
(In reply to Peter Langston from comment #41)
> Try this real test...
This works as well.
> The status for this bug should be: unresolved and unfixed.
No. This bug is fixed for Thunderbird from version 45.
> I am running Thunderbird 38.5.1 which I'm told is the release channel
> version.
This bug is fixed in Thunderbird 45 and later. TB 45 will be in the release channel from mid-March. You can try a beta version now: https://www.mozilla.org/en-US/thunderbird/channel/
Comment 43•9 years ago
|
||
It would be nice to fix the bug for Seamonkey too.
Bug 1230163 could be used to track the progress of porting the fix to Seamonkey.
@Jorg, the #ifdef MOZ_THUNDERBIRD is to avoid changing the behavior of the function in Firefox?
(Is mozilla/dom/base/nsDocumentEncoder.cpp shared between Firefox and Thunderbird?)
In that case, how to solve the problem for Seamonkey (which has messenger + browser)?
It would need to be a run-time decision?
Comment 44•9 years ago
|
||
(In reply to Jorg K (GMT+1) from comment #42)
> (In reply to Hartmut Figge from comment #40)
> > Here is the result of testing my current SM-Trunk, built with GTK2.
> Sorry, of course. There is conditional compilation at work, the fix is only
> compiled for Thunderbird!
> https://dxr.mozilla.org/comm-central/source/mozilla/dom/base/
> nsDocumentEncoder.cpp#1443
:-)
Now I'm using a patch which removes the conditional and it works in my SM.
Assignee | ||
Comment 45•9 years ago
|
||
(In reply to Mason from comment #43)
> @Jorg, the #ifdef MOZ_THUNDERBIRD is to avoid changing the behavior of the
> function in Firefox?
Yes.
> (Is mozilla/dom/base/nsDocumentEncoder.cpp shared between Firefox and
> Thunderbird?)
Yes.
(You could always read the comment at
https://dxr.mozilla.org/comm-central/source/mozilla/dom/base/nsDocumentEncoder.cpp#1443)
> In that case, how to solve the problem for Seamonkey (which has messenger +
> browser)?
> It would need to be a run-time decision?
You can't have it both ways, read the comment to understand the consequences for the browser part.
If someone is interested, submit a core patch that changes
#ifdef MOZ_THUNDERBIRD
to
#if defined(MOZ_THUNDERBIRD) || defined(MOZ_SUITE)
Comment 47•9 years ago
|
||
Once we get a release of Thunderbird 45 beta that includes the patch from bug 1214377, but that would put Thunderbird 38.7.0 as the earliest release. That's probably too late to consider.
Assignee | ||
Updated•8 years ago
|
tracking-thunderbird_esr38:
? → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•