Thank you for your post.
If you temporarily remove Base Elements plug-in, change the icon to a button, and then press the button, does this work with the button bar showing up?
Good idea...but unfortunately, no dice.
I removed the plugin, closed/opened FM, re-opened the file, verified that the Plugin wasn't shown in the Preferences, went to the layout in question. I manually entered in the value that drives the Hide Condition in order to show the button-bar that is otherwise hidden. Things worked fine for records that were not the current/active portal row record. But if the record is active before the button-bar is shown, I still had issues with the BB not responding.
I created a copy of the BB and removed the hide condition altogether. This BB also would periodically become non-responsive.
I did manage to narrow down the issue somewhat, though: it doesn't appear to be related to the active/non-active portal row, but is related to the LOCATION in the portal row that was clicked to make it active in the first place.
These portals are 95% covered by a container field that shows an image; this image container field is non-enterable in Browse mode. Behind each image are two more container objects (each is the same underlying field, though); they are arranged behind the image container in order to bisect the portal row into a 'top' and 'bottom' container; these two additional containers ARE enterable in Browse mode. When I click into a portal row on the top container, the button bar becomes non-responsive. If I click into the lower container (even in the same row) the BB becomes responsive again. I can click back and forth to toggle whatever the 'state' is, without changing rows, and the BB toggles responsiveness.
DOH! I think I just figured out what's happening. Since these background containers are enterable in Browse mode, when you click into one it becomes the in-focus object. This brings it to the front of everything and covers up the button-bar object - but the container has a transparent background, so you can't really tell that it's 'in front' of the button-bar. When I move the button bar down into the area covered by the lower container, it becomes covered/non-responsive when clicking on the lower container and not the top container.
Hmmm...so now I need to figure out how to allow them to click anywhere in the portal row but not have these containers become active - and yet still be acceptable as drag-n-drop targets. There's an AE calc on these containers that needs to fire, so that the script trigger also on these fields will operate. But it seems like I'll need a script trigger to de-focus the container when it's clicked on.
I added a trigger to the container for the 'onEnter' event. It's a simple script that just goes to another button on the portal row. And fortunately (but perhaps oddly) this trigger does NOT fire when you drop another container onto it, while the 'onModify' trigger DOES fire. I would think that they would both trigger, but they don't. That's OK, I kind of like it better this way - there are fewer events crossing over each other.