In Storybook, don't set `wrapped` for reorderable lists and don't show the `wrapped` control
Categories
(Toolkit :: UI Widgets, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox149 | --- | fixed |
People
(Reporter: tgiles, Assigned: henmofb, Mentored)
References
Details
(Keywords: good-first-bug, Whiteboard: [recomp] [lang=js])
Attachments
(1 file)
In our moz-box-group.stories.mjs file, we want the wrapped control to be conditionally hidden if the box group is a reorderable list. Additionally the wrapped control should not affect the "Reorderable" story if it is somehow set.
To help Mozilla out with this bug, here's the steps:
- Comment here on the bug that you want to volunteer to help.
This will tell others that you're working on the next steps. - Download and build the Firefox source code
- If you have any problems, please ask on Element/Matrix in the
#introductionchannel. They're there to help you get started.
- If you have any problems, please ask on Element/Matrix in the
- Start working on this bug.
- You will need to update
moz-box-group.stories.mjsso that thewrappedargType does not show if thetypearg isreorderable. An example of something similar can be seen in panel-list.stories.mjs. - To prevent the
wrappedarg from affecting the reorderable list story, you may need modify the main Template to not call thewrappedTemplateif the type is reorderable.- There may be other ways to solve this issue, so feel free to explore alternatives!
- If you have any problems with this bug, please comment on this bug and set the needinfo flag for me by using the "Request information from" checkbox and setting the dropdown select to "mentor". Also, you can find me and my teammates on the
#reusable-componentschannel on Element/Matrix most hours of most days.
- You will need to update
- Build your change with
./mach buildand test your change with./mach storybook. Also check your changes for adherence to our style guidelines by using./mach lint -o -w all --fix. - Submit the patch (including an automated test, if applicable) for review. Mark me as a reviewer so I'll get an email to come look at your code.
- How to Submit a Patch
- This is when the bug will be assigned to you.
- After a series of reviews and changes to your patch, I'll push it to autoland.
- If there are changes requested, please read the "To update a submitted patch" section to ensure you don't accidentally create a duplicate revision!
- Your code will soon be shipping to Firefox users worldwide!
- ...now you get to think about what kind of bug you'd like to work on next.
Let me know what you're interested in and I can help you find your next contribution.
Updated•2 months ago
|
| Assignee | ||
Comment 1•2 months ago
|
||
Hey Tim,
I'd love to volunteer to help out with this bug!
This would be my first open source contribution, so needless to say I'm brand new to this process, but I have confidence that I can learn quickly.
I have downloaded and built the Firefox source code already on my machine.
I will begin to look more deeply into this bug after posting this comment.
Thank you,
Henry Yeary
| Assignee | ||
Comment 2•2 months ago
|
||
| Assignee | ||
Comment 3•2 months ago
|
||
Hey Tim,
I went ahead and submitted my patch to phabricator: https://phabricator.services.mozilla.com/D279478, but I forgot to set "r=tgiles" in my amended commit message.
My apologies for the omission, and I hope you are still able to give the patch a look when you have the chance.
Additionally, should I request level 1 commit access? I think that's the only way I can access Firefox's tests to run against, correct?
I also hope I took the right approach here with the changes I made, but if not, it's all a learning experience!
Updated•2 months ago
|
Updated•2 months ago
|
Updated•2 months ago
|
Comment 5•2 months ago
|
||
| bugherder | ||
Updated•1 month ago
|
Description
•