[Bug]: Don't trigger element insertion when focused inside a text field / inside custom CSS

[jrmyfranck]

Contact Details

hello@jrmyfranck.com

What happened?

Currently, Structeezy shortcuts fire the corresponding insertions regardless of context.

While handy to quickly add elements to the page, it can trigger unwanted insertions.
It's especially problematic with the default shortcuts, when trying to add custom CSS to an element on a mac:

1. I'll focus in the custom CSS field
2. I'll type "%root%"
3. I'll then intend to open my code block by typing "{", but this requires me to press the "alt" and "(" keys (for context, the open parenthesis key (() is also the 5 key
4. Structeezy adds an <h5> element to the page

Potentially the same issues could occur when trying to type a "œ", "æ", etc., ie. in a text field

Version

v0.4.0

Version

v1.9.1.1

What browsers are you seeing the problem on?

No response

Relevant log output

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[cbontems]

Hello @jrmyfranck,

I confirm this behaviour with the defaults shortcuts. I'll look for a way to avoid triggering depending on the context.

In the mean time, maybe shortcuts like alt + h + 5 for headings instead of only alt + 5 could help even if they are more tricky to type ?

[jrmyfranck]

In the mean time, maybe shortcuts like alt + h + 5 for headings instead of only alt + 5 could help even if they are more tricky to type ?

That's what I ended up doing, and it does work as a workaround. However if Structeezy was context-aware that would obviously be better.

Not sure at all whether it is feasible, but I'm sharing this in case it's helpful at all:
Maybe by checking which element is currently focused, and preventing Structeezy functions if the focus is inside a Bricks field, a text field (on the page) or the custom CSS field?

[cbontems]

I think I have this one solved also. Feedback from users will tell if it is OK.

It was a bit tricky because Bricks uses <input> elements for the structure tree, therefore checking only for the active element type not being an input or textarea was not enough.

[cbontems]

Hello @jrmyfranck,

Did you have a chance to upgrade to the latest version and check if the problem is solved for you?

Thanks.

[jrmyfranck]

Hey @cbontems, haven't had the chance to thoroughly test it yet (been busy with non-Bricks related projects). I‘ll try to get to it during the weekend, and will report back.

[jrmyfranck]

@cbontems working now when editing text.

However, I noticed this behaviour when focused inside one of Bricks fields in the Styles panel (ie. when adding a class, or adding a value for a CSS property):

• A shortcut to insert an element will not fire.
• However, the shorcut to open/hide the panel still fires.

I don't know if that’s intentional (and I don’t necessarily think it's a bad thing), but I wanted to let you know.

[cbontems]

@jrmyfranck yes, I noticed this case too. They are different context, therefore not caught as the insertion one. I think it would be better to prevent shortcuts in all contexts, so I will change the behavior.