Bug 452 – Windows: Speed typing in a label shifts the screen

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 452 - Windows: Speed typing in a label shifts the screen


Summary:	Windows: Speed typing in a label shifts the screen

Status:	CLOSED NOT-A-BUG

Product:	Audacity
Classification:	Unclassified
Component:	User Interface
Version:	2.0.1
Hardware:	PC Windows (all)

Importance:	P4 Repeatable
Assigned To:	Vaughan Johnson

URL:	http://forum.audacityteam.org/viewtop...
Keywords:	labels

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2011-09-26 13:07 UTC by Gale Andrews
Modified:	2018-08-20 11:45 UTC (History)
CC List:	4 users (show)

See Also:
Steps To Reproduce:	See description for occasional half-screen shifts, which may or may not have the same cause. These steps are for a repeatable rightwards shift which removes sight of the label. If we can stop the repeatable "losing the label" we can demote the remainder if unfixed. 1 Import a WAV file of music or speech (or generate a chirp). Three minutes is sufficient for me but to be safe, make it at least thirty minutes. 2 Zoom in several steps and drag the horizontal scrollbar to somewhere along the tone. 3 To ensure fastest possible typing, configure prefs to use NUMPAD ADD for "Add Label at Selection". 4 Select about one-third of the visible waveform, then use NUMPAD ADD followed by typing with NUMPAD keys as fast as possible.
Release Note:	GROUP:Label Tracks * (Windows) '''Adding labels then typing very fast may cause a screen shift.''' If you use a single-key shortcut to add the label and NUMPAD keys to type, or a script like AutoHotKey, you may repeatedly lose sight of the label and have to scroll back to see it. '''Workaround:''' Type more slowly. Select in the label track then type to create the label, instead of using a shortcut to create the label.
First Git SHA:
Group:	LabelTrack
Workaround:
Closed:	2018-08-20 00:00:00

Flags:	gale: Regression+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Gale Andrews 2011-09-26 13:07:45 UTC

Split from http://bugzilla.audacityteam.org/show_bug.cgi?id=40#c3

I can reproduce the screen shift issue most (but not all) of the time in 1.3.14 thus on Win 7 x64 and XP (confirmed by other Windows users too):

1 New project
2 Import 3 minute stereo wav
3 Tracks > Add New > Label track
4 Zoom in so that you have about 4 seconds of audio in the scroll and drag
horizontal scrollbar so audio starts at about 20 seconds
5 Click at about 21 seconds then click in Background so that tracks are
deselected
6 Save and exit (exit seems more likely to reproduce )
7 Reopen saved project and down arrow to put focus in the label track
8 Speed and attack may be crucial here - hold a finger of right hand over "N"
and a finger of left hand over "S". Now hit first "N" then "S" as hard and fast
as you can. With luck, the label will be typed at the correct place but the
screen will shift rightwards. "N" then "W" also reproduces. "G" then "H" does not.

With some degree of reliability, bug 40 (typing "j" and "k" in a label activates the shortcut) can now be made to happen. Do *not* undo the label edit but click in the label track to left of the just created label, and type "j" or "k" (lower case) on its own. This will fairly likely not type in the label but move to the start or end of the track.

The screenshift is not a regression and occurs readily in 1.3.12 where it is
apparently related to autosave. Launch 1.3.12 and do steps 1 - 8 above. Step 8
will autosave. Further attempts to screenshift by speedtyping "N" then "S" will
always work if you wait for the autosave interval to elapse before trying
again. If you try before the autosave interval has elapsed, the bug never
occurs.

However if you build HEAD with James' hack to disable autosave, then do steps
1 - 8, the shift still occurs, so the indications are contradictory.

Comment 1 Gale Andrews 2012-05-04 17:01:08 UTC

More variants of this issue have been reported, so broadened the bug title to "Speed typing in a label shifts the screen." 

As well as the rightwards half-screen shift, you can get a half-screen leftwards shift if the label is on the right of the screen. These symptoms do not result in you losing sight of the label. The shift is more likely to appear the faster you type, the longer the track and the slower machine you have. The shift occurs even if you select in the label and type without using a shortcut to create the label. 

