[Bug and/or Feature Request] `FrontBrowserJavaScript` token evaluates constantly and can't be disabled while editing

[ar-km]

Overview:

When editing a macro, the FrontBrowserJavaScript token continues to evaluate regardless of whether the action that contains it is disabled or if Evaluate Condition Results (in the View menu) is off.

The only way to stop the evaluation is to stop editing the macro.

Steps to Reproduce

1. Add a Set Variable action (it could probably be a few different actions).

2. In the to field, insert the FrontBrowserJavaScript token.

   Using the default script is enough: %FrontBrowserJavaScript%document.forms[0].innerHTML%

   

(I'm currently using KM 11.0.3. But I originally found this in KM 10.)

Results

Go to your Front Browser, open the Inspector, go to the Console and watch the errors stream in and accumulate: TypeError: undefined is not an object (evaluating 'document.forms[0].innerHTML')

The TypeError is expected. The screenshot is showing how they're repeating (1 + 18 times in this case) as long as the macro is being edited.

Additionally:

• I've found the same results via Safari, Chrome, and Brave (to be expected) and via the sibling tokens SafariJavaScript and ChromeJavaScript.

• The performance of the system and Keyboard Maestro is degraded a little because the evaluation takes up CPU cycles (in my case that's a ~1-2% increase to KM and the KM Engine). But this is a known consequence of Evaluating Conditions:

  One Simple KM 10 Setting That Can Improve Performance - Tips & Tutorials - Keyboard Maestro Discourse

Expected

There should be some way to stop the repeated evaluation when using this token and editing a macro.

The most obvious (to me) and intuitive way would be that disabling the action would pause evaluation.

But I can also imagine it respecting the state of the Evaluate Condition Results View menu item.

I also thought about whether a UI element (like: (Click for result) in the If action) would help. But I assume that would be tricky because it would have to be placed in every action that could possibly use the FrontBrowserJavaScript token. And that sounds like a nightmare for a few different reasons.

[Airy]

Are you proposing a change to the KM Editor's behaviour?

I can see why the current behaviour is undesirable for you, and I can see you have some workaround ideas, but what would you consider to be the ideal behaviour for the KM Editor? Do you think perhaps there should be a new menu item on each actions cogwheel to override the global evaluation flag? That might be a solution.

[kevinb]

While the manual page for Tokens correctly states that "Tokens in Keyboard Maestro represent placeholders, that you enter during design time, for information that will be replaced in the text at run time", it does not state whether KM will keep polling for that information. On the face of it, there is no reason why it should, but I do wonder if there is a design decision here (perhaps affecting all tokens?) rather than a bug. I look forward to finding out!

[tiffle]

@kevinb

whether KM will keep polling for that information

The following discussion sheds a (dim) light on this:

Odd Behaviour of AppleScript Dictionary When KM Token in Use

This is really a post/question for @peternlewis... Two days ago I was using Script Debugger to examine the Finder AS dictionary when I noticed that every so often an additional KM dictionary would become available and then disappear - over and over again. I tracked it down to the use of the KM token %SafariTitle% and here is a screen recording of it happening: [2022-01-19_15-43-45 (1)] What you're looking at is this: On the right hand side is Script Debugger's display of AS dictionaries tha…

[ar-km]

@Airy

Are you proposing a change to the KM Editor's behaviour?

Yes.

@Airy

but what would you consider to be the ideal behaviour for the KM Editor?

There should be some way to stop the repeated evaluation while editing a macro that has an action that contains this token. Without this options there's:

1. A noticeable performance hit.

2. The browser's console accumulates whatever is output and can make it hard to distinguish the signal from the noise.

3. If the JS is performing some kind of interaction that changes the page's state (ex: Clicking a button), that will keep happening over and over again as you're editing the macro.

   The only way around this, while editing, is to delete the action containing the FrontBrowserJavaScript token.

@Airy

Do you think perhaps there should be a new menu item on each actions cogwheel to override the global evaluation flag? That might be a solution.

Agreed. That would be one way to do it.

Although that still runs into the issue I mentioned where it might be very difficult to add that option to all of the actions that could possible accept the FrontBrowserJavaScript token. But I don't know.

At least it wouldn't require the same kind of UI considerations as adding something like the (Click for result) button that the If action has.

@kevinb

it does not state whether KM will keep polling for that information.

Agreed.

In this case, it does keep polling.

I wonder what other tokens behave similarly.

@kevinb

On the face of it, there is no reason why it should

Well there are definitely times where I can appreciate the repeated evaluation while I'm working on that specific action. It's when I'm editing the other actions that it gets in the way.

@kevinb

but I do wonder if there is a design decision here (perhaps affecting all tokens?) rather than a bug. I look forward to finding out!

Good point. Me too.

[Airy]

@ar-km

@Airy

Do you think perhaps there should be a new menu item on each actions cogwheel to override the global evaluation flag? That might be a solution.

Agreed. That would be one way to do it.

Although that still runs into the issue I mentioned where it might be very difficult to add that option to all of the actions that could possible accept the FrontBrowserJavaScript token. But I don't know.

Let us know if you can think of any other way.

As I said, I was proposing that the flag be added to "all actions", not just the actions that "could possible accept the token."

[ar-km]

@Airy

As I said, I was proposing that the flag be added to "all actions", not just the actions that "could possible accept the token."

Ah. Sorry about the misunderstanding.

I guess that would do it too

Some items in the cog menu seem to be available for all actions. But other are action-specific.

For example the Set Variable to Text action has options for:

• Process Text Normally
• Process Text Tokens Only
• Process Nothing

While Set Variable to Calculation has none of those because the output is a calculation and not text.

This is why I didn't consider suggesting it as a globally available option.

[Airy]

@ar-km

This is why I didn't consider suggesting it as a globally available option.

Fair enough. I was simply suggesting a universal toggle because it seemed like the simplest quick fix. There may be other approaches. For example, there could be a new tab in the KM Editor Configuration that would list all 200 tokens (or just a few of them that really need this feature), each with a checkbox to allow users to disable that specific token from being evaluated in the editor. I don't think that's a better idea, but it's a valid idea.

[ar-km]

@Airy

For example, there could be a new tab in the KM Editor Configuration that would list all 200 tokens (or just a few of them that really need this feature), each with a checkbox to allow users to disable that specific token from being evaluated in the editor.

That's an interesting idea. There are pros/cons to the global (this idea) vs. specific (per/action) approach.

I don't want to be too prescriptive about the implementation since there's a lot I don't know re: the considerations @peternlewis has to take into account.

[peternlewis]

@ar-km

1. The only way around this, while editing, is to delete the action containing the FrontBrowserJavaScript token.

If you undisclosed the action, it will not be evaluated (since there is nothing to display).

While editing it, you could add a “typo” to the token (eg XFrontBrowserJavaScript).

I highly doubt I would add a list of 200 tokens with individually toggalable options for editor evaluation.

[ar-km]

@peternlewis

If you undisclosed the action, it will not be evaluated (since there is nothing to display).

While editing it, you could add a “typo” to the token (eg XFrontBrowserJavaScript).

Ah! These both work.

I like un-disclosing the best.

Thanks.