e497eccfb431be6af38d22c5bc2bb0e745c89b2d braney Sat Sep 5 09:22:17 2026 -0700 docent: eight more regression scripts, one per fixed bug rm35580 "Show 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 =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 _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/rm37785.docent.yaml src/hg/utils/docent/tests/regress/rm37785.docent.yaml new file mode 100644 index 00000000000..5b52919c345 --- /dev/null +++ src/hg/utils/docent/tests/regress/rm37785.docent.yaml @@ -0,0 +1,47 @@ +# #37785 -- a squishyPack track stole a neighbouring track's center label. +# +# GENCODE (knownGene) in squishyPack is drawn as two slices, a full-height part and a +# squished part, which smashSquish() stitches back together on the assumption that the +# squished clone is drawn immediately after its source. flatTracksCmp() broke an +# image-order tie involving that clone purely by visibility, even against an unrelated +# track sharing the same order, so MANE could sort between knownGene and its own clone. +# smashSquish() then merged the squished slice onto MANE's row and dragged MANE's center +# label with it: the label above knownGene's items read "MANE". Fixed in +# hg/hgTracks/imageV2.c, 7bed537d83b. +# +# The recipe is Lou's own URL from the ticket, which is all state and no session: both +# tracks in pack and both given the SAME image order, which is what makes the tie. +# +# What makes this test different from every other one here: rows:, height: and text: are +# all blind to the bug. The same three rows are drawn either way, the total image height +# is the same, and the labels are drawn into a PNG rather than into the page text. The only +# thing that changes is which row's the center label's image map hangs off, so this +# is the one script that uses has:/noHas: to say where an element sits. +# +# hgTracks puts each center label in a MAP named map_center_, inside the data cell +# of the row it belongs to. Fixed: map_center_mane is in td_data_mane. Buggy: it moved into +# td_data_knownGene along with the squished slice. Both halves are asserted, because the +# right map being present says nothing about a stray copy elsewhere. +target: genome-test +db: hg38 +position: chr11:528907-538911 +reset: true +fast: true +steps: + - go: chr11:528907-538911 + - hide: all + # squishyPack, and the colliding image order, are cart variables with no verb of their + # own, so this is the goto: escape hatch. It is also the exact URL the ticket used. + - goto: "/cgi-bin/hgTracks?db=hg38&position=chr11:528907-538911&hideTracks=1&knownGene=pack&mane=pack&knownGene_imgOrd=4&mane_imgOrd=4&pix=1100" + + - expect: + rows: [ruler, mane, knownGene] + exact: true + ordered: true + noText: "Warning/Error" + has: + - "#td_data_mane map[name=map_center_mane]" + - "#td_data_knownGene map[name=map_center_knownGene]" + noHas: + - "#td_data_knownGene map[name=map_center_mane]" + - "#td_data_mane map[name=map_center_knownGene]"