Is there any technical reason why the group focus element will close automatically when the user clicks outside of it? I’m curious if there is something inherent to a group focus element from a traditional coding perspective that makes them always close when clicked outside of it, or is that just something that Bubble implemented?
It is one of the most annoying things about using them and causes us to need to use so many hacky workarounds to keep them open when they need to be.
To me, a group focus closing when clicked outside of it is pretty logical. However, when you think about it, a group focus and a floating group is actually the same thing except for that a group focus “hugs” to a reference element and a floating group doesn’t.
My suggestion to bubble is to get rid of group focus all together. Keep floating group and add a checkbox called “float to a reference element group” or something like that. If it’s checked, they can expose another checkbox “close when clicked outside of it”.
To answer your question precisely, there’s no coding reason. They’re both elements with position:fixed or position:absolute, that’s all it is.
I wonder if I created a plugin called “Better Floating group” that did just that, would people use it?
That is a good idea. I just added to idea board to add checkbox to groupfoucs to not hide when clicked outside.
If there was a combination element as you suggest, that would be best.
Probably, especially as the group focus that is used for sub menus can only offset top and left (obviously can do things like negatives to go off bottom or right) but to be center aligned with its reference element, which may have a design that it’s width or position changes, and make it such that the groupfocus element will be able to have the width equal to the reference element.
I currently have to do these things with custom css or javascript and it is a pain.
BTW, any idea if there is any custom css that can stop the groupfocus from closing? I saw another thread with a suggestion that doesn’t work.
This works so long as the page width doesn’t change as the groupfocus will remain open, but it does not track the reference element as the reference element moves with the page width changes.
EDIT
This works so far as the page width doesn’t change quickly. The group focus will remain open and doesn’t close when clicked outside and tracks the reference element as the position shifts
One caveat to this is that the Bubble internal ‘is visible’ doesn’t work with it…what this means, is that when the custom CSS is applied and the groupfocus remains visible to the user on the screen, Bubble still interprets it as ‘invisible’ (can check debugger to confirm) which means any conditionals that reference the group focus is visible or is not visible will not work. To account for that, simply create a custom state that I call ‘is shown’ and use that instead of built in Bubble is visible/is not visible.
Personally, I don’t suggest using custom CSS if you don’t know CSS like the back of your hand. That’s because if it’s stops working, it’ll take you forever to figure out to fix it. I worked on projects where all I did was CSS the entire time, but even me I try to avoid it of possible.
Alright, well if people are down for a plugin like that I would make it
For sure people shouldn’t be implementing it if they can not understand the basics of what it does or how it is setup. For me personally, I don’t know it like the back of my hand, so the only times I implement it is when I need to work around Bubble limitations and there is a backup plan to just use the limited bubble native approach.
For this particular case, I’m keeping in the app the setup to keep the group focus visible via native Bubble features, which requires custom states and conditional workflow triggers and results in a bit of a visual ‘glitch’ when the group focus closes normally and the conditional trigger shows it again. Keeping this in place and then adding in the custom css, in case the custom css doesn’t work as hoped.
I’m looking forward to it. I’m sure a lot of others will be excited to utilize it as well.
I now use draggable groups nested in a floating group to replace pop ups, draggable menus and floating groups. A little bit of Javascript and/or CSS and i have complete control over my context menus and windows.
Edit: i meant replace groupfocus, not floating groups.
Is this simply to be able to drag them? Or does the javascript and/or CSS you use require them to be draggable. I ask because if I’m not interested in a draggable function, can the elements be just regular groups and not draggable groups.
I was having issues with the action to set focus on input when I use this code to keep the groupfocus always open. The HTML for keeping groupfocus open causes a problem with the set focus on input.
For me, it’s perfectly logical for the group focus to close when clicking outside of it.
But, there is a problem when debugging. If I try to run the debugger in step-by-step mode, as soon as I click “step-by-step” the group focus closes! It is impossible to troubleshoot with a group focus if I want to examine variables and workflow steps. I cannot interact with the elements in the group focus.
When using this approach, there are issues with visibility of other elements. Looking at the inspector, bubble shows them as not visible, since bubble code has the groupfocus as not visible, but due to the custom css the groupfocus is still visible (ie: open).
In order to account for this, on some elements I need to use the below css
visibility: collapse !important;
In order to have elements hide/show as I want (conditionally). For whatever reason, it works best to make it so the element is visible on page load, has collapse when hidden checked and to conditionally change the ID attribute so the above CSS will apply to the element to make it not visible. Conditional is based on when you want the element not visible.