On the function definition page, the lookup for the output type should have a higher z-index than the add labels button so it doesn't get cut-off.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | BUG REPORT | None | T344206 Special:MathStatus exception error on Wikifunctions | ||
| Resolved | Jdforrester-WMF | T342865 Post-creation work for wikifunctionswiki | |||
| Resolved | BTullis | T289316 Prepare and check storage layer for Wikifunctions.org (new public content wiki) | |||
| Resolved | Jdforrester-WMF | T275945 Create Wikifunctions.org | |||
| Resolved | Jdforrester-WMF | T299176 Phase Theta – Root task | |||
| Resolved | SDunlap | T294388 Run some full end-to-end browser integration tests on Beta Cluster Wikifunctions now it exists | |||
| Resolved | SDunlap | T276847 Write a suite of user experience end-to-end integration tests for WikiLambda in selenium/etc. sufficient for us to launch with | |||
| Resolved | Nik.xyz.in | T321934 E2E test for CUJ 3: Edit a function definition | |||
| Resolved | DVrandecic | T318933 CUJ 3: Edit a function definition | |||
| Resolved | AAlhazwani-WMF | T312121 The dropdown menu of the "output type" from the function definition page is hidden under another component |
Event Timeline
Comment Actions
Because we allow for scrolling of the Function Definition container (which is necessary for when multiple inputs are defined), when the Output drop-down is opened, it extends the height of the container and creates a scroll. I was unable to get the dropdown to overlay with Z-index's (with no scroll) whilst keeping the required scroll functionality for when there are multiple inputs that create an overflow. There may be a (potentially hacky) way of doing this, but currently the dropdown isn't *hidden* as you can scroll to it, so I don't know if someone else wants to take a go at triaging this further?
Comment Actions
Waiting on resolution of UX question in this Slack thread: https://wikimedia.slack.com/archives/C02Q5QXU95X/p1660044642469559?thread_ts=1660044539.936639&cid=C02Q5QXU95X
Comment Actions
While I think the fixed/sticky footer might bring more issues than benefits in the long run, a temporary solution might be to open the menu above (instead of below) when there isn't enough space. This is something that is also recommended by the Codex/Design System team.
Is this something feasible in your opinion @EWright-WMF? If yes, I could further explore this if necessary!
Comment Actions
@gengh in these type of situations how do you suggest to proceed? Do we keep the issue in beta/prod and wait on Codex, or do we add our own fix while we wait for Codex?
Comment Actions
@AAlhazwani-WMF considering that the lookup component for output field is always immediately above the footer, if displaying it on top were a trivial change (E.g. <15min task, change a parameter in the component instantiation) I would change it to your suggestion and get back to the normal behavior once T307030 is done. However, I don't think this can be done that easily with the current Lookup component. I have been looking in the Lookup documentation in here: https://doc.wikimedia.org/codex/v0.1.0-alpha.9/components/lookup.html and also the options of MenuConfig (please Anne correct me if I missed something!)
The task mentioned by @AnneT looks active and soon to be fixed, so I would just keep this stalled for now and keep an eye on the component progress.
@AnneT is there anyway we can support you with this?
Comment Actions
@gengh You're correct, there is currently no way to configure a menu in Lookup (or any other component that has a menu) to open up instead of down.
With T307030, I predict we will complete the work in two phases:
- Allow menus to extend past the lower edge of their container (this work is partially complete already)
- Allow menus to open up instead of down, if there isn't enough space below
I think the first phase will make your UX workable, and the second will make it ideal. Hopefully this will be sufficient for your needs!
Thanks for the offer of support! Once we have a solution to T307030 ready, it would be very helpful if you could test it within your application. I'll be sure to ping you here when that's ready for testing.
Comment Actions
We’re currently working on a global update for the publish component (see https://phabricator.wikimedia.org/T270304) and most probably we are going to remove the sticky footer from the function definition/editing flow. In that scenario we could also find a better solution for the “Add labels in another language” call to action, hence resolving this issue indirectly. @gengh how do you suggest to proceed? Do we keep this task open as long as we don’t complete the work on the publish component or can we close this?
Comment Actions
This task is anyway stalled: let's keep it that way till we have the issue solved in master. We can close it with confidence then :)
Thank you!!
Comment Actions
If I am right, the issue in WikiLambda should be fixed thanks to the patch for T320614 (which is merely a circumvent of the issue, I agree to say)
Comment Actions
Checked in wikifunctions.beta.wmflabs (e.g. https://wikifunctions.beta.wmflabs.org/w/index.php?title=Z10085&action=edit) - the issue seems to be fixed. Any additional work needs to be done for the issue?
