Page MenuHomePhabricator

Render the focused module view as a full-screen page
Closed, ResolvedPublic8 Estimated Story Points

Description

Summary

The dashboard can render a single module as a focused view on its own subpath, such as the Review Changes route. Today it renders inline within the dashboard, so the module sits below the other cards and its content starts partway down the page. Per the feedback in T433063#12171220, this is a regression. That view should be a full-screen experience showing the module on its own.

The same focused-module URL currently renders one of two ways depending on how it is reached:

  • As a dialog over the dashboard on a client-side open.
  • As a whole page on a cold load or bookmark.

The full-screen behavior should be consistent across both, so the view a user bookmarks matches the one they reach by navigating in. Review Changes is the reported case, but the fix applies to any module opened as its own view.

In addition, the header has unmatched padding for top/bottom, large padding to the left of the text, and the text size it too large.

Top / bottom paddingPadding on the left
Screenshot 2026-07-17 at 17.25.36.png (1,288×152 px, 33 KB)
Screenshot 2026-07-17 at 17.25.41.png (634×226 px, 30 KB)

Proposed changes (Figma)

  • The text size should be Heading 4, smaller than it currently is.
  • The top padding should match the bottom padding.
  • The left padding should be 14px, narrower than it currently is.

Acceptance criteria

  • A module's focused view renders as a full-screen page showing that module on its own, not inline below the other dashboard cards.
  • The focused view renders the same way whether reached by in-product navigation or by loading its URL directly.
  • Review Changes opens to its full-screen focused view with content starting at the top of the page.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
jsn.sherman renamed this task from Title: Render the focused module view as a full-screen page to Render the focused module view as a full-screen page.Aug 3 2026, 9:59 PM
jsn.sherman updated the task description. (Show Details)
TheresNoTime set the point value for this task to 3.
TheresNoTime subscribed.
Samwalton9-WMF changed the point value for this task from 3 to 5.
Dillon changed the task status from Open to In Progress.Aug 4 2026, 4:14 PM
Dillon claimed this task.
Dillon moved this task from Ready to In Progress on the Moderator-Tools-Team (Kanban) board.
Dillon updated the task description. (Show Details)
Dillon reopened this task as In Progress.Aug 4 2026, 5:33 PM
Dillon changed the task status from In Progress to Open.Aug 4 2026, 7:19 PM
Dillon moved this task from In Progress to Ready on the Moderator-Tools-Team (Kanban) board.

Moving this task back to Ready that way it's clear T433063: vary dashboard detail from viewport, not platform needs to be merged in first.

Dillon changed the task status from Open to In Progress.Aug 6 2026, 2:53 PM
Dillon moved this task from Ready to In Progress on the Moderator-Tools-Team (Kanban) board.

Change #1325536 had a related patch set uploaded (by Dillon; author: Dillon):

[mediawiki/extensions/PersonalDashboard@master] Render the focused module view as a full-screen page

https://gerrit.wikimedia.org/r/1325536

Test wiki created on Patch demo by DHardy-WMF using patch(es) linked to this task:
https://fc55c4d5e9.catalyst.wmcloud.org/w/

Change #1325536 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Render the focused module view as a full-screen page

https://gerrit.wikimedia.org/r/1325536

Change #1325551 had a related patch set uploaded (by MusikAnimal; author: Dillon):

[mediawiki/extensions/PersonalDashboard@wmf/1.47.0-wmf.15] Render the focused module view as a full-screen page

https://gerrit.wikimedia.org/r/1325551

Change #1325551 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@wmf/1.47.0-wmf.15] Render the focused module view as a full-screen page

https://gerrit.wikimedia.org/r/1325551

