Double clicking on empty area executes last item

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/3722
Reporter	egmont (@egmontkob)

Forking from #3715:

Go to a directory which has fewer entries than the height of the panel widget.

Double click on the empty area at the bottom.

Actual behavior: The last item is executed (if executable) or entered (if directory or archive).

Expected behavior: Nothing (other than the last item getting selected on the first click).

Unexpected execution of a binary can potentially be quite dangerous, and it's sure unexpected to execute it if you double clicked somewhere else.

(Similary I'm wondering whether the leftmost and rightmost columns (the borders which aren't highlighted) should be excluded as well.)

Note

Original attachments:

• mc-3722-prevent-execute-last-element-on-empty-area.patch (raw) by and on Dec 6, 2016 at 23:12 UTC
• mc-3722-prevent-execute-last-element-on-empty-area-v2.patch (raw) by and on Dec 7, 2016 at 12:47 UTC

[mc-butler]

Changed by and on Dec 6, 2016 at 23:06 UTC (comment 1)

Yes makes sense to prevent execute of last element BY ACCIDENT of an inexperienced user.

[mc-butler]

Changed by and on Dec 6, 2016 at 23:12 UTC

• Attachment mc-3722-prevent-execute-last-element-on-empty-area.patch (raw) added

[mc-butler]

Changed by mooffie (@mooffie) on Dec 7, 2016 at 0:45 UTC (comment 2)

The patch--

• probably fails for "brief" listing.
• doesn't address egmont's note about excluding left/right borders.
• could have been nicer if it factored out MSG_MOUSE_DRAG's code for figuring out a file index from coordinates.

[mc-butler]

Changed by and on Dec 7, 2016 at 12:47 UTC (comment 3)

Thanks mooffie, can you test next patch?

[mc-butler]

Changed by and on Dec 7, 2016 at 12:47 UTC

• Attachment mc-3722-prevent-execute-last-element-on-empty-area-v2.patch (raw) added

[mc-butler]

Changed by mooffie (@mooffie) on Dec 7, 2016 at 22:55 UTC (comment 4)

Have you considered idea #3 in my previous comment?

Some day we'll support drag & drop and then what? Will we duplicate these calculations for the 3rd time?

While MSG_MOUSE_DRAG also needs to know when the mouse cursor it outside the files, perhaps we can still share the code in a way that isn't inelegant.

[mc-butler]

Changed by and on Dec 8, 2016 at 11:40 UTC (comment 5)

Honestly I was focused on MSG_MOUSE_CLICK bug fixing because I can reproduce egmonts findings about "Double clicking".

I don't want touch MSG_MOUSE_DRAG (and maybe break it) by fixing "double clicking" here.

[mc-butler]

Changed by andrew_b (@aborodin) on Jan 7, 2020 at 10:40 UTC (comment 6)

Branch: 3722_double_click_on_empty
[bf9060d22d73059b8c940c7bfb79d4a7503147b9]

[mc-butler]

Changed by andrew_b (@aborodin) on Jan 7, 2020 at 10:41 UTC (comment 7)

• Owner set to andrew_b
• Branch state changed from no branch to on hold
• Status changed from new to accepted

[mc-butler]

Changed by andrew_b (@aborodin) on Jan 19, 2020 at 16:58 UTC (comment 8)

• Milestone changed from Future Releases to 4.8.25
• Branch state changed from on hold to on review

[mc-butler]

Changed by andrew_b (@aborodin) on Feb 2, 2020 at 16:20 UTC (comment 9)

• Branch state changed from on review to approved
• Votes set to andrew_b

[mc-butler]

Changed by andrew_b (@aborodin) on Feb 2, 2020 at 16:21 UTC (comment 10)

• Votes changed from andrew_b to committed-master
• Status changed from accepted to testing
• Resolution set to fixed
• Branch state changed from approved to merged

Merged to master: [647c431].

[mc-butler]

Changed by andrew_b (@aborodin) on Feb 2, 2020 at 16:23 UTC (comment 11)

• Status changed from testing to closed