Page MenuHomePhabricator

Mentor dashboard Personalized praise settings view - overlapping and misbehavior of the drop-down
Closed, ResolvedPublic2 Estimated Story PointsBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • In the mentor dashboard personalized praise module, click on the Settings icon to open the Settings view.
  • Try to make bigger or smaller the screen and see where the elements of the Settings view are placed.
  • Also, try to change the notifications frequency. Again, change the size of the screen to see how it behaves.

What happens?:

See this video:

  • The settings view of the new dashboard module is overlapping other elements of the screen.
  • In the notifications frequency drop-down, is not possible to view correctly all the options, depending on the size of the window you can see all of them, none of them or just a few of them.
  • Sometimes, the closing icon (x) is not working.

What should have happened instead?:

  • Settings view elements should not overlapped with other elements of the page, the closing icon should close the view and the notifications drop-down should show all the options, regardless screen size.

Other information (browser name/version, screenshots, etc.):

  • This is happening both in Vector 2022 and Legacy Vector.
  • It is also happening in mobile (see the video attached below).
  • Tested in Firefox (desktop) and Safari (mobile)

image.png (1×1 px, 178 KB)

Event Timeline

Urbanecm_WMF subscribed.

This seems to be a fairly significant issue, although it can be workarounded by the Cancel button (or clicking outside of the dialog). Moving to sprint.

In Vector 2022, lowering the z-index assigned to .vector-feature-zebra-design-disabled .mw-header "fixes" this in Vector, but the issue would be visible in other skins anyway. This also looks like a Codex issue rather than an issue in GrowthExperiments itself.

Seems to be caused within Codex (especially since a similar issue happens within Wikifunctions as well). Started a conversation in the talk-to-DST channel.

Related T337384: Label box optimizations

A given Dialog might appear deeply embedded inside a larger DOM structure (like a MediaWiki page). To prevent anything from colliding or overlapping, you can use Vue's built-in Teleport component to render a given component (in this case, Dialog) to another part of the page while otherwise keeping the Vue component hierarchy intact.

A basic approach would look like this:

<div class="my-feature">
    <button @click="open = true">Launch dialog</button>

    <teleport to="body">
        <cdx-dialog
	    v-model:open="open"
	    title="Save changes"
	    close-button-label="Close"
	    :primary-action="primaryAction"
	    :default-action="defaultAction"
	    @primary="onPrimaryAction"
	    @default="open = false"
        >
	    <p>Do you want to save your changes?</p>
        </cdx-dialog>
    </teleport>
</div>

You could also write <teleport to="#some-other-element">. Vue will append the dialog to the selected element when it renders.

Let's see if this solves the bug – if so we can update Codex documentation to make these directions prominent for on-wiki usage.

Change 944312 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Mentor dashboard: Prevent PersonalizedPraiseSettings from overflowing

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

Change 944313 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] [WIP] Mentor dashboard: Prevent the dialog from interfering with skin control items

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

