27e27b2c53090276a82fa8a4a8ae89f8db288263 braney Tue Sep 29 14:13:18 2026 -0700 docent rm38198 release-ab proof line, and registry rows for #38428 and #38430, refs #38198, #38428, #38430, #38252 rm38198's container reopen section fails on hgwbeta (v504, which lacks dba11b63364) and passes on genome-test. htmlSanitizeTest goes red when the svg allowlist of 7a356d85dba is backed out by hand, so #38428 gets a sandbox-ab row. #38430 gets a page row with no test yet. Both changes sit behind the hubHtmlSanitize gate. diff --git src/hg/utils/docent/tests/regress/rm38198.docent.yaml src/hg/utils/docent/tests/regress/rm38198.docent.yaml index 558a5e25afd..9bb3cd46199 100644 --- src/hg/utils/docent/tests/regress/rm38198.docent.yaml +++ src/hg/utils/docent/tests/regress/rm38198.docent.yaml @@ -1,126 +1,127 @@ # #38198 -- a second quickLift in the same session never updated a track that was already in # the lift hub. # # The hub writer skipped any track whose name it found in the hub file, so a track that had # been lifted once was frozen in the state it had at that moment. Two consequences, both # confirmed on hgwdev: a subtrack switched on after the first lift never reached the target, # and a visibility change on a track that had already been lifted never reached it either. # Found while testing #38032. # # f001e39d156 (merged as 437e6ad4150), hg/lib/trackHub.c. walkTree() no longer takes the set # of names already in the file and no longer skips a track for being there; it writes every # visible track into a dyString, and the new writeMergedHubFile() merges that over the file -- # a generated stanza replaces the old stanza of the same track IN THE SLOT THE OLD ONE HELD, # so parents stay ahead of their children, and a track in the file that was not generated this # time is kept, so tracks still accumulate across lifts. The skip could not simply be # dropped: a duplicate track name makes hub loading abort. # # This asserts the visibility half, on a top-level track, and it asserts it with the image # HEIGHT, which is unusual here and is the only thing that can say it. dense and pack draw # the same row under the same name with the same items, so rows:, text: and has: are all # blind to the difference; what changes is how many lines of transcripts the row takes. # Measured on 2026-09-17: 100 px after the dense lift and 436 px after the pack lift, with # hide: all and one gene track, so the bounds below are deliberately far from both numbers -- # a GENCODE update moves how many transcripts BRCA1 packs into, and this test is not about # that. Anything under 200 px is a row that did not re-pack. # # WHY NOT THE SUBTRACK HALF, which is what the ticket was filed about: it cannot be seen from # a rendered page today. A composite is written to the hub with ALL of its valid children, # hidden ones included, and those children come back VISIBLE on the target -- that is #38044, # still open. So a subtrack switched on between the two lifts is already drawn on the first # target, and both builds look the same. Measured with clinvar before this script was # written: lift one with clinvarMain and clinvarSubLolly hidden still drew all three rows on # hs1. If #38044 is ever fixed, that route becomes the tighter test and belongs here. proof: - "assertion-only 2026-09-17 -- written from #38198 and f001e39d156 after the fix reached genome-test" - "release-ab 2026-09-17 -- fails on v503 and passes on genome-test (v504). v503_branch 707b184e329 built into ticket sandbox 38316, CGIs, js and htdocs: the second lift's target is 100px, not >300" - "sandbox-ab 2026-09-28 -- container reopen section: fails on genome-test, which does not carry the fix (dba11b63364 on master), and passes on ts park 38198 (superVis38198, 25d72992255). Each of its three checks was removed in turn and the next one still failed on genome-test: lift 2 target, the source after lift 2, lift 3 target" + - "release-ab 2026-09-29 -- container reopen section: fails on hgwbeta (v504, whose v504_branch lacks dba11b63364) and passes on genome-test. On v504 step 26 fails, rows not drawn: wgEncodeReg4MarkH3k27ac after lift 2" target: genome-test db: hg38 position: chr17:43044295-43125483 reset: true fast: true steps: - go: chr17:43044295-43125483 - hide: all - track: {knownGene: dense} - expect: {rows: [ruler, knownGene], exact: true, height: "<120"} # First lift. One line of transcripts on the target, because that is what the source said. - convert: {to: hs1, quicklift: true} - open: lift - expect: rows: [quickLiftChain, knownGene] height: "<200" noText: "Warning/Error" # Back to the source and change nothing but the visibility. The track's name is in the hub # file from the first lift, which is the condition the bug needed. - goto: "/cgi-bin/hgTracks?db=hg38&position=chr17:43044295-43125483" - track: {knownGene: pack} - expect: {rows: [ruler, knownGene], height: ">300"} # Second lift. The stanza has to be rewritten with the state the track has NOW. Before # f001e39d156 this page came back the same height as the first one. - convert: {to: hs1, quicklift: true} - open: lift - expect: rows: [quickLiftChain, knownGene] height: ">300" noText: "Warning/Error" # ---- The reopen of 2026-09-23: a container set back to show stayed hidden. ---------------- # # Jairo's recipe: show the ENCODE4 Regulation container (wgEncodeReg4) with H3K27ac on and # lift; hide the container and lift; show it again and lift. After the third lift H3K27ac # was missing from the target, and it stayed missing. # # The hub file was not the cause. On the page a lift opens, hgTracks read a quickLifted # superTrack's state from the cart: it copied the source's bare wgEncodeReg4 into # hub_<n>_wgEncodeReg4 and then removed the bare one. So lift 2 stored hide under the hub # name. Setting the container back to show is setting it back to its default, and hgTracks # prunes a cart value equal to the default, so lift 3 had nothing to carry and the stored # hide won forever. The same step also deleted the source's own wgEncodeReg4=hide. # dba11b63364 (hg/hgTracks/hgTracks.c, hg/lib/trackHub.c) drops the hub_ value after a lift # and leaves the source's value alone. # # Three checks, and each would fail on the old build: # * after lift 3, H3K27ac is on the target (the bug itself); # * back on the source after lift 2, the container is still hidden (the deleted setting); # * after lift 2, H3K27ac is still on the target. That is the chosen behavior, not an # accident: a container hidden on the source keeps the stanza an earlier lift wrote, # the same as a hidden track. If that rule is ever changed on purpose, change this line. - goto: "/cgi-bin/hgTracks?db=hg38&position=chr17:43044295-43125483" - hide: all - track: {wgEncodeReg4: hideKids, wgEncodeReg4MarkH3k27ac: full} - expect: {rows: [ruler, wgEncodeReg4MarkH3k27ac], exact: true} # Lift 1, container showing. This one worked before the fix too. - convert: {to: hs1, quicklift: true} - open: lift - expect: {rows: [quickLiftChain, wgEncodeReg4MarkH3k27ac], noText: "Warning/Error"} # Hide the container on the source. - goto: "/cgi-bin/hgTracks?db=hg38&position=chr17:43044295-43125483" - track: {wgEncodeReg4: hide} - expect: {rows: [ruler], noRows: [wgEncodeReg4MarkH3k27ac]} # Lift 2, container hidden. - convert: {to: hs1, quicklift: true} - open: lift - expect: {rows: [quickLiftChain, wgEncodeReg4MarkH3k27ac], noText: "Warning/Error"} # Back on the source, straight after the target visit, with no change made. Before the fix # visiting the target had removed wgEncodeReg4=hide, so the container came back. - goto: "/cgi-bin/hgTracks?db=hg38&position=chr17:43044295-43125483" - expect: {rows: [ruler], noRows: [wgEncodeReg4MarkH3k27ac]} # Show the container again. H3K27ac keeps full from the first step. - track: {wgEncodeReg4: show} - expect: {rows: [ruler, wgEncodeReg4MarkH3k27ac]} # Lift 3. Before dba11b63364 the target drew only the chain and knownGene here. - convert: {to: hs1, quicklift: true} - open: lift - expect: {rows: [quickLiftChain, wgEncodeReg4MarkH3k27ac], noText: "Warning/Error"}