53452 - Mid-air collision: allow copy-paste of the comment from a textarea

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Description

[Jesse Ruderman]

I've had to view-source the mid-air collision page and then manually unescape 
my comments several times.  It would be much easier to recover from collisions 
if there was a textarea on the collision page contianing the new comment.

This assumes that people spend more time writing comments than tweaking 
summaries, or at least that it's easier to re-tweak a summary than it is to 
rewrite a comment.

Related: bug 31117, ignore collisions when the second person is just adding 
comments.  (I disagree with this bug because it would make bug discussion less 
continuous.)

Comment 1

[Jesse Ruderman]

Same with trying to cc a non-existent person.

Comment 2

[Jesse Ruderman]

And with trying to submit a new bug without a component.  

I think I've lost about a hundred lines of bug comments from bugzilla rejecting 
other changes and incorrectly assuming that my browser will let me see my 
comments again when I hit Back.  It gets annoying pretty quickly.

Comment 3

[Matthew Tuck [:CodeMachine]]

Yeah, AFAICS this is a browser bug, but we should try to help out where we can.

Comment 4

[Matthew Tuck [:CodeMachine]]

Perhaps we could bring up a new version of the fields on the query page with
midairs, and above each field we could show the original value and the other
user's value.

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

->New product Bugzilla.

Comment 6

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 7

[Daniel Wang]

Please do fix this bug soon, at least get it done before bug 46845 is
fixed. Currently when using b.m.o if any change is made to a bug by
somebody else or if you return to a bug page after making change to it,
any subsequent change or comment will cause Mid-air collision unless
you reload the page. If bug 46845 is fixed, then very likely QAs will
trash all form data modification by mistake when attempting to resubmit
a change.

Nominating as dogfood?

Comment 8

[Jason Pyeron]

Attachment: cut and paste solution

a readonly textarea of user's comments for the midair collision template.

Comment 9

[Gervase Markham [:gerv]]

Comment on attachment 125189 [details] [diff] [review]
cut and paste solution

> [% END %]
>+<p>
>+  Here are you comments which you have type so long on:<br>

Er... that's not English :-) How about: "Your additional comment was:"

>+  <blockquote>
>+    <textarea readonly="true" wrap="hard" name="comment" rows="10" cols="80">[% form.comment %]</textarea>
>+  </blockquote>
>+</p>

You probably don't want wrap="hard" on this particular textarea.

Gerv

Comment 10

[Jason Pyeron]

Attachment: cut and paste solution

I am leaving wrap="hard" because it is what was in the orig html.
Further I don't know how changing it would effect copy/paste in each browser.
you type in wrap="hard" then it is displayed in wrap="" which you copy then
paste in wrap="hard"?

seems bad to me.

fixed the english issue.

Comment 11

[Gervase Markham [:gerv]]

> I am leaving wrap="hard" because it is what was in the orig html.

The point is that the browser will have wrapped it when it submits it to the
server the first time; there is no need to wrap it again, and if there's some
sort of browser bug or quirk, it could even mangle things. And anyway, it's
superfluous because it should only mean something when the form is submitted,
which this one never is.

Lastly, did you test with Netscape 4? Does it allow <textarea> outside <form>?
(Or are you in a <form>?)

Gerv

Comment 12

[Jason Pyeron]

no IE 5.5

will xref the HTML spec 4.01

but much later tonight

also will drop the wrap="hard"

patch to follow

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 125236 [details] [diff] [review]
cut and paste solution

Removing review request since newer patch supposedly forthcoming.

I'm confused about the need for this patch, however.  Copying and pasting the
additional comment as it is currently displayed works fine for me in a recent
version of Mozilla Firebird.  Is this a browser-specific problem, and is this
because of the <blockquote>?  If so, seems like the better solution would be to
use some other way of setting apart the comment, perhaps <pre>, which show bug
uses.  A textarea will display only part of a comment longer than a few lines,
which requires extra effort on the part of the user to navigate for cutting and
pasting.

Comment 14

[Jason Pyeron]

Comment on attachment 125236 [details] [diff] [review]
cut and paste solution

Pathc is good as it is,

I have checked the html spec
http://www.w3.org/TR/html4/interact/forms.html#edef-TEXTAREA

it does not prohibit it outside a form

as to the wrap hard, it does make a differnce. At least on IE.

Comment 15

[Christian Reis]

Comment on attachment 125236 [details] [diff] [review]
cut and paste solution

There's no real reason to use a textarea here, as myk has suggested. A
blockquote alone should be fine.

I would also appreciate it if it the conflicting changes were visually distinct
-- my suggestion would be to use two columns, with "Their Changes:" and "Your
Changes:" heading.

Comment 16

[Jason Pyeron]

since we are going for a table look now??

a <td><pre>[%...%]</pre></td> would work too.


will mock it up later.

Comment 17

[Brodie]

Attachment: patch 2

Mozilla 1.7 doesn't allow the use of the back key to get the original comment.
According to Murphy's Law, almost every time I forget to copy the comment text
before submission I get a midair collision and lose my comment. I'm sick of
losing my text, so here are the changes as discussed. Satisfactory?

Comment 18

[Brodie]

Comment on attachment 154714 [details] [diff] [review]
patch 2

Not knowing which kiko was the last reviewer I'll ask Gerv instead.

Comment 19

[Christian Reis]

Comment on attachment 154714 [details] [diff] [review]
patch 2

I'm kiko.

This needs a filter HTML there -- we filter all data being output.

I don't actually like the way the UI is organized here, but if people are
willing to kill for this bug I could consider r+ing this (this page is already
scary enough though).

Comment 20

[Brodie]

Attachment: patch 3

With filter html.

I'm fine if someone wants to create a prettier UI for it, but I don't have the
knowledge of perl or bugzilla code for that. In the meantime I'd really like to
get this fix in - the bug has been around for years, the patch for a year.

Comment 21

[Christian Reis]

Comment on attachment 154728 [details] [diff] [review]
patch 3

Let's see what the approver thinks. The code is okay, the UI average.

Comment 22

[Dave Miller [:justdave]]

I *really* don't like this, but it's better than nothing, and it's a good
stopgap measure until the midair process gets the overhaul it's sorely in need of.

Comment 23

[Brodie]

Would someone check this in for me please.

Comment 24

[Vlad Dascalu]

Checking in template/en/default/bug/process/midair.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/midair.html.t
mpl,v  <--  midair.html.tmpl
new revision: 1.11; previous revision: 1.10
done