Page MenuHomePhabricator

VE opens at full-width in Vector (2022) in some situations
Open, Needs TriagePublic8 Estimated Story Points

Description

Per T307725, the Visual Editor is meant to open within the constraints of Vector (2022)'s fixed width.

However, there are certain cases (see ===Behavior below) when people opening VE will see the editing interface span the full width of the browser window they opening it within.

This task involves the work with making it so, in the cases listed below, VE opens within the width constraint the Vector (2022) skin introduces.

Behavior

Meta

  • Skin: Vector (2022)
  • Editing Interfaces Impacted: Visual Editor + New Wikitext Editor
  • Browser width: >960px (I think this is the max width Vector (2022) sets)
  • Operating system(s): all
  • Relevant configuration variables: $wgVisualEditorUseSingleEditTab, $wgVisualEditorEnableWikitext
  • Relevant user preferences: visualeditor-tabs
Case #1: Navigating to VE by opening the edit link (that appears at the top of content page) in a new tab
  1. With the Vector (2022) skin setting enabled in Special:Preferences, visit any page where the visual editor is available. E.g. https://en.wikipedia.org/wiki/Maya_Angelou .
  2. Open the Edit this page in a new tab (e.g. on a Mac, while pressing the , click the Edit this page link that appear at the top of the page; or on Linux right-click the link and select Open link in New Tab).

Actual

  1. ❗️ Notice the Visual Editor opens at a width that surpasses the 960px width constraint width Vector (2022) sets

Expected

  1. ✅ Notice the Visual Editor opens at a width that is no wider than the 960px width constraint Vector (2022) sets
Case #2: Navigating to VE directly via URL
  1. With the Vector (2022) skin setting enabled in Special:Preferences, visit any page where the visual editor is available. E.g. https://en.wikipedia.org/wiki/Maya_Angelou .
  2. Open VE by going to the following URL https://en.wikipedia.org/w/index.php?title=Maya_Angelou&veaction=edit

Actual

  1. ❗️ Notice the Visual Editor opens at a width that surpasses the 960px width constraint width Vector (2022) sets

Expected

  1. ✅ Notice the Visual Editor opens at a width that is no wider than the 960px width constraint Vector (2022) sets
Case #3: Reload the page while the editor is open
  1. With the Vector (2022) skin setting enabled, visit a page and open VE.
  2. Reload the page you navigated to in "1."

Actual

  1. ❗️ Notice the Visual Editor opens at a width that surpasses the 960px width constraint width Vector (2022) sets

Expected

  1. ✅ Notice the Visual Editor opens at a width that is no wider than the 960px width constraint Vector (2022) sets
Case #4: Switch from wikitext to visual editing
  1. Open wikitext editor, e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Test?action=edit (it loads full-width)
  2. Use the dropdown at the end of the toolbar to switch to Visual editing
  3. Notice that the URL changes to contain ?action=edit&veswitched=1 and the page does not reload.
    • Actual: VE loads full-width
    • Expected: VE should load with a constrained width

Done

  • All "Expected" ===Behavior is implemented

References

Event Timeline

ppelberg updated the task description. (Show Details)

The web team's preferred options here are having a standardized way for Vector to know which editor is enabled for the current user without having to check VisualEditor specific functions. This would either be a function in core e.g. EditPage::getEditorName or having machine/user readable URLs as proposed in T309882. We are open to other ideas, but out of the solutions considered with @Samwilson these felt like the best options which wouldn't incur technical debt.

Are you seeing the described behaviour on enwiki, as the example links show? Nothing should've changed there yet! The bugs should be happening on Beta though, e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Test?veaction=edit

With Case #2: Navigating to VE directly via URL, I'm not sure the described behaviour is correct (as in, it's not the correct bug :-P). If navigating directly to veaction=edit, things work correctly. The problem is in the following situation:

  1. $wgVisualEditorUseSingleEditTab = true
  2. visualeditor-tabs preference is remember-last (and VE was last used) or prefer-ve
  3. go directly to the editing page at e.g. https://en.wikipedia.beta.wmflabs.org/wiki/test?action=edit
  4. VE will load in full-width

With Case #3: Reload the page while the editor is open, I think this is the same situation as Case #2, because it's effectively directly loading by URL.

There is an additional case as well, I think: switching from wikitext (wide) to visual (stays wide, incorrectly). I'll add this to the description.

This also affects the "Add topic" functionality (sorry I don't know if this has a special name). I am guessing it has the same underlying cause, but let me know if you want a separate bug.

  1. Go to https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk:ET11/Archive_1&action=edit
  2. Click "Add topic"

add_topic.png (793×1 px, 74 KB)

Thanks @dom_walden, that's a good one to remember. I think it might be the same as Case #2 above, in that it requires directly going to ?action=edit. Can you confirm that it doesn't happen if you first go to https://en.wikipedia.beta.wmflabs.org/wiki/Talk:ET11/Archive_1 and then click Add topic? In that case, it should load within the narrow view (because the page doesn't reload). It's only if you're already editing and then click Add topic that it ends up wide.

Thanks @dom_walden, that's a good one to remember. I think it might be the same as Case #2 above, in that it requires directly going to ?action=edit. Can you confirm that it doesn't happen if you first go to https://en.wikipedia.beta.wmflabs.org/wiki/Talk:ET11/Archive_1 and then click Add topic? In that case, it should load within the narrow view (because the page doesn't reload). It's only if you're already editing and then click Add topic that it ends up wide.

Yep, if I click "Add topic" first it is in narrow view.

KSiebert set the point value for this task to 8.Jun 29 2022, 2:51 PM

Thanks for cutting this ticket @ppelberg

Update for all subscribed parties:
We, Community Tech, are going to look into approaches for this work and look into breaking it down for each case.
We have slated it for Sprint 29 pending on complexity and other subtasks to break out. We will reach out for technical expertise where we have questions about how to proceed.

@NRodriguez Looking at the work being done for T319449, it seems like the reduced-width feature is in a state of flux and that we shouldn't work to fix this until that's all been sorted out. Does that sound okay?