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

Audacity Bugzilla



Bug 1443 - Summary: Odd behaviors of label text editor
Summary: Odd behaviors of label text editor
Status: RESOLVED FIXED
Product: Audacity
Classification: Unclassified
Component: Labels
2.1.3
Per OS All
: P4 Summary
Assigned To: Default Assignee for New Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-07-11 02:06 UTC by Paul L
Modified: 2018-08-20 11:51 UTC (History)
7 users (show)

See Also:
Steps To Reproduce:
In several ways, the label edit box does not behave like most text editors (such as this one for Bugzilla): Create a label track and make a label. 1) Select a range of text, then do left arrow or right. (Try this dragging right to select text, then again dragging left.) Selection should collapse to the appropriate end, but instead, it collapses where the text drag stopped. 2) Select some text, then shift-click elsewhere in the text box. The end of the selection nearest the pick should adjust. But instead, it is the end where drag was released that adjusts. 3) Select some text, then right-click in the text box. If you pick outside the selected text, then cut and copy are not available in the pop-up menu, and after dismissing the menu, the cursor is left where you right-clicked. 4) Drag with the right button. The highlight box appears only at mouse up, unlike with left dragging where it updates continuously. Why? 5) Select some text with left-drag. Then right-drag in another part of the box. Label is left in a strange state showing both highlighted text and an insertion cursor. 6) Select some text and copy. Click and drag in the label box, so a character is highlighted, but then release where the highlight shrinks to nothing. Then command+C again, then command + V. The second Command+C should not change the clipboard. In fact it empties it. 7) Drag text as in 6. Then hit Backspace or Delete. One character should be deleted, but instead, nothing happens until you repeat the key. 8) Click in the text; then click and drag elsewhere in the text -- the highlight is as expected, only between the click and the drag point. But: drag again, yet elsewhere in the text, and behavior is not as expected. The previous drag anchor is used, rather than resetting to the mouse down point.
Release Note:
First Git SHA:
Group: ---
Workaround:
Closed: 2018-08-20 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul L 2016-07-11 02:06:55 UTC

    
Comment 1 David Bailes 2016-07-11 08:53:40 UTC
Step to reproduce:
>1) Select a range of text, then do left arrow or right.  (Try this dragging >right to select text, then again dragging left.)
>
>Selection should collapse to the appropriate end, but instead, it collapses >where the text drag stopped.

On Windows, both the current observed behaviour and the behaviour you suggest can be found in various text boxes, so probably no need to fix.

>2) Select some text, then shift-click elsewhere in the text box.
>
>The end of the selection nearest the pick should adjust.  But instead, it is the >end where drag was released that adjusts.

The observed behaviour is the expected behaviour on Windows.

>5) and 6)