Mentioned in SAL (#wikimedia-operations) [2026-08-13T19:24:20Z] <musikanimal@deploy1003> Started scap sync-world: Backport for [[gerrit:1325551|Render the focused module view as a full-screen page (T433896)]]

Mentioned in SAL (#wikimedia-operations) [2026-08-13T19:41:25Z] <musikanimal@deploy1003> musikanimal: Backport for [[gerrit:1325551|Render the focused module view as a full-screen page (T433896)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-08-13T19:54:57Z] <musikanimal@deploy1003> Finished scap sync-world: Backport for [[gerrit:1325551|Render the focused module view as a full-screen page (T433896)]] (duration: 30m 37s)

Change #1322093 had a related patch set uploaded (by Jsn.sherman; author: Jsn.sherman):

[mediawiki/extensions/PersonalDashboard@master] Open focused modules in the module dialog

https://gerrit.wikimedia.org/r/1322093

Moving back to review since I have a followup patch in need. Patchdemo created for exploration at your leisure.

Olga and I were reviewing this and we think the new full screen-ing looks great on mobile, but doesn't work well on desktop. Can we retain the current behaviour, where we open up within the Special page bounds, on desktop, but retain the new fullscreen behaviour on mobile?

Olga and I were reviewing this and we think the new full screen-ing looks great on mobile, but doesn't work well on desktop. Can we retain the current behaviour, where we open up within the Special page bounds, on desktop, but retain the new fullscreen behaviour on mobile?

We aren't dealing with a mobile/desktop split here. What we have is php/js and viewport width. I think we can accomplish what you're asking for with a few caveats. I'll take a swing at it and report back.

Test wiki created on Patch demo by JSherman (WMF) using patch(es) linked to this task:
https://6ee6346daa.catalyst.wmcloud.org/w/

Thank you, @jsn.sherman! It is looking good.

A couple of proposed tweaks, and then I have a question about the page title.

  1. Header padding and height do not match the designs. The padding around the header/arrow is larger than in the designs. The height should be = 46px while padding left/right = 10px from the tip of the arrow or 2px padding from the button area. Additionally, the divider is missing from the bottom of the header (border token, subtle).

Mobile header:

CurrentDesigns
Screenshot 2026-08-26 at 13.34.00 1.png (500×202 px, 18 KB)
Group 4.png (500×176 px, 16 KB)
  1. For the desktop header, the same should apply but the text should align left as it does currently.

Desktop header:

CurrentDesigns
Screenshot 2026-08-26 at 19.29.56.png (726×176 px, 17 KB)
Screenshot 2026-08-26 at 19.29.29.png (1,548×316 px, 40 KB)
  1. I was wondering about the Review Changes page title on desktop. The current keep the "Hello User!", however, that is not usually the pattern seen on wiki.

I was looking at other pages and subpages are divided by "/" however it doesn't seem that the page it necessarily a subpage according to the URL?

"/" for subpagesURL
Screenshot 2026-08-26 at 17.36.47 1.png (925×152 px, 35 KB)
Screenshot 2026-08-26 at 18.56.55.png (1,258×80 px, 24 KB)

Then I was thinking if we need it at all? @Samwalton9-WMF

Title with "/"No title
Group 1.png (1,440×358 px, 66 KB)
Group 3.png (1,440×381 px, 56 KB)

Test wiki created on Patch demo by JSherman (WMF) using patch(es) linked to this task:
https://732215f908.catalyst.wmcloud.org/w/

new patchdemo up:
https://732215f908.catalyst.wmcloud.org/wiki/Special:PersonalDashboard

@OTichonova
I think I got the alignment happy everywhere.
On 3, IMO the current behavior is not out of line for a special page. I'd strongly discourage us from wading into things beyond the content area.

I am concerned with all the skin overrides needed to prevent the FOUCs when loading a focused module i.e. https://732215f908.catalyst.wmcloud.org/wiki/Special:PersonalDashboard/ext.personalDashboard.reviewChanges (the feed appears to be broken on Patch Demo but it works in the patch, ignore; I'm just talking about the full-screen takeover part).

Would it be acceptable to have a "pending takeover" state like VisualEditor and MobileFrontend? See this example. For a brief moment, the skin renders normally and has a message "The editor will now load. If you still see this message after a few seconds, please [reload the page]." In our case it would say "The dashboard is loading. If you still see this message …" or something similar. If we go this route, we can avoid the skin overrides which are likely to break in the future and may not work at all on third-party skins. After the dashboard loads, we'd still get the full-screen takeover as the designs call for.

Correction: showPendingTakeover() doesn't remove the skin's chrome. VisualEditor's Hooks::onCustomEditor() and MobileFrontend's MobileFrontendEditorHooks::onCustomEditor() just return false. That only skips EditPage::edit(). showPendingTakeover() adds the message to the output, a <noscript> meta-refresh, and a no-ResourceLoader queue redirect. The response is a normal skinned page with just the parsed loading message. I confirmed that locally: the mobile editor takeover renders the Minerva header and footer around "The editor will now load."

So the loading state and the full-screen presentation are two separate things. MobileFrontend's overlay does the full-screen mobile view with an absolutely positioned div appended to body + html.overlay-enabled clipping the page container's overflow (resources/mobile.startup/Overlay.less).

The skin chrome is all still there. Neither VisualEditor nor MobileFrontend references #mw-head, .vector-header-container, or .minerva-header. VisualEditor desktop doesn't take over at all: it dims the read content while loading (.ve-loading, opacity 0.5), and once active hides a few in-content items and Vector 2022's TOC. So, I'm going to:

  • Drop focusedChrome.less
  • Give the focused container an opaque fixed-position layer at narrow widths
  • z-index-300, the Codex position: fixed token, and overflow: hidden on body for the scroll lock

No skin selectors at all. The z-index did need measuring against each skin, so here it is, from the five production skins locally:

  • Vector 2022 tops out at z-index: 50 for the pinned TOC and dropdowns, and .vector-sticky-header-container is only 3
  • Vector legacy has nothing of its own at or above 200, and an overlay at 200 covered all 49 sample points
  • Minerva's chrome is entirely static
  • MonoBook's sits at 3 and 4
  • Timeless is different: #mw-header-container is position: fixed; z-index: 200, with its nav columns at 197 through 199

Above that are the shared layers that should stay above us:

  • the Codex dialog backdrop at 400
  • dialogs and #mw-teleport-target at 450
  • popovers at 700
  • tooltips at 800
  • toasts at 900

So z-index-300 rather than 200: it clears Timeless's always-visible fixed header and GrowthExperiments' body-level help panel overlay (both are 200), and it stays under the dialog backdrop so a Codex dialog still opens above the focused view.

Two skins keep interaction-triggered chrome above anything we'd pick:

  • Timeless's .sidebar-inner, .dropdown at 350
  • MonoBook's .mobile-menu-active at 10000 with .menus-cover at 9999

Neither is reachable while the overlay covers its toggle, so in practice they stay down. The exception is keyboard focus, which is what the inert walk fixes: without it a keyboard user can tab to MonoBook's covered menu toggle and open a menu at 10000 over the focused view.

I played around with doing this server-side via useskin=apioutput. That renders a page with <head> and ResourceLoader intact but no header, sidebar, or footer. Wikistories hand-assembles a view like this from setArticleBodyOnly() plus headElement(). Both are server-side decisions though, and chrome-free here is conditional on viewport width, which the server doesn't know.

notes

  • The server render stays. A loading message would cost us the server-rendered module and a round trip, and buy no chrome removal, since the takeover page is fully skinned. Worth it for an editor that can't be server-rendered; not worth it here
  • The chrome stays focusable behind the overlay, where display: none removed it from tab order for free. Nothing marks it inert or aria-hidden, and I confirmed the search input still takes focus while painted over. MobileFrontend's overlay does it this way too. We can do better by walking up from the container to body and marking each ancestor's siblings inert, which needs no skin selectors either
jsn.sherman changed the point value for this task from 5 to 8.

Test wiki created on Patch demo by JSherman (WMF) using patch(es) linked to this task:
https://df0d1e85aa.catalyst.wmcloud.org/w/

Note that mobile device emulation in desktop mode behaves oddly because of vector + mobilefrontend-specific behavior, but regular desktop views and real (android) devices work fine. Haven't tested a narrow apple device.

Change #1322093 merged by jenkins-bot:

[mediawiki/extensions/PersonalDashboard@master] Focused modules: narrow dialog, wide frame

https://gerrit.wikimedia.org/r/1322093

jsn.sherman updated the task description. (Show Details)
jsn.sherman moved this task from QA to Done on the Moderator-Tools-Team (Kanban) board.

Test wiki on Patch demo by DHardy-WMF using patch(es) linked to this task was deleted:

https://fc55c4d5e9.catalyst.wmcloud.org/w/