## Summary When a work plan contains wide markdown content (such as tables), the content overflows horizontally in the side panel without a scrollbar, making it impossible to read the full content. ## Steps to reproduce 1. Open a work item with the `workplan` feature flag enabled 2. Open the work plan side panel 3. Add or generate a work plan that contains a markdown table 4. Observe that the table content overflows to the right and cannot be scrolled to ## Expected behavior Wide content (e.g. tables) should be contained within the side panel, either by wrapping or by enabling horizontal scrolling on the content area. ## Actual behavior The markdown content overflows the panel bounds horizontally with no way to scroll to the clipped content. {width=900 height=449} <details> <summary>Example Markdown to reproduce the issue in a workplan</summary> ```` ## Why Vue 2 is end-of-life and every page entrypoint under `app/assets/javascripts/pages` has to be moved to Vue 3 (`@vue/compat`) behind a feature flag before Vue 2 can be dropped. This issue covers the five GitLab Pages entrypoints owned by `group::planner intelligence`, rolled out through a single flag `vue3_migrate_pages`, as part of epic [&23090](https://gitlab.com/groups/gitlab-org/-/work_items/23090). The batch is small and self-contained: five CE-only entrypoints, no EE shadow directories, all already using the `vue3compat` app initializer. That makes it a good slice to land early, but two of the five have real Vue 3 compatibility risk that the current description understates (see key insights). ## What Five entrypoints, all confirmed present in `master`, none of them currently has a `vue3_migration.yml`: | Entry | File | Mounts | | --- | --- | --- | | `pages.projects.pages` | `app/assets/javascripts/pages/projects/pages/index.js` | `~/search_settings` | | `pages.projects.pages.new` | `app/assets/javascripts/pages/projects/pages/new/index.js` | `~/gitlab_pages/new` | | `pages.projects.pages.show` | `app/assets/javascripts/pages/projects/pages/show/index.js` | `~/gitlab_pages/show` | | `pages.projects.pages_domains.new` | `app/assets/javascripts/pages/projects/pages_domains/new/index.js` | `~/pages/projects/pages_domains/form` | | `pages.projects.pages_domains.show` | `app/assets/javascripts/pages/projects/pages_domains/show/index.js` | `~/pages/projects/pages_domains/form` | Deliverables: - `config/feature_flags/beta/vue3_migrate_pages.yml` (new). - Five `vue3_migration.yml` files with `status: rollout` and `feature_flag: vue3_migrate_pages`. - No EE files: `ee/app/assets/javascripts/pages/projects/pages` does not exist, so there is nothing to keep in sync. ### Key insights from code review - **The two `pages_domains` entrypoints are not the free win the description assumes.** Both `new/index.js` and `show/index.js` are byte-identical and call `initForm()` from `pages_domains/form.js`. That file does `sslToggle.$on('change', ...)` on the Vue instance returned by `initToggle`. Instance `$on`/`$off`/`$once` are **removed in Vue 3** and are explicitly called out in the migration guide. Verify whether the patched `@vue/compat` build still supports `INSTANCE_EVENT_EMITTER`; if not, refactor `form.js` to receive the change handler directly (or use `~/helpers/event_hub_factory`) instead of subscribing to the instance. Do this check first, because it decides whether this pair is a one-line change or a small refactor. - `~/toggles/index.js` also builds the toggle with `new Vue()` and a hand-written `render(h)` using the Vue 2 `props`/`on`/`attrs` object syntax, so it leans on compat render-function shims. Watch the console for compat warnings when the flag is on. - **`pages.projects.pages.new` is the highest-risk entry.** It goes `~/gitlab_pages/new` → `pages_pipeline_wizard.vue` → `~/pipeline_wizard`, which is a large stepper app, plus a `?raw` YAML template import, Apollo, and `GlToast`. Infection propagates downward, so enabling the flag moves the whole pipeline wizard subtree to Vue 3 on this page. Budget most of the verification time here. - `pages.projects.pages.show` mounts `edit.vue` and also instantiates the non-Vue `GlTabsBehavior` with `HISTORY_TYPE_HASH`. Tab switching and hash-based deep links need an explicit manual check. - `pages.projects.pages` mounts `~/search_settings`, which lazy-loads `./mount` through a dynamic `import()`. No other `search_settings` consumer has a `vue3_migration.yml` yet, so this is the first one under Vue 3. Confirm the Vue 3 infection propagates into that async chunk and that the chunk is emitted for the `.vue3` entry, not just for the Vue 2 entry. - Both `gitlab_pages` initializers already use `~/lib/utils/vue3compat/init_vue_app`, which is the expected pattern and reduces risk. ## How 1. **Pre-check the `$on` usage.** Run the `pages_domains` form under Vue 3 locally (`gdk config set vite.vue_version 3`, `gdk reconfigure`, `gdk restart`) and confirm whether the SSL toggle's `change` subscription still fires. Fix `form.js` first if it does not. 2. **Add the feature flag** `config/feature_flags/beta/vue3_migrate_pages.yml`, matching the shape of the sibling flags: ```yaml --- name: vue3_migrate_pages description: Enables Vue 3 in compatibility mode for the GitLab Pages pages ``` 3. **Add the five `vue3_migration.yml` files**, each next to its `index.js`: ```yaml status: rollout feature_flag: vue3_migrate_pages group: group::planner intelligence migration_issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/608113 ``` `group` and `migration_issue` are optional but useful; the schema lives in `config/helpers/vue3_migration_file_validation.js`. 4. **Restart Vite** (`gdk restart vite`). Vite builds its page entry map at startup and will not serve an entrypoint added while it was running. 5. **Verify both bundles build** — the original entry and its `.vue3` sibling — and that the five entries appear in `public/assets/webpack/vue3_migration.json`. 6. **Verify each page with the flag enabled.** For every entrypoint: console shows `[gitlab] [V] Using Vue.js 3 (with @vue/compat) for <app name>`, `document.querySelectorAll('[data-gitlab-vue3-app]')` returns the app, and no compat warnings. Functional checks: - Pages settings: settings search filters and highlights sections; `search_settings` async chunk loads. - New deployment: pipeline wizard steps forward and back, commits, `onDone` mutation runs, redirect happens. - Deployment detail: tabs switch, hash deep links restore the right tab, deployment list loads more, delete and restore mutations work. - New and edit custom domain: SSL toggle flips, dependent fields show/hide and enable/disable, hidden input value updates, form submits. 7. **Merge, then roll out.** Open a rollout issue and enable `vue3_migrate_pages` incrementally with the `user` actor. Monitor Sentry for the affected pages. 8. **Finish the migration.** Once the flag is enabled globally and has soaked, flip all five files to `status: migrated`, drop the `feature_flag` line, and remove the flag definition. Reference: [Vue 3 migration guide, Option 1](https://docs.gitlab.com/development/fe_guide/vue3_migration/#option-1-recommended-migrate-your-page-entrypoint-using-a-feature-flag-and-vue3_migrationyml). ## Open questions 1. **MR granularity.** Recommended default is three MRs so a regression on one page does not block the others: (a) flag definition plus the two `pages_domains` entries, (b) `pages.projects.pages`, (c) `pages.new` and `pages.show`. A single MR with all five is also viable since one flag gates them all. Not yet confirmed. 2. **`$on` fallout.** If compat does not support instance `$on`, the `form.js` refactor touches shared `~/toggles` consumers' expectations. Should that refactor land in this issue or as a separate prerequisite MR? 3. **Rollout ownership.** Who opens and drives the rollout issue and the flag enablement, and is that in scope here or tracked separately under the epic? 4. **Description drift.** The description references the parent epic as "Knowledge entrypoints" and mentions being "independent from the wiki batches", but the actual parent is [&23090 Vue 3 migration: Planner intelligence entrypoints](https://gitlab.com/groups/gitlab-org/-/work_items/23090). Confirm this is leftover template text before correcting it. ```` </details> ## Additional context This is behind the `workplan` feature flag (default off). The overflow is most noticeable with markdown tables but may affect other wide content like code blocks. ## Current design Hiii there! This isn't a real section. I'm testing something out with anchors here. Please ignore me, thank you! ## Solution Root cause: the workplan view renders markdown client-side with `marked` via `NonGfmMarkdown`, while the edit preview renders real GLFM — and the backend-rendered `contentHtml` (cached in object storage) is never queried by the frontend. Per the Markdown DRI's recommendation (https://gitlab.com/gitlab-org/gitlab/-/work_items/624088#note_3750007975), fix this at the root instead of patching overflow CSS: - Fetch `contentHtml` from GraphQL (query, subscription, and save mutation response) and write it to the Apollo cache. - Render it in the work plan view inside a `.md` container with `renderGFM`, replacing `NonGfmMarkdown`. This makes tables scrollable via GitLab's standard `MarkdownTable` treatment and unifies markdown rendering with the rest of GitLab. See the agent plan on this work item for the detailed implementation plan.