Menu Toggle Bug

When I click on Button (Icon) to toggle (show) a focus group, the toggle does not hide the group if I clicked again. The toggle only works if I move the mouse away from the button after the first click and then click again.

Now it makes sense to move the mouse away from the button because I presumably open the menu to click on an item inside it, but it’s still a bug because as a tester the toggle button should work without needing to move away from the button and it’s not user interface friendly to misbehave in that way.

So let me know if this bug is not already reported, I will report it. I have uploaded a screen recorder of the bug on YouTube for a demonstration of the bug.

Interesting enough, The stats button is working. You know why? Because in the conditional format, the icon is changed to another icon so there is no need to move the mouse button away.

I agree that this is undesired behavior, but it’s actually working as intended. The button isn’t a “toggle.” I’m imagining your workflow looks like, “When Button is clicked and focus group is not shown, show focus group.” You’ll have another workflow that says, “When Button is clicked and focus group is shown, hide focus group.”

The focus group has an automatic behavior that any click will hide it, but if you click on the thing that’s triggered to show it, you’re telling it to show again. If I understood a previous response from the team correctly, when you click the Button, the logic is saying, “Ok close this focus group because you clicked, but you clicked on the thing that is set to show it, so keep it shown instead.”

You can go ahead and file it as a bug, I’d be curious to see Bubble’s response and if it’s different than the previous thread I read on this topic.

1 Like

Thank you for your response Andrew, but let me be clear why I am sure it’s a bug on Bubble’s standards.

I wasted hours on this thinking that I am doing something wrong. In the workflow I used to do Show/Hide tricks using custom states and Terminate workflows until my hair was white. That’s because I used the toggle button before but it didn’t work for me.

Then I thought, why not read the Bubble Toggle reference manual to see what it says, here it is:
image

So as obvious, the element should not be visible if it’s already visible. Besides all that, why should more time be wasted using Show/Hide tricks doing just a simple function when the toggle can work good already? :slight_smile:

I am really not kidding when I tell you how much time I wasted on just making the menu work, thinking I am doing something wrong.

1 Like

I understand what you’re saying, but “focus group” has built-in functionality that we don’t really control. It behaves by its own rules, and I’d recommend filing a bug report to make sure we get the right response from the dev team.

Actually I also just had an idea to add one trick to the conditional format to change the ICON to the same icon if clicked, that way it will refresh and work as intended (as the STATS button in the video). But of course, doing workarounds to just do simple functions, doesn’t add good credibility or no-code writing to Bubble on the long run.

They haven’t responded to my previous bug, so I don’t want to confuse them with another one. Maybe if I get a response here, the bug may already be reported.

What I’m saying is that workflow doesn’t work, at least it has never worked for me. There are properties of a focus-group that we don’t get to control. If you can make it work as intended, I’d love to be wrong here.

Showing it works fine. It’s when you click on the same button to make it hide, that’s the part I’ve never been able to make work.

yeah it does work. will make an example

That quote is about element condition not a workflow. Post an example, that would be great. But also watch the video to understand what I mean.

I rebuild it, and found weird behavior. If you click the button to show it, then try to click the button again, the menu will not hide. If you click the button to show the menu, then move the mouse off the button, then click the button again, it WILL hide. That feels bugged to me.

Here’s the test page: https://testgroupfocus.bubbleapps.io/version-test?debug_mode=true
Here’s the editor: https://bubble.io/page?name=index&id=testgroupfocus&tab=tabs-1

2 Likes

That’s what I’ve been saying since the first post. Thanks for confirming. Please watch the video and notice the click sounds it is a very clear bug.

:white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark::white_check_mark:
i found a solution with just two workflows, 3 actions & 1state
light work,
Gfocus | Bubble Editor ,

5 Likes

The workarounds are great for short term. But imagine thousands of users logging in at the same time, how much processing power will be wasted on workflows just to open a menu.

1 Like

its the only way to do it. by design group focus doesnt work with toggle. it doesnt take up much processing power at all lol. “thanks beau youre so smart”

1 Like

I agree, @arto.eg, that it’s a bug.

However, I found a super-simple workaround. Extend the height of the Group Focus (GF) element and then shift the content down by the same amount. Then, set Offset top in the property editor to be negative that same amount. Make sure the GF is in the foreground (bring to front) so that it covers the trigger icon, and then simply add a click event to the GF which hides itself. (I made the GF element transparent yellow for illustration purposes in the image below.)

Works great for a typical mobile nav menu setup. :slightly_smiling_face:

EDIT: Of course, this assumes the GF in the final product will be completely transparent.

2 Likes

its not a bug lol… thats how group focus work, they cant be toggled.

It might not be a bug in the GF itself, but the behavior is certainly undesirable and annoying when used in a typical mobile menu scenario. One could argue that the icon click event which triggers the closing of the menu should not be propagated (and thereby cause the immediate re-open of the menu).

1 Like

nah klsdjfskd

1 Like

Technically, it’s not an icon click event, but an “outside the GF” click event. At any rate, perhaps it shouldn’t be propagated. It seems like that’s the issue.