Itchyfantastico
commented
6 months ago Same issue here since a few weeks. It happens with Opera GX and with Brave Browser too.
Furthermore nothing happens if I click on the emote icon to the right.
Open Tai-Mai opened 6 months ago
Itchyfantastico
commented
6 months ago Same issue here since a few weeks. It happens with Opera GX and with Brave Browser too.
Furthermore nothing happens if I click on the emote icon to the right.
RYJASM
commented
6 months ago I have also been having this issue for a few weeks. Fullscreen chat is basically UN-useable for chatting. Colon auto complete doesn't work for emotes. Pressing enter adds a new line instead of sending the message. It's a broken mess.
RYJASM
commented
5 months ago The emote menu, emote autocomplete and messaging is still broken. Mac OS and Windows 11, Chrome latest versions on both.
krompus
commented
1 month ago Still unusable, Firefox and Chrome, Windows and Linux.
RYJASM
commented
1 month ago Can confirm. Full screen chat is still utterly broken.
SirStendec
commented
1 month ago I wanted to comment on this, since it's been open for a while.
This happened because of a change to the version of React. Previously, React was perfectly happy with letting me move a DOM node to a new parent element while maintaining its reactivity.
That no longer works, which is why pretty much everything ends up breaking.
To fix this, I need to either switch to a pure-CSS solution for making chat appear, which isn't feasible since it isn't within the fullscreen root. Alternatively, React has a portal system to allow you to re-render an element into another element. I have been experimenting with this, but something about the chat tree keeps breaking whenever I try.
Just haven't gotten it working yet, though not for lack of trying.
RYJASM
commented
1 month ago I wanted to comment on this, since it's been open for a while.
This happened because of a change to the version of React. Previously, React was perfectly happy with letting me move a DOM node to a new parent element while maintaining its reactivity.
That no longer works, which is why pretty much everything ends up breaking.
To fix this, I need to either switch to a pure-CSS solution for making chat appear, which isn't feasible since it isn't within the fullscreen root. Alternatively, React has a portal system to allow you to re-render an element into another element. I have been experimenting with this, but something about the chat tree keeps breaking whenever I try.
Just haven't gotten it working yet, though not for lack of trying.
Thank you for looking into this. If you could override the fullscreen button to use a different element, below is a proof of concept for that, minus dragging controls and probably some other clean up. I full screen the div containing both the main element (video) and right sidebar (chat) and apply some styles to overlay the right sidebar over the other layers.
<script>
// generic full screen handler
function fullScreen(element) {
if(element.requestFullScreen) {
element.requestFullScreen();
} else if(element.webkitRequestFullScreen ) {
element.webkitRequestFullScreen();
} else if(element.mozRequestFullScreen) {
element.mozRequestFullScreen();
}
}
// full screen the div containing both the video container and chat container
fullScreen(document.querySelector("div:has(> main)"));
</script>
<style>
// max top layer the divs that contain the right column, may not be needed, could need to be changed
:has(.right-column) {
z-index: 9000 !important;
}
// position the right column (chat) over the window area
// could position/size this using javascript applied inline style css variables for top/left, etc
.right-column {
position: fixed;
top: 200px !important;
left: calc(80% - 30rem);
right: auto !important;
height: 70rem !important;
max-height: 80%;
display: block;
}
// hide everything else
.side-nav,
.channel-root__info,
.channel-root__info--with-chat,
[data-a-target="top-nav-container"] {
display: none !important;
}
// make the video and video containers fill the window
.persistent-player,
.video-player__container--resize-calc {
position: fixed !important;
top: 0;
left: 0;
right: 0;
bottom: 0;
max-height: 100% !important;
max-width: 100% !important;
height: 100% !important;
width: 100% !important;
z-index: 5000 !important;
}
</style>I haven't looked into changing the fullscreenElement target yet, but that's probably not an awful approach. Just depends on how well I can convince the player that yes, it's really in fullscreen mode.
RYJASM
commented
1 month ago I haven't looked into changing the fullscreenElement target yet, but that's probably not an awful approach. Just depends on how well I can convince the player that yes, it's really in fullscreen mode.
Unless something else depends on knowing the player is fullscreen, you could just scope those rules by toggling a class on the html element when the overridden fullscreen function runs. Seems to work as if it's full screen with those rules.
Describe the bug This issue is really hard to describe but I hope this recording can give you a good enough idea.
Screencast_20240505_120318.webm
1234s andarsts are in the correct order. (arstis just the equivalent ofasdfon a Colemak keyboard layout). Then, when I go into fullscreen, notice how this gets messed up.1234s. As a result, it pauses the player when I press space, thinking I'm typing. I didn't capture it in this recording because it messes with the other glitch(es) I wanted to show.To reproduce I hope it's clear from the recording.
Expected behavior I expect input in FS Chat to behave the same as in a normal non-FS chat.
Environment
FFZ Logs (via FFZ Control Center > Home > Feedback >> Log):