Test wiki created on Patch demo by Martin Urbanec (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/c7e918185c/w

Test wiki created on Patch demo by Martin Urbanec (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/67c1542495/w

Thanks @egardner for the T341944#9059985 tips. It seems to be fairly tricky to get the dialog's div to a correct place – one needs to break out of mw-page-container for it to work, which means both OutputPage::addHtml and BeforePageDisplayHook don't work (in 944313, I resorted to SkinAfterBottomScriptsHook, which gets the div where I want it to be, but I feel like I'm abusing it for something other than it was originally intended for).

Even with the wrapping div in the correct place, the dialog seems to stop respecting certain styles that seem to be MediaWiki/skin provided (in addition to ignoring GrowthExperiments-provided CSS, which is understandable, as it appears elsewhere). This is understandable, given we're breaking out of the mw-page-container, but it's not desirable outcome as part of fixing this task. An example is the font-size of the text, including in button labels (which is something that I don't think we were overriding):

image.png (306×1 px, 34 KB)
image.png (306×946 px, 30 KB)
With patchWithout patch (testwiki wmf.20)

This difference is clearly caused by breaking out of the mw-page-container wrapping div, which exempts the dialog from styles introduced by MediaWiki/skin. This can be shown via the two patchdemos linked below and comparing the style differences in them (one has div inside mw-page-container, other one outside), see GIF attached below:

ZliS.gif (1×1 px, 1006 KB)

The patchdemos with the two patches I uploaded below are available here (login as Patch Demo / patchdemo1 and click the cog icon in top right, under Send praise) :


To conclude, I think even to regular dialog users (without the need to override default h2/h3/h4 behaviour as we do), the div at the end of <body> solution isn't likely to work well, because of the missing core-provided skins. Regardless of whether we end up using <teleport> when working with Codex dialogs, I think the dialog needs to be working when invoked within mw-page-container, or if that's not possible, a way to apply normal MediaWiki/skin-provided stylesheets for individual items outside of mw-page-container.

@egardner Do you please have any thoughts on those issues I ran into?

Thanks @Urbanecm_WMF for the detailed write-up and the patchdemo links. I don't have any immediate solution this time around, but I think you've provided enough information for DST to think about how we want Codex styles to interact with MediaWiki-provided ones in this case.

I think that both the initial bug (z-index mismatch) and the the problems with using teleport as a work-around come from the styles being applied by the vector-body class.

.vector-body applies a font-size: calc(1em * 0.875) to all of its descendants (including the Dialog). This changes both the font size as well as the overall width of the dialog. I think that if you re-apply this style to wherever the Dialog ends up teleporting to, you'll see something that more closely resembles what you want.

.vector-feature-zebra-design-disabled .vector-body seems to be the source of the z-index collision, because this rule applies the styles position:relative and z-index: 0. This z-index rule is causing the collision – if you disable it, the dialog works fine in it's original position.

.vector-body applies a font-size: calc(1em * 0.875) to all of its descendants (including the Dialog). This changes both the font size as well as the overall width of the dialog. I think that if you re-apply this style to wherever the Dialog ends up teleporting to, you'll see something that more closely resembles what you want.

I remember this from OOUI: we also added a div at the bottom of the body to put dialogs in (except I think we added it from JS, rather than in the HTML), and in Vector we also had to style that with font-size: 0.875em; to get the sizes of things to work correctly. Vector's approach to font sizes is strange: it sets the root font size to 16px, but then almost in every place where text could appear it's set to 14px, using various font-size: 0.875em; rules. Long-term, I hope this can be fixed in Vector as part of the font size changes the Web team is planning for this year.

.vector-feature-zebra-design-disabled .vector-body seems to be the source of the z-index collision, because this rule applies the styles position:relative and z-index: 0. This z-index rule is causing the collision – if you disable it, the dialog works fine in it's original position.

I think this rule probably originates from T40848 or a similar concern. For special pages it's probably not that important to prevent things in the "content" area from breaking out into the "interface" area because most special pages are more like interface than like content; but for user-generated content pages, it will continue to be necessary. Teleporting is probably the easiest solution.

I've filed an upstream bug about addressing this issue in Vector / MW core here: T343476

Boldly reopening, to make the bug trackable on Growth team's board. This bug is sort of resolvable separately (even if it introduces a workaround/hack). Making a subtask of T343476 instead.

Blocked on the parent (where a long term solution is to be determined).

The bug where some of the dropdown options are inaccessible is T344776. In the video taken on mobile, scrolling the dialog causes the dropdown menu to become detached from the dropdown; this is T344542.

So, this is somewhat fixed as part of the parent task. Now the interface looks terribly (see below), but it works in terms of overlapping. We need to update our styles to meet the new dialog location. It might be also needed to check other usages of cdx-dialog (atm, seems to be only Personalized praise) and update them.

image.png (1×1 px, 163 KB)

Now the interface looks terribly (see below)

Due to Phabricator permissions issues I can't see the screenshot :(

Now the interface looks terribly (see below)

Due to Phabricator permissions issues I can't see the screenshot :(

Should be fixed, apologies.

Yeah it looks like this is because headers and paragraphs are no longer getting styled by the skin because they're no longer inside .vector-body or whatever other class Vector uses to style them. We might want to fix this in Vector by styling the dialog container with the same styles.

KStoller-WMF lowered the priority of this task from High to Medium.Oct 11 2023, 8:51 PM
KStoller-WMF moved this task from Sprint 0 (Growth Team) to Backlog on the Growth-Team board.

Change #944312 abandoned by Urbanecm:

[mediawiki/extensions/GrowthExperiments@master] [WIP] NOT WORKING: Mentor dashboard: Prevent the dialog from interfering with skin

Reason:

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

Change #944313 abandoned by Urbanecm:

[mediawiki/extensions/GrowthExperiments@master] [WIP] WORKING, somehow: Mentor dashboard: Prevent the dialog from interfering with skin control items

Reason:

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

Urbanecm_WMF added a subscriber: Etonkovidova.

Hi @Zapipedia-WMF! FYI, this issue should be resolved since August 2023, when the Design Systems team fixed the Dialog to not misbehave. I just tested it locally, and the issue indeed does not seem to appear anymore. Would you mind taking a look as well?

@Etonkovidova Moving this to QA, as it should be already fixed (as part of T343476).

Etonkovidova closed this task as Resolved.EditedApr 7 2024, 5:40 PM
Etonkovidova claimed this task.

Checked in testwiki wmf. 25 - all seem to be fixed; checked the mobile too.

from the task description videotestwiki wmf.25
- The settings view of the new dashboard module is overlapping other elements of the screen.
Screen Shot 2024-04-07 at 9.50.36 AM.png (1×1 px, 582 KB)
✅ Fixed
Screen Shot 2024-04-07 at 10.10.40 AM.png (1×2 px, 367 KB)
- In the notifications frequency drop-down, is not possible to view correctly all the options, depending on the size of the window you can see all of them, none of them or just a few of them.
Screen Shot 2024-04-07 at 10.19.44 AM.png (922×816 px, 261 KB)
✅ Fixed - the drop-down menu option are always visible; if it's close to the bottom of the page, the menu's options will open up.
Screen Shot 2024-04-07 at 10.21.35 AM.png (1×1 px, 219 KB)
- Sometimes, the closing icon (x) is not working.✅ Fixed

Note: test wmf.25 displays the Settings dialog differently than beta cluster - the controls are displayed properly styled in betacluster :

test wmf.25 beta
Screen Shot 2024-04-07 at 10.33.07 AM.png (1×1 px, 192 KB)
Screen Shot 2024-04-07 at 10.33.15 AM.png (1×1 px, 226 KB)

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

https://patchdemo.wmflabs.org/wikis/c7e918185c/w/

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

https://patchdemo.wmflabs.org/wikis/67c1542495/w/