Note: the associated epic T214647 should be read first before taking on this task!
The Drawer hide event removes a few CSS classes from the Drawer’s DOM element, but it never removes the Drawer’s actual HTML, and it also doesn’t remove the CSS classes on the HTML element.
Steps to reproduce
Open a reference, close a reference. Open the web inspector.
Expected results
The reference drawer element should no longer exist in the DOM
Actual results
The reference is still in the DOM, just below the <body/> closing tag, but hidden.
This leads to bugs like T211691 where the .has-drawer class on the HTML element clashes with other classes.
However, One Does Not Simply remove a class from the HTML element. The Drawer features a fade-in and fade-out animation, and to preserve this animation, the element must be removed after the animation finishes. This means adding a timer to the hide method (which means we should also guard against multiple calls to that timer). A timer is also prone to breakage if the CSS animation duration changes. It should be determined if we can somehow keep the CSS animation duration and the duration of the timer in sync (maybe with window.getComputedStyle)?
Bonus round
The Drawer is animated with a .drawer-visible class on the HTML element. This can probably be replaced with a CSS animation on the drawer itself, which will be executed when the Drawer is appended to the DOM. A CSS class would still be required to reverse the animation before the element is detached from the DOM., but at least this effect would be contained entirely in a keyframe animation, instead of in opacity, display and transition css rules.
AC
- [ x] All Drawer html and CSS classes should be removed from the DOM after a drawer closes.
QA Steps
- ReferenceDrawer: Click on a reference. Close the reference. Is the Drawer element removed from the DOM? Doe s it still fade-in and out correctly
- Repeat for CTA Drawers: click the watch star while anonymously
- Repeat for RedLinkDrawer: Find a page with a red link. Click the red link.