Make WordPress Core

Opened 14 years ago

Closed 8 years ago

#11328 closed enhancement (duplicate)

Issue with double click on comment's text when quick edit is used

Reported by: dimadin's profile dimadin Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.9
Component: Quick/Bulk Edit Keywords:
Focuses: administration Cc:

Description

When you edit comment via quick edit or when you write a reply on "Edit Comments" page and double click on text of other comment, used quick editing is turned off and quick editing is turned on other comment, with all text which you wrote lost.

I noticed this when I wrote a reply on one comment and when I wanted to copy a word from that comment by double clicking on it, my whole reply was lost.

So enabling of quick edit via double click on comment's text should be disabled when quick edit is used.

Attachments (2)

11328.diff (403 bytes) - added by nacin 14 years ago.
11328.2.diff (1.0 KB) - added by nacin 14 years ago.

Download all attachments as: .zip

Change History (30)

#1 @dimadin
14 years ago

  • Cc dimadin added

#2 @markjaquith
14 years ago

  • Milestone changed from 2.9 to Future Release

No patch. Moving this to future. Should be a simple patch.

#3 @nacin
14 years ago

  • Keywords reporter-feedback added

Can't reproduce on FF 3.5, Opera 10, Safari 4, Chrome 3, IE 6...

#4 follow-up: @richards1052
14 years ago

This is also a deeply annoying problem for me as well & I've replicated it on Firefox, Chrome & IE. I use Vista.

To replicate: go to comment page, hit Reply button for any published comment & open comment edit box, then highlight any word or phrase in original published comment, double-click. The edit box for the published comment will open & wipe out the Reply edit box.

#5 in reply to: ↑ 4 @nacin
14 years ago

Replying to richards1052:

This is also a deeply annoying problem for me as well & I've replicated it on Firefox, Chrome & IE. I use Vista.

What versions of IE and Firefox?

Let me send a note to someone I know can test this on Vista. I couldn't on XP, but I'll try again.

#6 @Denis-de-Bernardy
14 years ago

  • Cc Denis-de-Bernardy added

#7 follow-up: @richards1052
14 years ago

FF 3.5.6
IE 8
Chrome 3.0

I just wanted to pt out that I don't think it's a question of replicating the behavior since this isn't a bug. The double click is a shortcut built into the comment edit coding. This is specifically mentioned in the official WP blog as an intended feature. So the behavior works precisely as the coders intended for it to work.

The problem is that they didn't take into acct. that opening the comment edit box would wipe out an already opened comment edit box. So what I think should be done is that the code should check whether an edit box is already open & not open a new box if it is. Or else there should be some configuration options allowing you to turn off the double click feature if you want to so it never works.

My 2 cents anyway...

#8 in reply to: ↑ 7 @nacin
14 years ago

Replying to richards1052:
That's all precisely why I classified #11677 as a bug, because this is not intended behavior. The feature is double-click to open the inline editor.

The code should be doing more or less what you're describing -- as long as one is open, not closing it unless "Cancel" or "Save" is clicked.

This is a question of reproducing it because no developer has commented her saying that they are able to (and why). I believe that it is happening to you, we just need to narrow it down to the circumstances and steps for failure first.

I have tried turning on comment moderation shortcuts and still nothing. Please disable all plugins or create a new installation of 2.9 and let us know if you can still reproduce it.

#9 @digitaltoast
14 years ago

  • Cc digitaltoast added
  • Priority changed from low to normal

Nacin; I don't see how this can't be reproduced your end.

Brand new install, no plugins, make a post, add a comment, go to wp-admin/edit-comments.php,
click "reply", start typing a reply, then double click in the original comment - bang, and the comment is gone.

Tested on IE8, Chrome 4 and Firefox 3.6 - that covers the bases of MS, Webkit and Gecko.

I can make a screencam video and post it if anyone needs that?

#10 @westi
14 years ago

nacin: I have reproduced this issue on trunk with FF 3.5 on OS X

#11 @nacin
14 years ago

  • Keywords needs-patch added; reporter-feedback removed

Okay, misread the steps to reproduce and I wasn't trying hard enough, apparently. :)

Can reproduce now.

@nacin
14 years ago

#12 @nacin
14 years ago

  • Keywords has-patch needs-testing dev-feedback added; needs-patch removed

Again, sorry about the confusion.

Patch attached will disable double-clicking of any comment whenever any reply or edit box is open.

Feedback required: I'm thinking it should also check if the comment is unchanged (for an edit) or reply form is empty (for a reply) before deciding whether to prevent that reply/edit box from closing and another from opening. This also doesn't prevent a comment's "Reply" link from closing an opened box.

@nacin
14 years ago

#13 @nacin
14 years ago

  • Keywords dev-feedback removed

Second patch attached but I'm finding bugs in it, so ignore for now.

#14 @nacin
14 years ago

Never mind, patch looks good. Needs testing and I guess some cleanup.

Before a double-click is processed, it first checks if a reply/edit form is open. If a reply form is open, it only allows the new edit form to open if the reply is empty. If an edit form is open, it only allows the new edit form to open if the existing edit and its author meta is unmodified.

