Audacity Bug Summary
••• Introduction •••
••• Keywords •••
    Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla



Bug 224 - Label text boxes: Drag and select doesn't select whole words properly
Label text boxes: Drag and select doesn't select whole words properly
Status: RESOLVED FIXED
Product: Audacity
Classification: Unclassified
Component: Labels
1.3.14 alpha
Mac macOS
: P4 Repeatable
Assigned To: Default Assignee for New Bugs
: labels
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-12 06:24 UTC by Gale Andrews
Modified: 2018-08-20 11:45 UTC (History)
5 users (show)

See Also:
Steps To Reproduce:
1 Create a label with text, e.g. "This is a longish label". 2 Click out of the label to close it for editing 3 Now click in the label between the "g" and "i" of "longish". Say you intention was to delete the word "longish". So, click to the left of the "l" in "longish" and start dragging, thinking this will allow you to select the word - as soon as you start to drag, "long" is selected, and as you drag right the selection gets smaller. As you continue to drag, the selection "flips" and eventually "ish" is selected.
Release Note:
First Git SHA:
Group: ---
Workaround:
Closed: 2018-08-20 00:00:00
petersampsonaudacity: Test‑OK‑Mac+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gale Andrews 2010-09-12 06:24:31 UTC
reported by Bill Wharrie. Doesn't effect text boxes in e.g. Metadata Editor. Not apparent on Windows or Ubuntu. Is a nuisance given there is no right-click > Select All either.
Comment 1 Paul L 2016-06-21 19:04:51 UTC
I doubt this is really OSX specific.

Click and shift-click in labels certainly do not behave analogously to most text editors, and that is all about Audacity's own logic.
Comment 2 Paul L 2016-07-11 13:02:02 UTC
This was not quite intentionally fixed at
https://github.com/audacity/audacity/commit/06fd4818156f3c689512c3c1a2cfda323575fa08

I say not quite intentionally, because I was doing some cleanup of confusing stuff in LabelTrack that I thought would be only preliminary to this bug and others.

I wanted to understand why this fixed this bug before proceeding.  I think I do now.

A short answer is that the code was relying too much on doing certain delayed changes of label track state in the repaint procedure (a bad idea for code clarity), and assumed that a paint event would happen between the left click and the first drag event.

But in fact the click and at least one drag event are dispatched first, and only then came the painting.

By not delaying certain changes until the painting, but doing them at once in click and drag -- I fixed this bug without fully understanding why.
Comment 3 Paul L 2016-07-11 13:26:55 UTC
This bug is fixed, construing the steps to reproduce very exactly.

However.  Let step be a click-drag-release rather than just a click.

Then, the behavior is still strange.

But rather than reopen this bug, please let the new bug 1443 track this and other anomalies.
Comment 4 Peter Sampson 2017-08-03 13:00:43 UTC
Following the steps to reproduce - testing on macOS Sierra 10.12.6 with 53c3adf 03Aug17 3e39771

"longish" is correctly selected in full

Also sanity checked on lated Wdows nightly wher it is ok too