I've no idea what right dragging is meant to do.
Comment 2 Paul L 2016-07-11 10:19:16 UTC
(In reply to David Bailes from comment #1)

"Various text boxes" means something besides the Label track?
Comment 3 David Bailes 2016-07-11 13:02:08 UTC
(In reply to Paul L from comment #2)
> (In reply to David Bailes from comment #1)
> 
> "Various text boxes" means something besides the Label track?

Yes. For example in the address bar in File Explorer on Windows 10, left and right arrow position the cursor near where the text drag stopped. (one character before and after respectively.) But in the search box in the same program it behaves the other way.
Comment 4 Paul L 2016-07-11 13:10:52 UTC
(In reply to David Bailes from comment #3)

But maybe the inconsistency of Windows should be criticized then.

The behavior I propose makes more sense to me, and is analogous to what left and right arrow keys do when you have a non-point selection in the wave tracks.

Would you object to this change?  You sound not really committed either way, just arguing we might leave it be.

But I think label track code is full of a lot of other confused logic that needs to be reexamined and set straight some how.
Comment 6 David Bailes 2016-07-12 04:37:04 UTC
(In reply to Paul L from comment #5)
> Fixed here
> https://github.com/audacity/audacity/commit/
> cb3e5e6d4fe484132b7dae246e52614fedb758de

One of your changes is:
Shift-click adjusts the end of selection nearest the pick

As I stated in comment #1, the old behaviour is the standard behaviour on Windows. The new behaviour is not standard.

So why did you change it?

Please revert this part of your changes for Windows users. (Changed behaviour also appears to be non standard on Linux, no idea about Mac).
Comment 7 Paul L 2016-07-12 10:24:59 UTC
(In reply to David Bailes from comment #6)

To summarize:

If you shift click, the end of the highlighted box that is anchored could either be that farther from the pick point (as now), or the previously anchored end (as you would like).

I see either behavior as arguably a good one, and I see the former seems to be standard on the Mac where I develop.

I don't like making platform specific code where it is avoidable, but I can easily do that here to satisfy your objection.
Comment 8 David Bailes 2016-07-13 06:58:23 UTC
(In reply to Paul L from comment #4)
> (In reply to David Bailes from comment #3)
> 
> But maybe the inconsistency of Windows should be criticized then.
> 
> The behavior I propose makes more sense to me, and is analogous to what left
> and right arrow keys do when you have a non-point selection in the wave
> tracks.
> 
> Would you object to this change?  You sound not really committed either way,
> just arguing we might leave it be.

No objection at all to the change. It was just because of the regrettable inconsistency on Windows, I thought the priority for the change wasn't very high.

> 
> But I think label track code is full of a lot of other confused logic that
> needs to be reexamined and set straight some how.
Comment 9 David Bailes 2016-07-13 07:01:49 UTC
(In reply to Paul L from comment #7)
> (In reply to David Bailes from comment #6)
> 
> To summarize:
> 
> If you shift click, the end of the highlighted box that is anchored could
> either be that farther from the pick point (as now), or the previously
> anchored end (as you would like).
> 
> I see either behavior as arguably a good one, and I see the former seems to
> be standard on the Mac where I develop.
> 
> I don't like making platform specific code where it is avoidable, but I can
> easily do that here to satisfy your objection.

Thanks for reverting to the original behaviour on Windows. I agree that a case could be made for either behaviour, but in cases like this, I think it's less confusing for users to use the standard behaviour on their OS.
Comment 10 David Bailes 2016-07-13 07:07:18 UTC
Tested on Windows 10, after this commit:
https://github.com/audacity/audacity/commit/26676652d7f54de518ed348a3c672afcd71b7c3e


All 8 steps to reproduce now fit in with standard Windows behaviour.

In doing the tests, I noticed yet more strange stuff:

1. Clicking in a label can select other tracks.

2. With a label as focus, but no text selected, pressing ctrl+c selects the entire project

3. With a label as focus, but no text selected, pressing ctrl+x deletes all audio and labels.
Comment 11 David Bailes 2016-07-13 08:55:09 UTC
(In reply to David Bailes from comment #10)
> Tested on Windows 10, after this commit:
> https://github.com/audacity/audacity/commit/
> 26676652d7f54de518ed348a3c672afcd71b7c3e
> 
> 
> All 8 steps to reproduce now fit in with standard Windows behaviour.
> 
> In doing the tests, I noticed yet more strange stuff:
> 
> 1. Clicking in a label can select other tracks.
> 
> 2. With a label as focus, but no text selected, pressing ctrl+c selects the
> entire project
> 
> 3. With a label as focus, but no text selected, pressing ctrl+x deletes all
> audio and labels.

Clarification of points 2 and 3 above. These undesirable side affects only happen when the option "select all audio in project, if none selected" is on.
Comment 12 Peter Sampson 2016-07-20 09:51:59 UTC
I agree with David;s findings in comment #10 and comment #11

on both Mac and W10 with rcf2625a

So mostly fixed - but the issues in comment #11 still need fixing
Comment 13 James Crook 2017-09-28 11:25:59 UTC
REOPENED. Issue in comment 11 still needs fixing.
Comment 14 Peter Sampson 2018-01-25 12:32:12 UTC
(In reply to David Bailes from comment #11)
>> 1. Clicking in a label can select other tracks.

It only does that now if you have the preference for "Select all if none selected" - and it's supposed to do that.

And note that that preference (after much tortuous debate) is "off" by default - so with default settings you won't see this. behavior
Comment 15 Peter Sampson 2018-01-25 12:33:25 UTC
(In reply to Peter Sampson from comment #14)

OOPS my previous Comment #13 refers to this

> 2. With a label as focus, but no text selected, pressing ctrl+c selects the
> entire project
Comment 16 Peter Sampson 2018-01-25 12:37:27 UTC
(In reply to Peter Sampson from comment #15)
Abd the same applies to David's 3rd point

> 3. With a label as focus, but no text selected, pressing ctrl+x deletes all
> audio and labels.

And David himself points out in Comment #11 that 2&3 are not "issues" but depend the the "Select all ..." setting.

So those are not a bug - but a design feature - a direct consequence of retaining the "Select all ..." that Gale fought so hard for.
Comment 17 Peter Sampson 2018-01-25 12:41:25 UTC
In comment #10 David wrote:

>1. Clicking in a label can select other tracks.

More accurately clicking in a range label will (not can) select in the asio tracks over the time range defined bu that range label.

Audacity is supposed to do that - it is intended behavior, has been for a long while.


Accordingly I see no residual issues and I am going to mark this bug as resolverd
Comment 18 David Bailes 2018-01-26 04:22:11 UTC
(In reply to Peter Sampson from comment #17)
> In comment #10 David wrote:
> 
> >1. Clicking in a label can select other tracks.
> 
> More accurately clicking in a range label will (not can) select in the asio
> tracks over the time range defined bu that range label.
> 
> Audacity is supposed to do that - it is intended behavior, has been for a
> long while.

Testing with Windows 10:
With the auto-select option off.
If you click in a point or region label, this selects all the tracks. I think that track selection should not be changed by this action.

Quote from the manual:
When you click inside a label to select it, the label background color changes to white, indicating that the label text is open for editing, and the cursor point or region of audio the label corresponds to is restored. The region will be visible in all audio tracks that are selected and the cursor will be visible in all audio tracks that have the yellow focus border. 


> 
> 
> Accordingly I see no residual issues and I am going to mark this bug as
> resolverd
Comment 19 David Bailes 2018-01-26 05:32:46 UTC
(In reply to Peter Sampson from comment #16)
> (In reply to Peter Sampson from comment #15)
> Abd the same applies to David's 3rd point
> 
> > 3. With a label as focus, but no text selected, pressing ctrl+x deletes all
> > audio and labels.
> 
> And David himself points out in Comment #11 that 2&3 are not "issues" but
> depend the the "Select all ..." setting.
> 
> So those are not a bug - but a design feature - a direct consequence of
> retaining the "Select all ..." that Gale fought so hard for.

I didn't say that they are not issues.
My take, is that when a label is open for editing and is the focus, a user would expect that if they used any of the standard keystrokes for editing text, then these would only affect the text of the label. For example, using left and right arrow moves the text cursor, it doesn't move the project's cursor.
Comment 20 Peter Sampson 2018-01-26 07:50:58 UTC
(In reply to David Bailes from comment #18)
David wrote:

>Testing with Windows 10:
>With the auto-select option off.
>If you click in a point or region label, this selects all the tracks. 
>I think that track selection should not be changed by this action.
>
>Quote from the manual:
>When you click inside a label to select it, the label background color changes 
>to white, indicating that the label text is open for editing, and the cursor
>point or region of audio the label corresponds to is restored. The region will 
>be visible in all audio tracks that are selected and the cursor will be visible
>in all audio tracks that have the yellow focus border. 


Indeed the manual explicitly tells you that the selection *will* be changed by clicking in the label.

If you have audio tracks focused (yellow bordered) before clicking in the label track and then click in a range label in the label track the selection will extend to just those (previously focused) audio tracks - the focus and yellow border of course shits to the label track once you click in the label.  (the manual is not entirely accurate in regard to this, I will fix that).

If no audio tracks is focused and you click in a range label then all of the audio defined by that range label is selected.

This is the behavior that Gale explained to me a long time ago.


The behaviors appear to be independent of the setting for "select all if none ...",
Comment 21 Peter Sampson 2018-01-26 08:08:17 UTC
(In reply to Peter Sampson from comment #20)
And see also this page in the Manual:
https://alphamanual.audacityteam.org/man/Audacity_Selection#Label_Tracks

Where using the shortcuts Alt_right & Alt+left enable you to navigate between labels without losing your audio track focus.
Comment 22 Peter Sampson 2018-01-26 08:11:05 UTC
(In reply to David Bailes from comment #19)
David wrote:
>My take, is that when a label is open for editing and is the focus, a user 
>would expect that if they used any of the standard keystrokes for editing 
>text, then these would only affect the text of the label. For example, using 
>left and right arrow moves the text cursor, it doesn't move the project's cursor.

And that is indeed what happens (I just tested on W10 with latest alpha)
Comment 23 David Bailes 2018-01-26 08:14:09 UTC
(In reply to Peter Sampson from comment #20)
> (In reply to David Bailes from comment #18)
> David wrote:
> 
> >Testing with Windows 10:
> >With the auto-select option off.
> >If you click in a point or region label, this selects all the tracks. 
> >I think that track selection should not be changed by this action.
> >
> >Quote from the manual:
> >When you click inside a label to select it, the label background color changes 
> >to white, indicating that the label text is open for editing, and the cursor
> >point or region of audio the label corresponds to is restored. The region will 
> >be visible in all audio tracks that are selected and the cursor will be visible
> >in all audio tracks that have the yellow focus border. 
> 
> 
> Indeed the manual explicitly tells you that the selection *will* be changed
> by clicking in the label.

The phrase "that are selected" is ambiguous. eg, it could mean "that are selected before clicking". That's how I read it.

> 
> If you have audio tracks focused (yellow bordered) before clicking in the
> label track and then click in a range label in the label track the selection
> will extend to just those (previously focused) audio tracks - the focus and
> yellow border of course shits to the label track once you click in the
> label.  (the manual is not entirely accurate in regard to this, I will fix
> that).
> 
> If no audio tracks is focused and you click in a range label then all of the
> audio defined by that range label is selected.
> 
> This is the behavior that Gale explained to me a long time ago.
> 
> 
> The behaviors appear to be independent of the setting for "select all if
> none ...",

But why is it independent of that setting?
And what about point labels? With no audio tracks selected I click in the label and audio tracks are selected. Why?
Comment 24 Peter Sampson 2018-01-26 08:21:33 UTC
(In reply to David Bailes from comment #23)
>But why is it independent of that setting?

Because I think that that has always been intended behavior.


>And what about point labels? With no audio tracks selected I click 
>in the label and audio tracks are selected. Why?

I don't see that (and the Manual doesn't say that).  What I see is the cursor showing in all tracks, not a selection.
Comment 25 David Bailes 2018-01-26 10:26:08 UTC
(In reply to Peter Sampson from comment #24)
> (In reply to David Bailes from comment #23)
> >But why is it independent of that setting?
> 
> Because I think that that has always been intended behavior.
> 
> 
> >And what about point labels? With no audio tracks selected I click 
> >in the label and audio tracks are selected. Why?
> 
> I don't see that (and the Manual doesn't say that).  What I see is the
> cursor showing in all tracks, not a selection.

The tracks become selected (I agree that there is no audio selected).

Given that you don't think there are any bugs here, and even if you did, the chance of anyone fixing them in the near future would be small, this probably isn't worth discussing any further.