move RHS forward when in tablet size
given that has an underlying problem, I'd suggest to revert as it might be a less problematic result until the proper fix is created.
also attached 's video of my attempt to fix for reference
QA Test Steps
opening the RHS and resizing the window should work as expected.
only on tablet size and with RHS expanded should it overlap
Tested and Passed. See comment on MM-33107.
Okay, so after taking a look, I don’t think a revert is really necessary.
Some contributing thoughts:
The auto-suggest is a more prominent feature than the expanded RHS
The root problem is actually that a number of our overlays are positioned next to their trigger elements in the DOM instead of being hoisted up to the top to be on top of everything
The CSS has previously accounted for increasing the RHS z-index for smaller screen widths, presumably for similar situations in the past. The challenge here is that this z-index increase was not updated when the post box’s z-index was, so they now have the same z-index and the post box is winning
Possible fixes (order of complexity):
Implement proper hoisting of all overlays within the webapp
Update the positioning of the auto-suggest to be aware of the RHS and prevent overlapping with it
Update the z-index of the RHS for the various screen widths as necessary
Probably #3 is out best bet at this point with #1 (and maybe combined with #2) being the longer term fix when the common components and layout overhaul projects are able to fix the general overlay challenges we currently have.
With that in mind, all we really need to do to accomodate #3 is update ‘sass/responsive/_tablet.scss’, line 464, to change it’s ‘z-index’ value from 12 to 13 to place it above the post textfield’s new z-index of 12. This could probably be added to the existing PR is currently working on.