Opened 15 years ago
Closed 9 years ago
#11328 closed enhancement (duplicate)
Issue with double click on comment's text when quick edit is used
Reported by: |
|
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.
Pull Requests
- Loading…
Change History (30)
#3
@ Lead Developer
15 years ago
- Keywords reporter-feedback added
Can't reproduce on FF 3.5, Opera 10, Safari 4, Chrome 3, IE 6...
#4
follow-up:
↓ 5
@
15 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
@ Lead Developer
15 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.
#7
follow-up:
↓ 8
@
15 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
@ Lead Developer
15 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
@
15 years ago
- 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?
#11
@ Lead Developer
15 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.
#12
@ Lead Developer
15 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.
#13
@ Lead Developer
15 years ago
- Keywords dev-feedback removed
Second patch attached but I'm finding bugs in it, so ignore for now.
#14
@ Lead Developer
15 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
@ Lead Developer
15 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
@ Lead Developer
15 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
@
15 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.
#19
@
15 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:
↓ 21
@
15 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:
↓ 23
@ Lead Developer
15 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
@
15 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
@
15 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
@ Lead Developer
14 years ago
- Keywords needs-patch added; has-patch needs-testing removed
Cross referencing #15898. The attached patch is horrible. Needs work.
#27
@ Core Committer
9 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.
No patch. Moving this to future. Should be a simple patch.