e497eccfb431be6af38d22c5bc2bb0e745c89b2d
braney
  Sat Sep 5 09:22:17 2026 -0700
docent: eight more regression scripts, one per fixed bug

rm35580  "Show <alt> placed on its chromosome" errored on the window
rm36061  DECIPHER SNVs details missing after a quickLift
rm36335  a quickLifted GIAB item click printed a garbled "can't port"
rm36340  a search-result click carried the source coordinate
rm37491  hgConvert named subtracks the user never showed as not liftable
rm37562  a stale lastPosition banner on the lifted search-results page
rm37615  a quickLifted bigBed tooltip reported pre-lift coordinates
rm37785  a squishyPack track stole a neighbouring track's center label

Each asserts the behavior its ticket says is correct, on genome-test, and names
in noText:/noUrl: the exact string the buggy build produced rather than a generic
"Error". Where the last page has no track image the noText: is paired with a
positive text: or url: check, because a bare noText: passes just as happily on a
blank page or an early error.

Four things found writing these, all of them recorded in the scripts:

A ticket's stated position and its stated item can disagree. #36061 says to go to
chr7:156,982,676-156,996,015 and click item 517898; that item is at
chr7:155,803,191, and decipherSnvs draws nothing at all in the ticket's window.

hideKids cannot express "the user deselected this subtrack". It writes a
<track>=hide cart variable, and isSubtrackVisible() (hg/lib/trackHub.c) begins
with overrideComposite = (NULL != cartOptionalString(cart, tdb->track)) and then
forces enabled = TRUE, so the sibling counts as visible to hgConvert and lands
back in the "failed to lift" warning. A first rm37491 failed on exactly that and
looked like the bug being back. A deselected subtrack is <track>_sel=0 with no
visibility variable, which is what hgTrackUi's checkbox writes and what the goto:
in that script sets.

#37615's fix is not the one the plan for this suite described. The first commit
appended a note saying the coordinates came from the source assembly; the second
replaced it with the real fix, which puts the TARGET coordinates in the tooltip.
A test for the note would fail.

decipherSnvs (SNVs) and decipher (CNVs) are two different members of the
superTrack decipherContainer, and the row that turns up when the SNVs track draws
nothing is the CNVs one, which reads like the same track under a shorter id.

refs #38252

diff --git src/hg/utils/docent/tests/regress/rm36340.docent.yaml src/hg/utils/docent/tests/regress/rm36340.docent.yaml
new file mode 100644
index 00000000000..671b131c061
--- /dev/null
+++ src/hg/utils/docent/tests/regress/rm36340.docent.yaml
@@ -0,0 +1,50 @@
+# #36340 -- a search-result click after a quickLift could not find the source coordinate.
+#
+# Gerardo's steps: load his session, QuickLift to human HG02257.pat 2021, search "brca2" on
+# the lifted view, and click the BRCA2 hit under "MANE Select Plus Clinical". The result was
+#
+#     Sorry, couldn't locate chr13:32315508-32400268 in HG02257.alt.pat.f1_v2 May 2021
+#     human (HG02257.pat 2021)
+#
+# -- the hit carried the SOURCE assembly's coordinate and the target could not resolve it.
+# Same error from the "NCBI Gene Orthologs" hit.
+#
+# The target is named by ACCESSION, not by label, and that is not cosmetic here. GenArk
+# carries two releases whose labels differ only in punctuation, and for this sample they
+# swap haplotype between them: GCA_018466835.1 is HG02257 PAT (2021) while
+# GCA_018466835.2 is HG02257 MAT (2024). A label fragment like "HG02257.pat" would be one
+# hub update away from matching the wrong assembly.
+#
+# The session is Gerardo's own, kept because what it holds -- a custom track plus a hub on
+# hg38 -- is what made the search return several kinds of hit.
+target: genome-test
+db: hg38
+reset: true
+fast: true
+steps:
+  - loadSession: {user: Gerardo, name: quickLift_CT_hub}
+  - expect: {noText: "Could not find session"}
+
+  - convert: {to: GCA_018466835.1, quicklift: true}
+  - open: lift
+  - expect: {noText: "Sorry, couldn't locate"}
+
+  - goShow: "brca2"
+  - expect: {url: "/hgSearch", noText: "Sorry, couldn't locate"}
+
+  # The first BRCA2 hit on the results page. Which of the several hits it is does not
+  # matter much -- they all resolve to the same gene span -- but where it LANDS matters a
+  # great deal, and that is what the next step reads.
+  - click: 'a:has-text("BRCA2")'
+
+  # This is the assertion the script exists for, and noText: is the weaker half of it.
+  # The bug sent the click at the SOURCE coordinate, chr13:32,315,508-32,400,268, which the
+  # target cannot resolve. Fixed, the click lands on the target's own contig:
+  # JAGYVI010000002.1:12,922,586-13,007,328, measured 2026-09-05, and 84,742 bases wide
+  # against BRCA2's 84,760 on hg38. Naming the source coordinate in noUrl: is what makes
+  # this fail on the buggy build rather than merely pass on the fixed one.
+  - expect:
+      url: "position=JAGYVI010000002.1%3A12922586"
+      noUrl: "chr13%3A32315508"
+      noText: "Sorry, couldn't locate"
+      rows: [mane, knownGene]