yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

Android: drop the top bar; make search a button that opens a modal where search applies #57

New Issue
Closed
opened 2026-08-18 05:59:09 +00:00 by logan · 3 comments
logan commented 2026-08-18 05:59:09 +00:00
Collaborator
Copy Link
Copy Source

Report

We do not need the top bar with the search on mobile. Remove the bar entirely and make search a button that brings up a modal, on the pages where searching is allowed.

Findings

  • The header currently holds the wordmark, the library selector, the search box and the job indicator. Removing the bar means rehoming all four — the job indicator is the awkward one (see the "background jobs indicator is obscured" issue, which proposes turning it into a transient notification).
  • store/search-store.ts already holds the map of what each view searches and whether it can search at all — that is exactly the condition for showing the button.
  • Removing a 4em row is the single biggest vertical win on a 439 CSS px viewport (see the small-screens issue).

Direction

Search becomes a per-view action (an icon in the view's own header area, or a search item in the bottom nav), opening a wa-dialog with the box and live results. Library selection moves into Settings or the "More" surface. Keep the search term view-scoped and keep the "Showing X matching 'y'" line the desktop shows.

**Report** We do not need the top bar with the search on mobile. Remove the bar entirely and make search a button that brings up a modal, on the pages where searching is allowed. **Findings** - The header currently holds the wordmark, the library selector, the search box and the job indicator. Removing the bar means rehoming all four — the job indicator is the awkward one (see the "background jobs indicator is obscured" issue, which proposes turning it into a transient notification). - `store/search-store.ts` already holds the map of what each view searches and whether it can search at all — that is exactly the condition for showing the button. - Removing a 4em row is the single biggest vertical win on a 439 CSS px viewport (see the small-screens issue). **Direction** Search becomes a per-view action (an icon in the view's own header area, or a search item in the bottom nav), opening a `wa-dialog` with the box and live results. Library selection moves into Settings or the "More" surface. Keep the search term view-scoped and keep the "Showing X matching 'y'" line the desktop shows.
logan removed the
Status
Blocked
1
 label 2026-08-20 22:33:32 +00:00
logan commented 2026-08-20 22:33:32 +00:00
Author
Collaborator
Copy Link
Copy Source

Unblocked. #62 is closed, so the job indicator has somewhere to
live that is not this bar.

What that leaves for this issue, of the four things the bar holds:

  • job indicator — done. Below 600px it is already display: none
    and its rows are in <job-band>, a grid row between the top bar and
    the main panel. Nothing here has to rehome it.
  • wordmark — services/top-bar-fit.ts already collapses it, and
    the collapsed form is visually-hidden rather than display: none
    because that h1 is the document's top-level heading. Whatever
    replaces the bar has to keep an h1 somewhere.
  • search box — this issue's own subject. store/search-store.ts
    already holds which views can search, which is exactly the condition
    for showing the button.
  • library filter — the awkward one now. It is the only control in
    the app that calls setSelectedLibrary, so it cannot simply be
    dropped (that is the trade #143 explicitly refused when deciding what
    the top bar gives up). Settings or "More" per the Direction.

One thing measured while doing #62 that is worth knowing here: the
phone's top bar is 3.25em, not the desktop's 4em (index.css), and
the grid template that says so is in the max-width: 599px block —
which is last in the file on purpose, since a media query adds no
specificity. Removing the row means editing that template, not just
hiding the header.

**Unblocked.** #62 is closed, so the job indicator has somewhere to live that is not this bar. What that leaves for this issue, of the four things the bar holds: - **job indicator — done.** Below 600px it is already `display: none` and its rows are in `<job-band>`, a grid row between the top bar and the main panel. Nothing here has to rehome it. - **wordmark** — `services/top-bar-fit.ts` already collapses it, and the collapsed form is visually-hidden rather than `display: none` because that `h1` is the document's top-level heading. Whatever replaces the bar has to keep an `h1` somewhere. - **search box** — this issue's own subject. `store/search-store.ts` already holds which views can search, which is exactly the condition for showing the button. - **library filter** — the awkward one now. It is the only control in the app that calls `setSelectedLibrary`, so it cannot simply be dropped (that is the trade #143 explicitly refused when deciding what the top bar gives up). Settings or "More" per the Direction. One thing measured while doing #62 that is worth knowing here: the phone's top bar is **3.25em**, not the desktop's 4em (`index.css`), and the grid template that says so is in the `max-width: 599px` block — which is last in the file on purpose, since a media query adds no specificity. Removing the row means editing that template, not just hiding the header.
logan self-assigned this 2026-08-20 23:36:13 +00:00
logan added the
Status
In Progress
 label 2026-08-20 23:36:13 +00:00
logan commented 2026-08-20 23:36:14 +00:00
Author
Collaborator
Copy Link
Copy Source

Claiming. Branch feat/57-drop-the-android-top-bar.

Approach, following the inventory above:

  • search box — a PageAction on page-header, gated on
    search-store's own SEARCH_SCOPES / OWN_SEARCH_VIEWS map, opening
    a wa-dialog. A wa-dialog rather than anything popup-shaped for the
    reason #60 established from the Web Awesome source: wa-popup falls
    back to position: fixed without the Popover API, and .main-panel's
    contain: paint clips a fixed descendant. <dialog>/showModal() is
    Chrome 37 and uses the real top layer, so the modal is immune by
    construction rather than by styling.
  • library filter — into Settings -> Libraries as a "Showing"
    control, which is #148's own first suggestion. Taking #148 in this
    pass: it is the library-filter half of this issue and says so.
  • wordmark — the h1 moves into the phone's own chrome rather than
    being deleted; the document keeps a top-level heading at every width.
  • the row — deleted from the max-width: 599px grid template, not
    hidden.

I will say in the PR whether the modal should become #60's
<action-sheet> pattern or wait for it.

Claiming. Branch `feat/57-drop-the-android-top-bar`. **Approach**, following the inventory above: - **search box** — a `PageAction` on `page-header`, gated on `search-store`'s own `SEARCH_SCOPES` / `OWN_SEARCH_VIEWS` map, opening a `wa-dialog`. A `wa-dialog` rather than anything popup-shaped for the reason #60 established from the Web Awesome source: `wa-popup` falls back to `position: fixed` without the Popover API, and `.main-panel`'s `contain: paint` clips a fixed descendant. `<dialog>`/`showModal()` is Chrome 37 and uses the real top layer, so the modal is immune by construction rather than by styling. - **library filter** — into Settings -> Libraries as a "Showing" control, which is #148's own first suggestion. Taking #148 in this pass: it is the library-filter half of this issue and says so. - **wordmark** — the `h1` moves into the phone's own chrome rather than being deleted; the document keeps a top-level heading at every width. - **the row** — deleted from the `max-width: 599px` grid template, not hidden. I will say in the PR whether the modal should become #60's `<action-sheet>` pattern or wait for it.
logan commented 2026-08-21 00:18:17 +00:00
Author
Collaborator
Copy Link
Copy Source

PR #167, CI green, WebKit step confirmed to have actually run.

On the fourth decision the handover asked for — whether this modal
should wait for or become #60's <action-sheet> — the answer is
neither, and #73's Phase 3 → Phase 4 order stands unchanged.

A search modal and an action sheet are different shapes under a rule
this repo already states: a dialog that only asks a question is a
confirmAction() call, and a dialog carrying input is a
<wa-dialog> in the host's own template. This one carries input.
<action-sheet> is for the six menus, whose item model is a list of
actions; nothing here is one, and nothing here needs undoing when it
lands.

What this does take from #60 is your finding, which is the strongest
argument for the Direction and is why the guard here is a component
test rather than an e2e assertion: on Chrome 113 a wa-popup is a
fixed-position box inside .main-panel's contain: paint, and no
tier here can see that, so the assertion is that there is a native
<dialog> in the tree rather than that nothing is clipped.

**PR #167**, CI green, WebKit step confirmed to have actually run. On the fourth decision the handover asked for — **whether this modal should wait for or become #60's `<action-sheet>`** — the answer is neither, and #73's Phase 3 → Phase 4 order stands unchanged. A search modal and an action sheet are different shapes under a rule this repo already states: *a dialog that only asks a question is a `confirmAction()` call, and a dialog carrying **input** is a `<wa-dialog>` in the host's own template.* This one carries input. `<action-sheet>` is for the six *menus*, whose item model is a list of actions; nothing here is one, and nothing here needs undoing when it lands. What this does take from #60 is your finding, which is the strongest argument for the Direction and is why the guard here is a component test rather than an e2e assertion: on Chrome 113 a `wa-popup` is a fixed-position box inside `.main-panel`'s `contain: paint`, and **no tier here can see that**, so the assertion is that there is a native `<dialog>` in the tree rather than that nothing is clipped.
logan closed this issue 2026-08-21 00:18:33 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-21 00:18:42 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Shell-Nav Kind/Enhancement Platform/Android
Priority
High
2
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Depends on
#62 Android: the background-jobs popover is hidden behind other UI — make it a notification instead
yonlu/yellowjacket
Reference: yonlu/yellowjacket#57