A more severe and repeatable rightwards SHIFT occurs if you use a single-key shortcut to create the label quickly AND use NUMPAD keys to type the label rapidly. I cannot make this reliably happen if typing with other keys, only sometimes (it happens more often on slower machines and longer tracks). This shift means that you can no longer see the label you were typing into. It occurs repeatably in 2.0.0 even on fairly fast machines. It does not occur in 1.2.6 even on slow machines.

Comment 2 Vaughan Johnson 2012-06-16 23:05:18 UTC

(In reply to comment #1)

Cannot replicate this per current "Steps to Reproduce", nor steps in initial report (comment 0), so cannot fix it.

Even if I could, it is a P4, imo. As RM, on 2012-06-16, I have demoted this. 

It's totally an edge case, imo. Infinitesimally few users have this problem, right?

Comment 3 Gale Andrews 2012-06-17 15:57:42 UTC

(In reply to comment #2)
REOPENED to see if we may not have explored this sufficiently, left at P4 at the moment.

Thanks for trying Vaughan, but whatever the rating, I can't accept resolving a bug on the grounds you currently can't reproduce it (even though that means you can't fix it). "Steps to repro" are entirely reproducible for me (tried again now, on Win 7 dual core 2.4 GHz 6 GB RAM). Also I sometimes get the issue described in comment 0 when typing quite slowly (as do a number of people on the Forum).

Is it possible you have too fast a machine? Did you try on a lower powered machine? Did you try in Unicode Release instead of Debug?

The user with the speed typing issue has "hundreds of labels". I don't find I need more than a single label and three minutes of audio to reproduce the issue, but perhaps on blazing fast machines you do. Also let's investigate the type of keyboard being used, which may have varying latencies. I have a USB keyboard.

Here are some of the reporter's comments that led me to the "steps to reproduce." Clearly this issue detracts hugely from his ability to use Audacity productively.

"I'm using Audacity version 2.0.0 on Windows XP.
Load a large waveform. By large I mean at least an hour long audio file.
Click inside the wave form area. Mark an area of the waveform by clicking
and dragging the mouse. Quickly Hit the keyboard short cut key that
permits the addition of a label, and quickly begin typing a label (I don't
know if it matters but my labels are always numbers so perhaps it's
necessary to type numbers for this bug)
The problem seems to worsen as I add more labels (I eventually end up with
between 500 and 600 labels)
This causes the waveform to scroll if I've started typing label numbers
too quickly. This is such an annoying bug for me as it happens all the
time. It's like trying to write a letter and someone keeps pulling the
paper away from you."

I have a project from the user (528 MB) with 68 minutes of audio and 590 labels that also reproduces the "steps to repro". If you agree to try that, I'll upload it to my server.

Comment 4 Vaughan Johnson 2012-06-19 02:53:01 UTC

(In reply to comment #3)

> REOPENED to see if we may not have explored this sufficiently, left at P4 at
> the moment.
> 
> Thanks for trying Vaughan, but whatever the rating, I can't accept resolving a
> bug on the grounds you currently can't reproduce it (even though that means >you
> can't fix it). 

Okay. But I did try the tests you question later in your message, per the Bugzilla entry. I still think it's P4. Thanks for reverting it to that status.


>"Steps to repro" are entirely reproducible for me (tried again
> now, on Win 7 dual core 2.4 GHz 6 GB RAM). Also I sometimes get the issue
> described in comment 0 when typing quite slowly (as do a number of people on
> the Forum). 
> 
> Is it possible you have too fast a machine? 

I tested with a 30 minute track, as suggested for fast machine. Yes, a fast machine, but only Win 7 sp1 dual core 1.6GHz, 4G RAM, so not as fast as yours. Bug did not happen for me, with repeated testing.


>Did you try on a lower powered
> machine? 

Thanks. "Low-powered" should be in the bug report if that's necessary.


>Did you try in Unicode Release instead of Debug?

No. But Debug mode runs slower, so more likely to show "speed typing" problems. Right? Does it show this problem in Debug mode for you?


> 
> The user with the speed typing issue has "hundreds of labels". 

I'd expect very few users will ever have that many labels, *and* do speed typing. Thanks for demoting back to P4. No longer on agenda for 2.0.1.



>I don't find I
> need more than a single label and three minutes of audio to reproduce the
> issue, but perhaps on blazing fast machines you do. 

So is 30 minutes too little? It did not happen for me. 

Looks very edge case. 


>Also let's investigate the
> type of keyboard being used, which may have varying latencies. I have a USB
> keyboard. 

Fine. I tested on a laptop. But if we're down to hardware issues, again, I think this is edge case.


> 
> Here are some of the reporter's comments that led me to the "steps to
> reproduce." Clearly this issue detracts hugely from his ability to use Audacity
> productively. 

One reporter, out of tens of millions of users? We demote it to P4 as you agreed.

Comment 5 Vaughan Johnson 2012-06-19 22:45:33 UTC

(In reply to comment #4)

>>Did you try on a lower powered
>> machine? 

>Thanks. "Low-powered" should be in the bug report if that's necessary.

And now it is. :-)

I tried it on Win XPsp3, old laptop with 1.7GHz processor, 2GB ram, in 
debug mode with several other programs running. No NUMPAD_ADD on it, so I used F9. So now confirmed, but this machine is slow on everything and does other weird things with updated apps, and was far more stressed than I know it can handle. I still think it's a P4.

Comment 6 Gale Andrews 2012-06-20 06:09:13 UTC

(In reply to comment #5)
Thanks for more testing. I will do more testing on different machines (after 2.0.1). But if I get instant repeatability on a faster machine than one where you couldn't repeat it, possibly something more than just machine speed is at play? 

I can repeat the problem just the same in Debug in that Win 7 computer. An alternative theory might state that if Debug is much slower capturing the keystrokes, it could mask the problem (as if person was typing slower).     

It stops at P4 unless I can reproduce on many more machines ; obviously P2 was assuming it was easily reproducible. I have no idea, but maybe fixing this could fix the other (not speed-typing) shifts, too?

Comment 7 Vaughan Johnson 2012-06-20 23:32:11 UTC

(In reply to comment #6)

I tested again on the faster Win machine, latest revision, with release build running alone, and debug build in debug mode, 55 minute track, and now the results are for both, that NUMPAD_ADD acts as shortcut only the first time, then as '+' in the label. Perhaps there's some interaction with changes James has made for shortcuts.

Comment 8 Vaughan Johnson 2012-06-20 23:38:58 UTC

(In reply to comment #6)

> Thanks for more testing. I will do more testing on different machines (after
> 2.0.1). But if I get instant repeatability on a faster machine than one where
> you couldn't repeat it, possibly something more than just machine speed is at
> play? 

Yes, if that happens, please report it. 

> 
> It stops at P4 unless I can reproduce on many more machines ; obviously P2 was
> assuming it was easily reproducible. I have no idea, but maybe fixing this
> could fix the other (not speed-typing) shifts, too?
> 

I do expect there's a bug, or a few, in there, somewhere. Just difficult to find, and increasingly obviated by faster processors.

Comment 9 Gale Andrews 2012-11-14 14:56:14 UTC

Using a script like AutoHotKey to send CTRL + B then type the label also reproduces the issue, unless a sleep command is added to the script to slow it down. See URL.

Comment 10 Leland Lucius 2013-10-04 18:18:38 UTC

Just to verify Gale...this has nothing to do with the automatic scrolling because the label extended to the right of the screen correct?

Comment 11 Gale Andrews 2013-10-05 11:45:42 UTC

(In reply to comment #10)
Leland wrote:
> Just to verify Gale...this has nothing to do with the automatic scrolling
> because the label extended to the right of the screen correct?
Nothing to do with it. I can reproduce the steps by thrashing the CPU with a video encoding then select about a third of the wave close to time zero, use NUMPAD 8 to open a label then use NUMPAD 456456 to type the label. The screen then shifts so that the 456456 label is just about on screen to right.

Then I stopped the video encoding, dragged the horizontal scrollbar back where it was, clicked in the waveform just before the 456456 label, DOWN arrow into the label track, then typed ns . This also shifted the screen rightwards (see http://bugzilla.audacityteam.org/show_bug.cgi?id=452#c0 ) .

Comment 12 Peter Sampson 2018-08-13 11:48:56 UTC

Testing on W10 with audacity-2.3.0-alpha-86-11da92d66846706d83c4cd44a0d05ff34b0f3d4d

I just can't make this happen - the label is always visible as I type fast

So AFAICT this is not a bug any more