A "Reply" link on a comment still closes an opened box, and I'm thinking it should stay that way.

#15 @azaozz
14 years ago

  • Type changed from defect (bug) to enhancement

Yes, patch looks good, needs a little cleanup.

However thinking about the UX: the "doubleclick to quick edit" used to be available for posts too at first but was removed later. Perhaps we should remove it for comments too to avoid confusion.

With this patch it becomes somehow inconsistent: sometimes works, sometimes doesn't. Also it used to trigger for the whole <tr> but seems that was unexpected for many people so now it only triggers for '.column-comment > p'.

Changing ticket type to enhancement since this is expected behaviour.

#16 @nacin
14 years ago

Agreed this is an enhancement... Removing the double-click event makes sense if the feature is seldom used. If we are to leave it, then the patch makes sense. I agree that the new behavior appears inconsistent at first, but I think a user would understand it (and get frustrated much less than the current behavior).

Perhaps Jane can look into all of the UX here?

#17 @richards1052
14 years ago

I'm glad we're all on the same pg. now & thanks for the patch. It will help immensely. My anecdotal sense is that this double click feature is prob. not used very often.

But I'm cool if people decide to keep it as long as there is a check in the coding that prevents opening a new edit box if one is already open.

#18 @digitaltoast
14 years ago

Working great here too - thanks

#19 @justincwatt
14 years ago

Wish this could have made it into 3.0, as it just bit me today. When you think about it, this is really a significant data loss bug (not an enhancement). "Doubleclick to Quick Edit comment" (which I never knew existed) should be suppressed if you're currently replying to or editing another comment.

Imagine someone in the middle of a multi-paragraph response losing it all by doubleclicking on a word in another comment. I suppose this could be considered a bigger issue, as accidentally clicking on any another comments' reply/quick edit button would also result in data loss.

#20 follow-up: @digitaltoast
14 years ago

  • Severity changed from normal to major
  • Version changed from 2.9 to 3.0.1

This just happened to me, too - this is a serious bug that needs squashing urgently. It's been SEVEN MONTHS now - I'll up the severity.

#21 in reply to: ↑ 20 ; follow-up: @westi
14 years ago

  • Keywords ux-feedback added
  • Version changed from 3.0.1 to 2.9

Replying to digitaltoast:

This just happened to me, too - this is a serious bug that needs squashing urgently. It's been SEVEN MONTHS now - I'll up the severity.

Firstly, please don't change the reported in version to a newer version - you are hiding the age of the ticket then

Secondly, there is not yet a suitable solution to this issue available - if you have the time and the skills we would welcome an improved patch.

#22 @richards1052
14 years ago

Can you be more specific about why the current patch isn't "suitable?" I installed the patch & it works perfectly. Others have installed it as well saying the same. If there's something the patch doesn't do that you think it should could you communicate that the person who wrote it so they can attempt to either rewrite it or answer your concerns.

If the patch hasn't been included in any upgrade because someone feels the patch isn't suitable but hasn't communicated what isn't suitable about it, then I think there's a communication gap here.

The solution is suitable as far as I'm concerned. This bug is a real disaster for someone who writes many comments in their blog as I do & invariably wipes out hours worth of comments over time as I've done due to this issue.

#23 in reply to: ↑ 21 @digitaltoast
14 years ago

Replying to westi:

Replying to digitaltoast:

This just happened to me, too - this is a serious bug that needs squashing urgently. It's been SEVEN MONTHS now - I'll up the severity.

Firstly, please don't change the reported in version to a newer version - you are hiding the age of the ticket then

Sorry, I did that because it still exists in the current version. I would suspect more people are on 3.x than 2.x (possibly). Didn't know that it hid the date.

Secondly, there is not yet a suitable solution to this issue available - if you have the time and the skills we would welcome an improved patch.

I have to agree with Richard, it works absolutely fine for me, doesn't appear to affect anything else, squashes the bug nicely. In fact, a quick google around reveals quite a few others frustrated by losing long replies like this.

As Richard says, it works, it doesn't appear to break anything... why is such an easy fix "not suitable"?

#24 @nacin
13 years ago

  • Keywords needs-patch added; has-patch needs-testing removed

Cross referencing #15898. The attached patch is horrible. Needs work.

#25 @chriscct7
9 years ago

  • Focuses administration added
  • Keywords dev-feedback added

#26 @chriscct7
8 years ago

  • Severity changed from major to normal

#27 @afercia
8 years ago

  • Keywords close added; ux-feedback needs-patch dev-feedback removed

As far as I can tell, there's a JavaScript confirm dialog now that prevents the main issue (data loss). See in the screenshot below. When replying or editing a comment and double clicking on the text of another comment (notice the word "use" is selected) a JS confirm appears.

While I'd be in favor of removing the "double click to edit" feature, I'd propose to close this ticket, unless I'm missing something.

https://cldup.com/O_YE56WOee.png

#28 @SergeyBiryukov
8 years ago

  • Keywords close removed
  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #21845.

Note: See TracTickets for help on using tickets.