Closed Bug 98572 Opened 23 years ago Closed 23 years ago

cut & paste from <pre> always adds <newline> at the end of pasted text

Categories

(Core :: DOM: Serializers, defect)

Product:
Core
Component:
DOM: Serializers
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 75283
Milestone:
mozilla0.9.9

People

(Reporter: sujay, Assigned: t_mutreja)

References

Details

(Keywords: topembed, Whiteboard: EDITORBASE+; fixinhand?; need r=, sr=, testing; [plntxt][QAHP])

Attachments

(1 file)

patch to plaintext serializer
5.86 KB, patch
Details | Diff | Splinter Review
when cutting & pasting text from a text (not html!) file to another application, a <newline> is also created. ------- Additional Comments From Doron Rosenberg 2000-10-08 03:37 ------- what buildid does your build have? ------- Additional Comments From Asa Dotzler 2000-10-09 13:30 ------- so you're copying text from a browser window which has a foo.txt loaded into the content window? Or, your're copying text from a Composer window with a text file loaded? Or, you're copying text from a Composer window which has some plain text typed into the content area? Or, you're copying text from a plaintext email you're recieved? Or, you're copying text from a message compose window you've just typed palin text into? Reporter, please provide clear and specific steps to reproduce. Please also include the buildID you tested. Thank you for testing mozilla and reporting bugs. ------- Additional Comments From Bjoern Jacke 2000-10-14 08:20 ------- my build has been 2000100409 ... I copy text from the browser to a different application. HTML is fine but plain text files ftp://ftp.dante.de/pub/tex/support/rmligs/README don't work. To reproduce it just load the file into your mozilla, mark some text with you left mouse button, paste it to a vi running in an xterm with your middle mouse button. Sorry I didn't add a full decription in the report but I thought this would be trivial to reproduce. ------- Additional Comments From David Krause 2000-10-14 21:49 ------- *** Bug 56631 has been marked as a duplicate of this bug. *** ------- Additional Comments From David Krause 2000-10-14 21:51 ------- Confirming on linux cvs build 2000101321, this bug has been driving me crazy for a while now. ------- Additional Comments From David Krause 2000-10-14 21:52 ------- Forgot to click Confirm bug. :) ------- Additional Comments From David Krause 2000-10-14 21:56 ------- Steps to reproduce: Select text in urlbar. Paste it into an xterm, for example, and notice that there is a newline. I'm not sure which component this should go into. ------- Additional Comments From Decklin Foster 2000-10-14 22:30 ------- *** Bug 56583 has been marked as a duplicate of this bug. *** ------- Additional Comments From Decklin Foster 2000-10-14 22:31 ------- *** Bug 56695 has been marked as a duplicate of this bug. *** ------- Additional Comments From Decklin Foster 2000-10-14 22:34 ------- I think this one is jfrancis (see #54851), duping my bug filed against him and another one. If not, pass it on... ------- Additional Comments From KOIKE Kazuhiko 2000-10-15 00:48 ------- The reporter said copy from a html file worked fine, but I see it doesn't work on Win98. ------- Additional Comments From Doron Rosenberg 2000-10-15 01:26 ------- qa for selection is my friend blake ------- Additional Comments From timeless@linuxworld:/vacation 2000-10-15 09:20 ------- Akk: is this up you alley? ------- Additional Comments From Tobias Burnus 2000-10-16 00:56 ------- Suggest: OS=all since in bug 56631 is was also seen with Windows2000. ------- Additional Comments From Ben Bucksch 2000-10-16 21:43 ------- Joe, is the follwoing covered by this bug?: copying from urlbar or any textfield (like in bugzilla) into the composer gives newline, text *in monospace*, newline. The formatting worries me most. It is plaintext what I am pasting, and I want no formatting, not <pre>. Pasting into another app, copying ther and pasting into Mozilla Composer works as expected. All on Linux. ------- Additional Comments From beppe@netscape.com 2000-10-17 12:28 ------- moving to future, until we get the fix dates down ------- Additional Comments From Ben Bucksch 2000-10-17 12:40 ------- Filed bug 57041 about the problem mentioned. ------- Additional Comments From jfrancis@netscape.com 2000-10-19 10:02 ------- moz 0.9 ------- Additional Comments From Jesse Ruderman 2000-10-19 10:51 ------- *** Bug 57031 has been marked as a duplicate of this bug. *** ------- Additional Comments From Decklin Foster 2000-10-28 12:18 ------- *** Bug 57791 has been marked as a duplicate of this bug. *** ------- Additional Comments From Decklin Foster 2000-10-28 12:19 ------- *** Bug 57915 has been marked as a duplicate of this bug. *** ------- Additional Comments From Chris Siebenmann 2000-11-07 15:26 ------- This also happens for text in <pre> blocks (in a browser window), such as in these bug reports. (Current Linux CVS trunk pull/build.) This also appears to happen for selections in non-<pre> text under some situations: if the selection starts at the start of a new paragraph or a new container, it appears to generate the newline on pasting. (Merely a new line, from a <br>, doesn't seem to do it.) Eg: on this web page, selecting 'Bugzilla Bug' and pasting will generate a newline, but selecting 'Bug List:' will not. Selecting 'Bug 55661 depends on' will, and so on. ------- Additional Comments From Boris Zbarsky 2001-01-01 22:04 ------- *** Bug 64059 has been marked as a duplicate of this bug. *** ------- Additional Comments From Scott Gifford 2001-01-02 02:05 ------- Added self to cc. ------- Additional Comments From Keyser Sosez 2001-01-02 21:46 ------- *** Bug 64159 has been marked as a duplicate of this bug. *** ------- Additional Comments From Akkana 2001-01-03 11:54 ------- I nominated 56135 for nsbeta1, and this is the same bug (not sure which Joe wants to be the real bug and which one the dup), so I'll nominate this one as well. ------- Additional Comments From Boris Zbarsky 2001-01-05 08:13 ------- *** Bug 64392 has been marked as a duplicate of this bug. *** ------- Additional Comments From jfrancis@netscape.com 2001-01-20 02:09 ------- dup *** This bug has been marked as a duplicate of 56135 *** ------- Additional Comments From Stephan Niemz [faniz] 2001-01-21 08:07 ------- Is this really a dup? Bug 56135 is about MailNews, this is about the Browser. And bug 56135 is about copying from the Subject field, this bug is about copying from/to anywhere in the browser. ------- Additional Comments From jfrancis@netscape.com 2001-01-22 13:47 ------- it's the same bug, really. ------- Additional Comments From Stephen Walker 2001-01-25 21:22 ------- vrfy dup ------- Additional Comments From jfrancis@netscape.com 2001-02-07 12:07 ------- reopening. related issues in bug 56135 are fixed, but copying from pre's still exhibits this behavior, and will require a separate fix. ------- Additional Comments From Akkana 2001-02-07 13:21 ------- It's a bit complicated, because if I select across lines, I want to get the line breaks (e.g. if I select one stanza of a poem), but if I select just a word or two, I don't want line breaks. In other words, I do want line breaks that are inside the block I've selected; I just don't want an extra newline at the end of what I've selected (unless I've selected the entire contents of the pre block). Maybe that's not really that complicated after all. ------- Additional Comments From jfrancis@netscape.com 2001-02-07 17:21 ------- What Akkana is asking for would just work if copies from inside pre's always copied as plaintext. If you pasted that into html, it would be a text insertion, and returns would automatically be converted into breaks. Getting a plaintext paste to exhibit the desired behavior is free. Making the determination that we want a plaintext copy is the hard part. All the other code that examines the selection during copy happens _after_ we have decided whether to do a text or html copy. I'll have to bend things around a bit to get this to work. ------- Additional Comments From Ben Bucksch 2001-02-07 20:32 ------- jfrancis, I can see your coding problems, but logically, it's easy: If the selection is only inside a <pre> (or exactly all of the <pre>), use plaintext flavor. If the user selects something outside the <pre>, use HTML flavor. ------- Additional Comments From Peter Lairo 2001-02-08 01:26 ------- shouldn't soft returns be pasted as soft return (thus adjusting the linewraps to the new window width) and hard returns be pasted as hard returns? This would be the desired solution. I've also noticed that when pasting into a message, the text is pasted as "preformatted" text and not as "body" text, as one would expect. Paste should simply paste as plain text (body) unless the message one is pasting into AND the copied text are BOTH formatted. ------- Additional Comments From Ben Bucksch 2001-02-08 04:28 ------- > shouldn't soft returns be pasted as soft return (thus adjusting the > linewraps to the new window width) and hard returns be pasted as hard > returns? This would be the desired solution. There's nothing like soft returns in normal plaintext. > I've also noticed that when pasting into a message, the text is pasted as > "preformatted" text and not as "body" text, as one would expect. Yeah, that's what this bug is about. That "preformatted" (i.e. <pre>) is what causes the newline at the end. ------- Additional Comments From Peter Lairo 2001-02-08 04:55 ------- would it be possible to put soft returns into plain text? Is mozilla or netscape capable of suggesting / implementing such a standard? (if not, who?) If either answer is yes, it should definetely be pursued as top priority and i will post a bug for it. This is still the *major* drawback of all e-mail formatting issues. ------- Additional Comments From Stephan Niemz [faniz] 2001-02-08 07:19 ------- Please let's keep the focus on the bug. Such a discussion would be more appropriate in one of the newsgroups. ------- Additional Comments From Keyser Sosez 2001-03-21 16:26 ------- *** Bug 70603 has been marked as a duplicate of this bug. *** ------- Additional Comments From Scott Gifford 2001-03-30 14:31 ------- FYI, I'm still seeing this bug on 2001032614. ------- Additional Comments From Dimitri Papadopoulos 2001-04-13 03:38 ------- I'd like to add that this not only the case with <PRE>. Cut & paste from <H1>, <H2>, <H3>... also adds newline. Seen on Netscape 6.01A on Solaris 8/SPARC. Looks like this is the same bug? ------- Additional Comments From jfrancis@netscape.com 2001-04-16 17:49 ------- sigh. this is not happening anytime soon. ------- Additional Comments From beppe@netscape.com 2001-05-03 15:28 ------- need to investigate further before we work on the resolution ------- Additional Comments From Jacek Piskozub 2001-05-31 11:27 ------- 10 dups. Making mostfreq. ------- Additional Comments From jfrancis@netscape.com 2001-06-01 13:32 ------- One alternative that would solve this and a host of other problems would be to *not* copy <pre> unless all of it is selected. Ie, make <pre> copy rules identical to the rules for other block elements. This would have the bad effect that you would lose the pre-formatting when copying parts of pres. ------- Additional Comments From Dimitri Papadopoulos 2001-06-05 02:47 ------- Again note that this is not only a <pre> issue. The same happens with <h1>, <h2>, <h3>, ... ------- Additional Comments From jfrancis@netscape.com 2001-06-05 02:55 ------- Dimitir is correct. The H1, ..., H6 elements are the other blocks that behave like pre when we copy. Ie, we force them to be emitted even if you are only copying something inside them. Other blocks we don't copy unless you either: are copying everything inside them, or copy across at least on of the boundaries (start or end) of the block In contrast, there are lots of non-block elements that we will copy even if you only have some interior content selected. Basically all the tags that are used for stylistic purposes (b, i, u, tt, s, strike, em, strong, ....). ------- Additional Comments From Ben Bucksch 2001-06-05 12:01 ------- Joe, I don't think, it is a good idea to ignore <pre> (and thus plaintext formatting) when only parts are copied. ------- Additional Comments From jfrancis@netscape.com 2001-06-18 14:23 ------- *** Bug 86172 has been marked as a duplicate of this bug. *** ------- Additional Comments From KOIKE Kazuhiko 2001-06-19 13:05 ------- *** Bug 85077 has been marked as a duplicate of this bug. *** ------- Additional Comments From Boris Zbarsky 2001-07-03 20:57 ------- *** Bug 89036 has been marked as a duplicate of this bug. *** ------- Additional Comments From _basic@yahoo.com 2001-07-11 11:23 ------- *** Bug 90340 has been marked as a duplicate of this bug. *** ------- Additional Comments From Jacek Piskozub 2001-07-11 11:30 ------- Dup bug 90340 is about View Source. Is the actual syntax of view source (we do not see it - bug 74862) a big <pre> block? If not, bug 90340 is not a dup of this one :-( ------- Additional Comments From Boris Zbarsky 2001-07-11 11:37 ------- View-source uses a big <pre> block, yes. ------- Additional Comments From Jesse Ruderman 2001-08-08 11:19 ------- *** Bug 94342 has been marked as a duplicate of this bug. ***
Whiteboard: [plntxt][QAHP]
Target Milestone: --- → mozilla0.9.7
*** Bug 55661 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
*** Bug 100055 has been marked as a duplicate of this bug. ***
Whiteboard: [plntxt][QAHP] → EDITORBASE; 1,000,000 days; [plntxt][QAHP]
So this bug will take over 2700 _years_ to fix? If you include the original bug (bug 55661) which was marked netscape confidential and then duped to this, this bug has 17 dupes, and is editor's most frequently reported bug according to http://bugzilla.mozilla.org/duplicates.cgi If its going to be a lot of work to fix, thats one thing, but I'm sort of curious how the 1,000,000 day estimate was arrived at, and what point such an estimate has.
*** Bug 101551 has been marked as a duplicate of this bug. ***
*** Bug 103362 has been marked as a duplicate of this bug. ***
Blocks: 104166
Won't report another duplicate, just add myself to CC list....
*** Bug 106419 has been marked as a duplicate of this bug. ***
*** Bug 107127 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.7 → mozilla0.9.9
*** Bug 109587 has been marked as a duplicate of this bug. ***
*** Bug 104462 has been marked as a duplicate of this bug. ***
*** Bug 113189 has been marked as a duplicate of this bug. ***
*** Bug 114389 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.9 → mozilla1.0.1
*** Bug 96749 has been marked as a duplicate of this bug. ***
Clearing milestone for reconsideration, and nominating for moz1.0. According to http://bugzilla.mozilla.org/duplicates.cgi, this is editor's second most frequently reported bug, with 25 dupes. (The bug with more dupes (28), bug 4302, has a whole lot of dependancies, and looks like its become a semi-meta bug.) This behaviour is annoying. It affects cut and paste (not just plaintext mail compose), and should really be fixed.
Keywords: mozilla1.0
Target Milestone: mozilla1.0.1 → ---
This bug is a nightmare. I just know someone is going to come along and "fix" it and cause even more trouble than we have now. Some ideas along with problems: 1) solution: when an entire copy is wrapped in a <pre>, we could have the plaintext serializer strip off a trailing newline after serialization is complete. problem: this would only help when pasting into plaintext contexts. When pasting into html context, we would still have the related problem that it would paste in as an entire <pre> block, when often what the user wanted was just the text (merged into whatever block they pasted into). 2) solution: in the copy code we force out <pre> into the transerfable data if the copy is inside a <pre>. We could instead force out a <span style: white-space pre> (css syntax probably wrong: off the top of my head). We would only do this in the case where we are forcing the <pre> to be output. In the "natural" case where the user actually selected the entire <pre>, we would copy the <pre>. This would give us the desired behavior for both plaintext and html copy, since the span won't cause a newline when serialized to plaintext and will merge into existing blocks when pasted in html. problem: If you do this into html email and mail it to someone using NS4x they will see ugly yellow tag icons in their mail. ns4x is not "span safe". This would also give odd results when the user copied part of a <pre> and then part of some additional content after it. They would lose the "boundary" between the two chunks of content at paste time, since the span won't cause a block boundary. 3) solution: we read the mind of the user. problem: I am not smart enough to implement this. I'm not moving this milestone end unless and until there is a workable plan, and I don't have one.
Target Milestone: --- → mozilla1.1
The other problem with solution number 2 is that there is no easy way in the html editor to do anything with a span. for instance, if the user pasted it somewhere and didnt want the white-space: pre style, they would not have an easy way to remove it. At least with a <pre>, they can put their caret at the front of it and backspace, which will destoy the <pre> and place it's former contents into the preceding block.
why can't we decide to copy text as text/plain if it's all inside a single tag? ref @2001-02-07 17:21, @2001-06-01 13:32, @2001-06-05 02:47, @2001-06-05 02:55
99% of the dups here would be fixed by solution 1. People seem to only get really upset about the carriage return when they paste some text that looks safe (like a single character) into a shell and a command is executed as a result. It seems to me that the plaintext and html problems should be separated, since the user requirements in the two cases are fairly different and the consequences of this bug are much more serious in the plaintext case. The HTML problem is indeed hard and not nearly as urgent as the plaintext. It sounds like a simple fix is available for the plaintext problem. Nominating to implement solution #1 for 0.9.8. Joe, would you like me to spin off a separate bug on the plaintext serializer issue only?
Keywords: mozilla0.9.8
In addition to what bz said, none of the arguments jfrancis gave explain why I get two blank lines after pasting one character from the middle (not the end) of the pre block, or why anyone would ever want that behaviour, whether pasting into plain text or html. Note that this bug was originally opened on cutting and pasting _from_ a text file. I tried to trace through the code, but got lost. gdb deciding that I was calling pure virtual methods all the time didn't help, and the abuse of string ownership rules didn't make things easier, either.
Joe: here is what I think it should do (this would solve bug 49176 as well as this one): We iterate over the selection. When we cross a block boundary (i.e. descend into a block from outside it, or ascend out of a block from starting inside it), that block is added to the paste context. If we do not cross a block boundary (i.e. the selection is entirely inside a pre, or entirely inside a table, both of which are common cases which are causing all these dups) then we don't copy the block to the context, and the text will paste as though the block hadn't existed. This is the right thing for paste-into-plaintext, and in the cases I've been able to think of it's right for paste-into-html as well (though you may know of cases where it's not -- I know you've spent a lot of time thinking about edge cases, so please tell me where I'm going wrong). I know how to write the "iterate over the selection and notice if we're crossing a block boundary" code -- that's not hard. But it's quite different from what the copy code is doing now, and I don't understand the current code, so I've been reluctant to dive in and rip out the existing code without an understanding of what it's doing now and how the context is set up since I'm sure there are reasons for what the current code is doing.
I realize this is a "simple" suggestion that would leave us with yet another menu item, but would it be a bad idea to implement the current "copy" for standard TEXT only, and add a "copy as HTML" or "copy special" for passing the HTML/whatever from the source window? For those control freaks out there, maybe you could pref the control-C behavior to one or the other.
I've always apreciated and frequently used the *context menu* feature in WordPerfect: +--------------------------+ | Paste | | Paste without attributes | <-- or "Paste as plain text" +--------------------------+ It the the feature I miss most since my company forced us to switch to M$ Word.
On that note - is "Paste without Formatting" more intuitive, and is it accurate? If so, I'm not opposed to the solution of giving the user the option to paste in formatted text by default, and choose to retain the attributes by choosing the other option.
I don't think paste without formatting helps much. As has been mentioned previously, the primary problem with this bug is when you're copying from Mozilla and pasting into another app, especially a UNIX terminal window. Those apps aren't going to have a paste without formatting menu.Copy without formatting is better, but particularly on UNIX, it's counterintuitive---when I hilight words, I expect them to be on the clipboard and usable by other apps immediately.Copy with formatting is better still, and default to copy without formatting, but people who actually use the editor might not like it.
Agreed. We have a separate bug somewhere to allow a choice of various types of paste in the editor, but that doesn't fix the bug at hand, which is that we advertise plain text on the clipboard but add to the copy some characters which shouldn't be part of the text.
Just pitching in to say that this bug also afflicts xmlterm, the xterm implementation using mozilla. Cutting a filename from a PRE block and pasting it at the command line causes the command to be (unexpectedly) executed because of the extra newlines. I would suggest going with solution #1 or the one proposed by Akkana.
*** Bug 106448 has been marked as a duplicate of this bug. ***
*** Bug 120618 has been marked as a duplicate of this bug. ***
hey joe, if i buy you a six-pack of your favorite beverage, is there any chance of getting this fixed before the year 5775? ;) I'm not kidding.
plussing cause a million days seems doable
Whiteboard: EDITORBASE; 1,000,000 days; [plntxt][QAHP] → EDITORBASE+; 1,000,000 days; [plntxt][QAHP]
Keywords: nsbeta1+
ok, i think i have a workable plan on how to fix this, by tweaking the plaintext serializer. The basic idea is that newlines caused by closing block tags should not be emmitted until something after them is forced to be emmitted. That way we will effectively strip trailing newlines caused by block closures.
Status: NEW → ASSIGNED
Whiteboard: EDITORBASE+; 1,000,000 days; [plntxt][QAHP] → EDITORBASE+; 3 days; [plntxt][QAHP]
Target Milestone: mozilla1.1 → mozilla0.9.9
Joe, I don't want to hold you back, but are you sure that this is the right strategy? > The basic idea is that newlines caused by closing block tags should > not be emmitted until something after them is forced to be emmitted. But if I select an entire block (e.g. complete <ul>), I would expect a newline at the end. It's no tragedy, if there isn't one, but it's not right (TM). Akk's suggestion in comment 20 looks good to me, but I can't comment on feasibility of implementation.
The iterator I requested for Find would also make it easy to check for block boundaries as in comment 20. There are lots of places where it would be helpful to see tags both going in and going out ...
Jeo, you may want to take a look at the patch in bug 94176, if you want to stick to your plan. Not sure, if it helps (|mLineBreakIsDue|), but it might.
Whiteboard: EDITORBASE+; 3 days; [plntxt][QAHP] → EDITORBASE+; fixinhand?; need r=, sr=, testing; [plntxt][QAHP]
My attempt at fixing this. I don't know the serializer well enough to tell if I've broken something. FlushLines() usage is the big worry. I actually think the comment in FlushLines() about wrapping won't be a problem here, due to when I call it. But I could be wrong. What I'm more worried about is getting out of sync with mEmptyLines. However in testing I couldn't get anything bad to actually happen, and this does seem to fix the problem. I need the serializer experts to jump in here and tell me if I'm full of it. I suppose we may want to land the fix even if it *is* wrong, if the regressions are actaully not as bad as the bug.
To address Ben's comment #32: Ben, my fix can easily be tweaked in this regard. In my first cut I made everything in DoCloseContainer() use my "delayed" vertical spacing, with the exception of html and body tags. I figured if we are emitting an entire doc we want the trailing vertical space. However we could restrict the fix to just pre closures. Just remove the trailing ",PR_TRUE" param from the EnsureVerticalSpace() calls.
Daniel Bratell is the right one to review that.
I think you and Tanu Mutreja is duplicating eachothers work to fix two instances of the same problem, that newlines aren't output lazily. Tanu Mutreja is working in bug 75283, and I suggest you coordinate this with him so we get a general solution for all block level tags. I haven't looked enough at the patch to say whether it's the right thing to do. I'll look more at it when you've talked to Tanu.
I made a note for Tamu in bug 75283. However, the serializer folks should take this and run with it. "My work here is done". If it helps, great. If it doesn't, double your money back.
over to serializer owner....
Assignee: jfrancis → harishd
Status: ASSIGNED → NEW
Component: Editor: Core → DOM to Text Conversion
Keywords: topembed
--> Tanu
Assignee: harishd → tmutreja
Tanu's "isLinebreakDue" patches essentially implement the same thing Joe did here; the additional "float" argument to EnsureVerticalSpace is a red herring since it's always passed as PR_TRUE, so we might as well just assume that as in Tanu's earlier patches.
I'm not sure what you meant by a red herring. Float is not always true. It defaults to false. so that I would not have to touch all the pre-existing calls. There are plenty of calls where it is defaulting to false.
I'm also not sure how Tanu's fix interacts with pre's and headers. I though we emitted *two* newlines for these (in order to get a blank line for vertical margin). Does Tanu's patch hide both of these newlines?
does the patch in 75283 fix this bug? If so, that would be great! I would prefer to have Tanu's patch land if it does the trick: it's better to have the serializer owner in charge here.
I feel this patch to provide cleaner way for lazy line breaks but it may not do it's job when in EnsureVerticalSpace(), mFloat = -1 and noOfRows =0. If needed, I'll modify the patch. While closing the tags, as we should not just add line breaks but should use the lazy ones, we can use the approach in this patch because this way it's possible to call varying number of lazy line breaks.
Jfrancis, I tried modifying the patch in many possible way but I was always failing in one or the other test cases(probably because of the inappropriate calls to FlushLine()). I have uploaded a patch there in 75283 which essentially solves this bug as well some other related ones. I just tried to solve this by least changes. Should we mark it as Dupe of 75283?
Resolved by the same patch proposed for bug#75283. *** This bug has been marked as a duplicate of 75283 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Tanu, if you have a patch which fixes this bug as well as others, and which passes testing better than my patch here, then we should definitely use your patch! One reason I handed this off to you rather than seek reviews/approval was I that I knew you would be able to test it. I don't know enough about the serializer to test these patches correctly.
verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: