Cursor Bug in new editing fields for the Source Linker
LegacyUser
✭✭✭✭
Jeff Wiseman said: Recently I have been running into this very frustrating behavior with the new vital fields editing feature in the source linker. For census records, I normally improve the residence information from the index files via the following sequence:
First select the data to be brought over to the FS record...
Then modify the data in the new vitals editing fields...
Finally, I place the cursor (via my mouse) into the "Reason to Attach Source" field and start typing where the data was taken from...
As you can see, only the first character goes into the Reason field and then the cursor JUMPS BACK into the residence block and starts editing that block.
If you reposition the cursor back to after the "t" in the Reason field and continue typing, the same thing occurs (i.e., only one more character goes into the Reason field and the others jump back into the Residence field. The only way I can enter the text in the Reason field is to type "t", then reposition the cursor after the "t", then type "a", then reposition the cursor after the "a". You have to do this 2 or 3 times before the positioning of the cursor in the Reason field finally "sticks" and I can continue typing without the cursor jumping around the page dropping text as it goes.
This was totally bizarre, infuriating, and 100% reproducible (although I haven't tried it yet today, it was doing this yesterday and the day before).
Using Safari 12.1.2 on an iMac17,1 running macOS 10.12.6 (Sierra)
First select the data to be brought over to the FS record...
Then modify the data in the new vitals editing fields...
Finally, I place the cursor (via my mouse) into the "Reason to Attach Source" field and start typing where the data was taken from...
As you can see, only the first character goes into the Reason field and then the cursor JUMPS BACK into the residence block and starts editing that block.
If you reposition the cursor back to after the "t" in the Reason field and continue typing, the same thing occurs (i.e., only one more character goes into the Reason field and the others jump back into the Residence field. The only way I can enter the text in the Reason field is to type "t", then reposition the cursor after the "t", then type "a", then reposition the cursor after the "a". You have to do this 2 or 3 times before the positioning of the cursor in the Reason field finally "sticks" and I can continue typing without the cursor jumping around the page dropping text as it goes.
This was totally bizarre, infuriating, and 100% reproducible (although I haven't tried it yet today, it was doing this yesterday and the day before).
Using Safari 12.1.2 on an iMac17,1 running macOS 10.12.6 (Sierra)
Tagged:
0
Comments
-
Jeff Wiseman said: There has been no response to this rather spastic behavior in the source linker. Is it being looked at?0
-
Cindy Hecker said: I can tell you I have seen this too.0
-
Tom Huber said: Jeff, try approaching this in a different order:
Enter the reason statement first.
Next, move the residence over
Now Edit the residence entries.
Any problems?0 -
Jeff Wiseman said: I don't have anything to try this on at present. For now, the hack is to keep repositioning the cursor until it "sticks" as I indicated in my initial post. But why should I have to use a completely backward workflow in order to get around the fact that it is broken and needs repair.
It's weird to enter a reasons statement for why you've changed something BEFORE you even change it!0 -
Tom Huber said: Well, backward to you, but I start with the reason statement and go from there.
The real kicker is the really apparent bug in that the cursor does not remain in lace while making the entry.
That definitely needs to be resolved.0 -
Tom Huber said: I’m talking about working with attaching sources that contain more than one name. Manually adding information outside the source linker is a different matter.0
-
Jeff Wiseman said: Yes, I was just starting to try those edit boxes. I wasn't real interested at first, but then I realized it might speed things up a bit for me. Indexes for Censuses only contain the year number and general area that the census was (supposedly) collected. I Always go directly to the image of the appropriate census page and retrieve the EXACT date (Month/Day/Year), and when provided the EXACT location including street number and street name when available. This extra information has been VERY useful in many cases when verifying birthdays and movements of families from area to area.
However, it usually requires me to first link all persons in the source to their appropriate names in the tree with the source linker, and then go back to each person that was in the census, open their person page, and modify the Residence information. If you create text strings ahead of time of the residence data for the different family members (remember that text will be the same for each of them), I can then go into the source linker and just paste in each field as you go through the different names on the census in that family group (some of them have 10-15 names). The date, place, and Reason fields will be the same for everyone in the family group for that census page.
It looks promising but I haven't fully explored it yet. Once I started running into this irritating behavior, I just stopped using the feature. It will be nice to finally try this out again if they decide to fix it.0 -
Jacob Reid said: We are aware of the issue and are working to resolve it.0
-
Jeff Wiseman said: Hooray! This is a bug that drives me CRAZY because when I'm working in the Tree, I keep forgetting about it :-)0
This discussion has been closed.