Closed Bug 1162963 Opened 8 years ago Closed 8 years ago
Tabs lost when copying from editor, regression from 31
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20150407092154 Steps to reproduce: 1. Create a new message in Thunderbird. 2. Write the following 3 lines to the editor: <tab>foo<tab>foo<tab><enter> <tab>bar<tab>bar<tab><enter> <tab>baz<tab>baz<tab> 3. Select all and copy to clipboard: <ctrl-a><ctrl-c> 4. Paste to editor or to another text editor Actual results: <tab>foo<space>foo<enter> bar<space>bar<enter> baz<space>baz<space> Expected results: <tab>foo<tab>foo<tab><enter> <tab>bar<tab>bar<tab><enter> <tab>baz<tab>baz<tab>
Summary: tab copy → Tabs lost when copying from editor, regression from 31.X
Steps To Reproduce: 1. Install attached xpi 2. Click somewhere of editor at the bottom of browser 3. Ctrl+A to select all 4. Ctrl+C to copy to clipboards 5. Ctrl+V to paste them Actual Results: foo foo bar bar baz baz Expected Results: foo foo bar bar baz baz Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=05532af92277&tochange=47d62ded4e5f Regressed by: Bug 1151873
Steps To Reproduce: 1. Open attached html 2. Crtl+A to select all 3. Ctrl+C to copy to clipboards 4. Launch notepad.exe 5. Paste(Ctrl+V) on to notepad.exe
Component: Message Compose Window → Editor
Product: Thunderbird → Core
Version: 38 → 38 Branch
[Tracking Requested - why for this release]:
I still plan to look at this if I get some free time.
Sorry, the Thunderbird tracking flags got lost when I added myself to the CC list since this is a core bug.
According to the summary, this issue was in ESR31 for the entire cycle with no reports. I don't think we need to take the fix in ESR38.
REPRODUCIBLE 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 This one has some common symptoms with "Bug 1193153 Copy paste steals multiple spaces (blanks)": a) Reproducible with SeaMonkey MailNews client b) Not reproducible with SeaMonkey WebPage Composer. c) Copy/paste the <tab>foo example from SeaMonkey Plain Text email composer to here to this comment field shows the problem. Also copy/paste the dotted lines in example of Bug 1193153 from SeaMonkey Plain Text email composer to here to this comment field shows the problem. d) So there might be common roots for both problems?
OS: Unspecified → All
See Also: → 1193153
Since you pinged Robert: Please note that this is most probably a duplicate of bug 1174452. Ehsan worked on that one and attached his WIP.
Please ping Robert in bug 1174452. I think we don't need two bugs so complain about whitespace getting lost.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Why put TB flags on a resolved (duplicate) M-C core bug? We should be watching bug 1174452 for inclusion in TB ESR38 when it's fixed.
Wayne decided to keep bug 1193153 open to track the Thunderbird side of this.
(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #6) > this issue was in ESR31 for the entire cycle with no reports. If the informaiton in bug 1174452 is correct this is a 38 regression, not 31. Anyway, the action for this has moved to bug 1174452.
Status: RESOLVED → VERIFIED
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #14) > (In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #6) > > this issue was in ESR31 for the entire cycle with no reports. > If the informaiton in bug 1174452 is correct this is a 38 regression, not 31. This bug was opened on 2015-05-08. Bug summary contains "regression from 31.0", however Versio:=38 is set. I bekieve "regression from 31.0 in bug summary" == "No problem in 31, regression is found in 38". I believe it's not "regression started from 31.0". Other mysterious bugs: Bug 1160880 - Selecting text & replying in plain text eats spaces in some situations Opened on 2015-05-03, but Version:=3.1 is set. Bug 1167926 - Copy-pasted text with moz-txt-link-abbreviated link omits preceding space upon send, breaks mailinglist-confirmation Opened on 2015-05-24, but Version:=3.1 is set. Problem reports on which version of Thunderbird? History looks: 1. Bug 116083 was kept open for long time, and many bugs were duped to it, and patch was landed on version=37. 2. bug 1151873 was opened for version=37, and patch was landed on version=38. 3. Then Bug 1174452 was opened for version=38. If new problem started from Thunderbird 37 or 38, change from White-space:pre-wrap to White-space:pre was done in Plain Text composing?
The summary is misleading. This worked in TB31, but not TB38. The regressing bug 1151873 was correctly diagnosed in comment #2. Comment #6 is wrong. Bug 1160880 and bug 1167926 can be reproduced in TB 3.1 (three dot one). They have nothing to do with this. Long ago white-space:pre-wrap to White-space:pre where treated differently by the M-C core editor. Copying from "pre-wrap" as used by TB always worked. As of bug 116083 both worked. As of bug 1151873 neither work. Is this enough analysis now? The action is in bug 1174452 and its TB clone 1193153.
(In reply to Jorg K (GMT+2) from comment #16) Thaanks for answer. Bug 116083 was opened on 2001-12 and many bugs were duped, and patch for Bug 116083 was landed on version=37, then Bug 1151873 was opened for 37 and patch was landed on version=38, then Bug 1174452 was opened for 38. If Bug 116083 for Whitespace:pre was applicble to Thunderbird, and if Thunderbird's Plain Text composer had used/was using/uses Whitespace:pre, I think one of Bug 116083, bug 1151873, and Bug 1174452 should occur in any Thunderbird version. i.e. phenomenon like Thunderbird Bug 1193153 should occur in any Thunderbird version. Why problem of Thunderbird Bug 1193153 started to occur from version 38(or 37) even though Bug 116083 was not fixed for lo--ng time.
I repeat what I said: Long ago white-space:pre-wrap to white-space:pre where treated differently by the M-C core editor. Copying from "pre-wrap" as used by TB *always* worked. I repeat: It always worked, even before bug 116083 was fixed. As of bug 116083 pre-wrap continued working and pre started working. See details here: attachment 8530567 [details] [diff] [review]. Code deleted, the special treatment for pre-wrap used in TB that always worked: Find(NS_LITERAL_STRING("pre-wrap") Code inserted: case NS_STYLE_WHITESPACE_PRE: case NS_STYLE_WHITESPACE_PRE_WRAP: case NS_STYLE_WHITESPACE_PRE_LINE: case NS_STYLE_WHITESPACE_PRE_SPACE: Now all variation of pre* worked. As of bug 1151873 no pre* works.
(In reply to Jorg K (GMT+2) from comment #16) > Bug 1160880 and bug 1167926 can be reproduced in TB 3.1 (three dot one). Is this reason why you set 3.1(three dot one)? (See History, please) You did dupliction test with Tb 3.1 in 2015/08 even though reporter says Tb 31 or Tb trunk? Or you knew phenomenon of these bugs well in Tb 3.1 and successors? Bug 1160880 : Version: field of 31 was changed to 3.1 by firstname.lastname@example.org on 2015-08-11. Bug 1167926 : Version: field of trunk was changed to 3.1 by email@example.com on 2015-08-13.
Why are we talking two completely different bugs in this bug here? I tested both on TB 3.1 (three dot one): See bug 1160880 comment #9 and bug 1167926 comment #3. I tested them on 3.1 to see whether they had anything to do with the pre/pre-wrap issues. Result: They are different issues.
(In reply to Jorg K (GMT+2) from comment #20) > Why are we talking two completely different bugs in this bug here? Because this bug has confusing "regression from Tb 31", and it actully produced confusion. I wanted to know what is problem in which version in this bug which is already cloased as dup, And I wanted to know difference aamong following. (i) Report for Tb 38(some may be for Tb 37), including this bug. Bug 1196662 and dups of it(1186394 1187712 11919 05 1196164 1196710 1197512 1197515 1197844 1198707 (ii) Report for Version:trunk/31 in 2015/05, which had changed to Version:3.1 by you in 2014/08. Bug 1160880, Bug 1167926 (still open, not duped to Bug 1196662). Note-1: patch by Bug 116083 was landed on version=37. Note-2: No Product=Thunderbird nor MailnewsCore in dup bugs of Bug 1160880. Produc=Firefox or Core only. Note-3: Following is seen in lines removed by patch for Bug 116083. > - // check for moz prewrap style on body. If it's there we are > - // in a plaintext editor. This is pretty cheezy but I haven't > - // found a good way to tell if we are in a plaintext editor. Change by Bug 116083(landed on 37) produced problems in Thunderbird, and change by Bug 11518738lnded on 38) resolved partially in 38, but problem of bug 1174452 still remains in 38. If so, Bug 1196662 and dups of it (report on Tb 38) can be explained. However, it can not explain Bug 1160880 and Bug 1167926, which was set as Version=3.1 by you and you could reprodue problem of Bug 1160880 and Bug 1167926 in Tb 3.1. It can not explain why "no Product=Thunderbird bug in dup bug of Bug 116083".
I suggest to stop the discussion now. Bug 116083 caused NO problems in TB. Before bug 116083 pre-wrap worked for TB and after bug 116083 pre-wrap continued working. Only that after bug 116083 pre also started working (copying whitespace). This is not used in TB but only in FF. Since pre behaved differently after bug 116083, someone raised bug 1151873 (copying rich text). Sadly, as a fix, both pre-wrap and pre were changed, so now rich text copied, but not whitespace, so by this fix, TB is now affected. This is now reported in bug 1174452 and its TB clone bug 1193153. The other two bugs, bug 1160880 and bug 1167926, are independent. The already occur from version 3.1. The hibernation bug 1196662 has nothing to do with any of that. As far as I see it, everything is now correctly categorised.
(In reply to Jorg K (GMT+2) from comment #22) Thanks for explanaation.
You need to log in before you can comment on or make changes to this bug.