Omnichannel Livechat widget prevents body scrolling body

[billynoah]

Description:

When livechat widget loads a trigger message, the element gets inline css added by some javascript in /livechat/rocketchat-livechat.min.js anytime it is 480px wide or less:

overflow: hidden; height: 100%; width: 100%;

The javascript looks something like this:

s=document.body.style.cssText,document.body.style.cssText+="overflow: hidden; height: 100%; width: 100%;"

This css does not get removed even after the trigger messgae is closed which causes the body to become unscrollable on mobile devices.

Additionally, the trigger causes .rocketchat-widget to get the following inline css which effectively overlays the entire screen and makes it impossible to click anything:

position: fixed; width: 100%; height: 100%; max-height: 100vh; bottom: 0px; right: 0px; z-index: 12345; left: 0px;

Steps to reproduce:

1. Install livechat widget on a site per LIvechat installation script instructions
2. Add a "Trigger" under "Livechat Triggers"
3. Load a page on a mobile device or device with viewport width 480px or less
4. Once widget loads the trigger, body gets inline css overflow: hidden; height: 100%; width: 100%; which will not go away.

Expected behavior:

I'm not sure what the purpose of this inline CSS is, but at the very least it should disappear once the message is dismissed. Expected behaviour is the body element should be scrollable and the widget should not inject CSS which interferes with usability.

Actual behavior:

Body element becomes unscrollable as shown in screenshot below:

Server Setup Information:

• Version of Rocket.Chat Server: 3.18.3
• Operating System: Ubuntu 20.04.3 LTS
• Deployment Method: snap
• Number of Running Instances: 1
• DB Replicaset Oplog: ???
• NodeJS Version: v12.22.1
• MongoDB Version: 3.6.14 / wiredTiger (oplog Enabled)

Client Setup Information

• Desktop App or Browser Version: Desktop App
• Operating System: This bug is based on width of viewport in a broser / OS is irrelevant

Additional context

n/a

Relevant logs:

n/a

[billynoah]

This issue has come back as of v4.6.2