Input fields unresponsive in fullscreen mode
See original GitHub issueHello everybody,
Last year I integrated blockly into the Node-RED IOT framework. This works fine but our users have asked to be able to show the Blockly editor in full-screen mode. I have implemented that feature request in plain Javascript, and it works!
But the problem is that (only in fullscreen mode) the input fields don’t respond:
- When clicking on a dropdown, the dropdown doesn’t appear
- When clicking on a color picker, the picker doesn’t appear
- When clicking on an edit box, the text is not selected and you can not enter new characters
- …
In had this problem in my old Blockly version, but after installing the current version from the Github master branch it is still the same behaviour. So I assume it is in all Blockly versions…
To Reproduce
I used the following standard code snippet to goto fullscreen mode, when an expand button is clicked:
var blocklyArea = $("#node-red-contrib-blockly-expandable");
var blocklyFullScreenRequest = blocklyArea[0].requestFullscreen || blocklyArea[0].mozRequestFullScreen || blocklyArea[0].webkitRequestFullscreen || blocklyArea[0].msRequestFullScreen;
// Check whether the browser supports fullscreen
if (blocklyFullScreenRequest) {
// Expand the Blockly editor when the expand button has been clicked
expandblocklyAreaButton.click(function(e) {
// Make sure (on all browsers) that the blocklyArea DIV element has 100% AFTER it has become fullscreen
// If document.fullscreenElement is null then full-screen mode has been quitted...
blocklyArea.on('webkitfullscreenchange mozfullscreenchange msRequestFullscreen fullscreencha nge', function(e) {
if (document.fullscreenElement) {
// Make sure the blockly area fills the entire screen
document.fullscreenElement.style.height = "100%";
}
});
// Expand the blocklyArea element to fullscreen
blocklyFullScreenRequest.call(blocklyArea[0]);
})
}
- Show the Blockly editor in fullscreen mode.
- Try to enter a text in a text input field, or try to open a dropdown input.
- Nothing will happen …
Expected behavior
I expect in fullscreen mode that I can enter data into my blocks.
Desktop (please complete the following information):
- OS: Windows 10
- Browser Chrome, Firefox, Edge
Stack Traces
I don’t see any issues in my console log.
Additional context
Have spend some hours debugging the events of a colorpicker, but now I’m stuck …
Here is a demo animation for a color picker in normal (non-fullscreen) mode:
As you can see: the events (mouse, keydown, …) arrive nicely in Blockly. And as soon as the transform is executed, the color picker is displayed at the correct location.
But when we look at the demo for the same color picker in fullscreen mode:
You can see that the colorpicker is NOT displayed after executing the transform statement. However when I open the color picker (variable “f” in above code) in the console, it seems to have the correct structure (i.e. seems identical to one in normal mode):
This means the color picker has the correct html structure, but this html elements don’t become visible after the transform statement.
So I thought that the parent element perhaps would be wrong, but in both modes the console shows that variable “f” has the (Node-RED) body element as parent:
Which means that in both modes the color picker should become available in the body. Don’t know if that is a problem in fullscreen mode, since the body is perhaps displayed BELOW the blockly editor (so the body is invisible)???
When I let my program run, at the end the color picker html elements will be added to the DOM tree in normal mode:
But at the end in fullscreen mode, the color picker html table is not available anymore:
That might be the reason why the color picker is not visible? But I have no clue why this html table is not added in fullscreen mode…
Hopefully somebody can help me, because this is way too far into depth for me 😭
Thanks a lot !! Bart Butenaers
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (2 by maintainers)
Top GitHub Comments
This will be fixed in the upcoming release next week using:
run before the initial inject.
Hi Rachel (@rachel-fenichel), Sam (@samelhusseini), Thanks again! Bart