TERPISAH dari baris utama
"...investigational use only" (yang pakai text-[19px]). Disembunyikan
lewat parent-scoped selector (dibatasi HANYA di dalam popover
disclaimer yang sudah kita kenali -- div.bg-popover.border-muted.
shadow-lg -- supaya .text-\[13px\] tidak sengaja kena elemen lain di
halaman yang kebetulan pakai ukuran teks sama). */
div.bg-popover.border-muted.shadow-lg .text-\[13px\]{
display:none !important;
}
/* --- 12. Perbaiki teks tooltip nyaris tak terbaca (hitam di atas gelap) ---
Komponen Tooltip bawaan OHIF (platform/ui-next/src/components/Tooltip/
Tooltip.tsx) memasangkan `text-primary-foreground` dengan latar
`bg-muted` -- pasangan token yang salah dari sumbernya sendiri (baru
ketahuan sekarang karena override #4 di atas SENGAJA menggelapkan
--primary-foreground supaya teks tombol cyan terang kontrasnya bagus;
Tooltip.tsx lalu ikut memakai token yang sama untuk konteks yang
berbeda -- teks di atas latar gelap `muted`, bukan di atas tombol cyan
terang -- sehingga nyaris tak kelihatan, hampir hitam di atas hitam).
Berlaku untuk SEMUA tooltip hover di viewer, bukan cuma toolbar
MPR/MIP/MinIP/3D. Diperbaiki dengan dipasangkan ke `--muted-foreground`
(token yang memang didesain terang, utk dibaca di atas latar `muted`)
-- TIDAK mengubah token --primary-foreground itu sendiri (supaya
kontras teks tombol cyan tetap seperti semula), cukup timpa warna
tooltip-nya saja lewat selector spesifik struktur Radix Tooltip. */
[data-radix-popper-content-wrapper] [data-side]{
color:hsl(var(--muted-foreground)) !important;
}
/* --- 13. Viewer kepotong di bawah saat dibuka di tablet ---
Dilaporkan 14 Sep 2026: di tablet, lebar aman tapi bagian bawah viewer
(toolbar/gambar) terpotong, tidak ada scroll ke sana sama sekali.
Root cause: OHIF mengukur tinggi elemen utamanya pakai class Tailwind
`.h-screen` (height:100vh) dan turunan `h-full` yang berujung ke situ.
Di Chrome desktop 100vh selalu = tinggi viewport penuh, jadi selalu
pas. Di Safari/Chrome TABLET, 100vh dihitung dari tinggi viewport
TERBESAR (seolah address bar/toolbar browser sedang tersembunyi) --
sedangkan area yang benar-benar terlihat lebih pendek karena toolbar
itu MASIH ada. Bagian bawah elemen jadi ke-render di luar area
terlihat, dan karena body di-set overflow:hidden (viewer didesain
sbg app satu-layar, sengaja tidak bisa page-scroll), tidak ada jalan
sampai ke sana.
Fix: unit CSS modern `dvh` (dynamic viewport height) -- otomatis
menyesuaikan tinggi toolbar browser yang benar-benar terlihat, bukan
viewport maksimal teoretis. Dipasang SETELAH deklarasi vh (bukan
menggantikannya) supaya browser lama yang belum kenal `dvh` tetap
pakai vh sebagai fallback (aturan CSS terakhir yang dikenali browser
yang menang).
TERBUKTI TIDAK CUKUP SENDIRIAN (uji lewat tablet asli 14 Sep 2026 --
panel coronal/sagittal di bawah tetap kepotong): dvh mengurangi
selisihnya tapi tidak menjamin PAS di semua tablet/browser.
Percobaan KEDUA yang GAGAL LEBIH PARAH (baru diketahui lewat verifikasi
emulator SEBELUM sempat sampai ke tablet -- lihat diskusi, jangan
diulang): memaksa `#root, #root > *{height:auto}` supaya body bisa
"mengembang" mengikuti konten. Ternyata layout grid viewport Cornerstone
BERGANTUNG pada rantai tinggi definitif (bukan auto) dari #root ke
bawah utk menghitung ukuran piksel kanvas gambar via ResizeObserver --
begitu salah satu leluhurnya jadi height:auto, seluruh viewport
RUNTUH ke tinggi 0 dan HALAMAN JADI KOSONG TOTAL (bukan cuma
kepotong, malah tidak render apa-apa). #root DAN turunannya TIDAK
BOLEH disentuh height/min-height-nya sama sekali.
Fix yang benar (tahap 1): JANGAN ubah rantai tinggi #root ke bawah
(biarkan OHIF mengatur ukuran kanvasnya sendiri lewat dvh di atas).
Cuma izinkan `overflow-y:auto` pada html/body TANPA memaksa height
apa pun di situ -- kalau tinggi konten (hasil dvh) kebetulan masih
lebih tinggi dari viewport yang benar-benar terlihat, body/html yang
overflow BUKAN #root, jadi aman di-scroll tanpa mengganggu
perhitungan ukuran kanvas. Berlaku universal (tidak dibatasi
tablet) -- aman di desktop krn overflow-y:auto tidak berbuat apa-apa
selama konten tidak melebihi tinggi layar.
TAHAP 1 MASIH TIDAK CUKUP (uji tablet asli lagi, 14 Sep 2026): `.h-
screen` TERNYATA TIDAK PERNAH DIPAKAI SAMA SEKALI di route viewer ini
(dicek langsung: querySelectorAll('.h-screen') kosong) -- rule itu
selama ini TIDAK BERBUAT APA-APA di halaman yang bermasalah, salah
sasaran dari awal. Elemen yang SEBENARNYA menentukan tinggi baris
konten (pembungkus panel kiri + grid viewport + panel kanan, di
BAWAH header) ternyata diset lewat INLINE STYLE dari JS OHIF sendiri:
style="height: calc(-52px + 100vh)" pada
div.relative.flex.w-full.flex-row.flex-nowrap.items-stretch.overflow-hidden.bg-background
-- 52px = tinggi header (h-[48px] + border), 100vh = sumber masalah
yang sama (vh vs dvh), TAPI di-set inline, jadi class .h-screen tidak
relevan di sini. Elemen ini JUGA punya overflow-hidden SENDIRI, jadi
kalau 100vh > tinggi yang benar-benar terlihat, baris ini memotong
ISINYA SENDIRI (grid viewport) -- ini yang bikin gejala "scroll ada,
tapi cuma di section gambar 2x2" (overflow html/body dari tahap 1
menggeser baris yang SUDAH kepotong ini, bukan mencegahnya kepotong).
Override lewat CSS eksternal + !important -- SATU-SATUNYA cara CSS
biasa menang atas inline style, dan tetap menang meski JS OHIF
menulis ulang inline style itu tiap resize (nilai computed akhir
tetap ikut rule !important kita, bukan string vh yang JS tulis).
TIDAK diubah ke `auto` (pelajaran dari percobaan kedua di atas) --
cuma ganti unit vh->dvh, tetap nilai definitif. 52px di-hardcode
sesuai yang OHIF sendiri hitung utk header Lumen ini (stabil kecuali
header di-redesain ulang). */
.h-screen{
height:100dvh !important;
}
html, body{
overflow-y:auto !important;
}
div[class~="flex-row"][class~="flex-nowrap"][class~="items-stretch"][class~="overflow-hidden"]{
height:calc(-52px + 100dvh) !important;
}