You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Remove option for files not visible in landscape #4920
The single-file three-dot menu is a BottomSheetDialog opened in observeMenuOptionsSingleFile():
MainFileListFragment.kt:689 — dialog.setOnShowListener { behavior.peekHeight = fileOptionsBottomSheetSingleFile.measuredHeight } sets the peek to the full measured content height and leaves the sheet STATE_COLLAPSED.
MainFileListFragment.kt:678-687 — drag is disabled (STATE_DRAGGING is forced back to STATE_EXPANDED), so the user can't drag the sheet up either.
Result: in landscape the sheet's own bottom edge sits below the (short) screen, so the last rows (Details → Remove) are off-screen. The inner option list is inside a ScrollView capped at max_height_bottom_sheet (file_options_bottom_sheet_fragment.xml:90-105), and that cap is 300dp in landscape vs 400dp portrait (res/values-land/dims.xml vs res/values/dims.xml) — but that inner cap doesn't help because the whole sheet, header included, is anchored past the viewport bottom, and there's no scroll of the sheet itself. Not reproducible on tablets (taller landscape viewport / sw600dp), matching the report.
Fix direction:
Don't pin peekHeight to full content height; let the sheet expand within the window (STATE_EXPANDED + behavior.maxHeight/skipCollapsed), or clamp peekHeight to the available height so the ScrollView (which already scrolls) becomes the scroll surface. The ScrollView at line 90 already supports scrolling once the sheet is bounded to the screen.
Distinct from the CAB/action-bar landscape fix in #4895 (that only touches the action-mode bar via window insets, not observeMenuOptionsSingleFile) and from #4898 (sort sheet — no capped ScrollView). Same landscape-height family, different component.
Activity
DeepDiver1975 commentedon Jul 6, 2026
Confirmed bug in current master. Located cause:
The single-file three-dot menu is a
BottomSheetDialogopened inobserveMenuOptionsSingleFile():MainFileListFragment.kt:689—dialog.setOnShowListener { behavior.peekHeight = fileOptionsBottomSheetSingleFile.measuredHeight }sets the peek to the full measured content height and leaves the sheetSTATE_COLLAPSED.MainFileListFragment.kt:678-687— drag is disabled (STATE_DRAGGINGis forced back toSTATE_EXPANDED), so the user can't drag the sheet up either.Result: in landscape the sheet's own bottom edge sits below the (short) screen, so the last rows (Details → Remove) are off-screen. The inner option list is inside a
ScrollViewcapped atmax_height_bottom_sheet(file_options_bottom_sheet_fragment.xml:90-105), and that cap is 300dp in landscape vs 400dp portrait (res/values-land/dims.xmlvsres/values/dims.xml) — but that inner cap doesn't help because the whole sheet, header included, is anchored past the viewport bottom, and there's no scroll of the sheet itself. Not reproducible on tablets (taller landscape viewport /sw600dp), matching the report.Fix direction:
peekHeightto full content height; let the sheet expand within the window (STATE_EXPANDED+behavior.maxHeight/skipCollapsed), or clamppeekHeightto the available height so the ScrollView (which already scrolls) becomes the scroll surface. TheScrollViewat line 90 already supports scrolling once the sheet is bounded to the screen.Distinct from the CAB/action-bar landscape fix in #4895 (that only touches the action-mode bar via window insets, not
observeMenuOptionsSingleFile) and from #4898 (sort sheet — no capped ScrollView). Same landscape-height family, different component.🤖 Generated with Claude Code