Removed relative positioning from scrollable chat area

[dshire]

There is a conflict in positioning relative to the parent container between the opened date picker and the "scroll-to-bottom"-button. This PR removes the relative positioning from the scrollable area that was introduced to position the scroll-button.

see here for how it should look (and looks with this fix):

This "fix" now leads to another issue: If the input area grows (due to long text in it) AND the scroll-button is visible, it will be displayed on top of the input area. see screenshot below.

Success criteria

• date picker is positioned correctly when open
• scrollable chat area working as expected (no double scroll bars, overflowing elements etc.)

How to test

Please describe the individual steps on how a peer can test your change.

1. deploy webchat with date picker
2. make sure there are enough message that chat area is scrolling
3. test for breaking display

Security

• Possible injection vector
• Authentication/Access controls touched
• Sensitive Data could be exposed
• XSS
• Logging/Monitoring touched
• Exchanges data with external systems
• No security implications

Additional considerations

• This PR might have performance implications

Documentation Considerations

These are hints for the documentation team to help write the docs.

[sushmi21]

The scroll button is also visible inside the persistent menu. Can we hide the scroll button when the persistent menu is open?

[dshire]

The scroll button is also visible inside the persistent menu. Can we hide the scroll button when the persistent menu is open?

how do I open the persistent menu?

[vj-venkatesan]

The scroll button is also visible inside the persistent menu. Can we hide the scroll button when the persistent menu is open?

how do I open the persistent menu?

you need to set it up in the endpoint editor .

It might be tricky to hide it I think , The logic to open the menu is in WebchatUI

[dshire]

Okay I see it. hiding the button is not the solution here, we need to position it relatively to the scrollable chat area again. Either by changing the date picker to position itself differently, e.g. using portal, or by constantly measuring the input area and positioning the scroll button with a calculation of this measurement. But we can't do either in a quick fix here

[sushmi21]

Okay, then we can merge this and see if we can find a better solution in a follow-up.

[sushmi21]

Rest looks fine

[dshire]

Okay, then we can merge this and see if we can find a better solution in a follow-up.

how about I quickly add a setting to disable this button? then it can be at least disabled from the endpoint in case there is issues

[dshire]

or even better, we hide it by default for now

[vj-venkatesan]

or even better, we hide it by default for now

You mean the scroll button ?
I think we can agree that this button overlapping is not as bad as the original issue. So internally in the team we agreed that is good , anything on top of this shall be done in a follow up in my opinion .

[dshire]

or even better, we hide it by default for now

You mean the scroll button ? I think we can agree that this button overlapping is not as bad as the original issue. So internally in the team we agreed that is good , anything on top of this shall be done in a follow up in my opinion .

ok then feel free to merge and proceed. otherwise please let me know