Debrief RTILA X: Issues Encountered and Workarounds in a Project

Bug Reports
1

1. type and keyboard Commands Not Recognized in a Specific Context (Facebook Lexical Editor)

Issue encountered:
Although the type and keyboard commands are native and recognized by RTILA X, they were ignored by the engine in our project, raising the warning [WARN] - Command: unknown command | Data: {"command":"type"} in the logs. This issue occurred in a very specific context: entering a multiline comment with emojis and mentions (@) inside Facebook’s rich text editor (Lexical), itself encapsulated in a popup (dialog) opened via JavaScript.

Faulty native commands:

  • type (parameters: text, selector, delay, clear)
  • keyboard (parameters: key, selector)

Context details and JSON structure used:
Commands were placed in the then block of an if condition. The selector targeted a complex Rich Text editor:
div[role='textbox'][contenteditable='true'][data-lexical-editor='true'] p.
The text to enter contained real (physical) line breaks, emojis (:four_leaf_clover:, :clapper_board:), and special characters.

Excerpt of failed JSON structure:

{
  "command": "type",
  "name": "type-comment-text",
  "params": {
    "selector": "div[role='dialog'][aria-labelledby] div[role='textbox'][contenteditable='true'][data-lexical-editor='true'][tabindex='0']:not([aria-hidden]) p",
    "text": "${ai_comment_text}",
    "delay": 50,
    "timeout": 15000,
    "clear": true
  }
}

It is possible that using RTILA variables (${ai_comment_text}) containing physical line breaks interpreted by AI, or the exact parameter structure, caused the RTILA parser to silently reject the command as “unknown”.

Workaround:
Replace with a run_script command using the underlying Playwright API (page.keyboard.type() and page.keyboard.press()). This works perfectly as Playwright sends real system events to the browser, which is necessary for Rich Text editors like Facebook’s, bypassing the native command parsing issue.

2. IF Conditions with type: "script" - state is not defined

Issue encountered:
When using an IF condition with type: "script", the state object (holding project variables) is not injected into the JavaScript evaluation context. The error state is not defined occurs, crashing the workflow. The “JS expression” field in the UI also remains empty when importing JSON.

Faulty native command:

  • if with condition.type = "script" and condition.script = "state.variables.ai_status === 'OK'"

Workaround:
Use the “DOM flag” technique. Instead of evaluating a JS variable directly in IF, use a preceding run_script that modifies the page DOM by adding an attribute data-ai-ok='true' on the <body> tag if the condition is met. Then use native IF with type: "element_visible" and selector body[data-ai-ok='true']. This is 100% reliable and circumvents the JS scope bug.

3. IF Conditions with type: "variable_contains" - Unsupported condition type

Issue encountered:
The condition type variable_contains, which logically checks if a variable contains a string, is not supported by the engine and causes a fatal error.

Faulty native command:

  • if with condition.type = "variable_contains"

Workaround:
Same technique as above: use the “DOM flag” with element_visible.

4. for_each Loops - Unstable Behavior with Empty else Block (to verify)

Issue encountered:
In a for_each loop, if an IF condition returns false (e.g., post already liked) and the else block is empty, the workflow sometimes seems to stop or does not properly continue to the next iteration.
(Note: The problem was also observed when using a misconfigured scroll_into_view command that caused loop bugs. Leaving the else empty seems to work sometimes but remains flaky.)

Native command to verify:

  • for_each with IF having empty else

Workaround:
Always put a harmless command in the else, like a 100ms wait, to ensure the engine processes moving to the next iteration correctly.

5. Line Breaks and Mentions in Facebook Comment Fields

Issue encountered:
Facebook uses the Lexical editor, which does not behave like a standard text field. Using document.execCommand('insertLineBreak') in DevTools or sending \n does not correctly trigger line breaks and breaks mention detection (@). For example, the second tag is not recognized if line breaks are not handled natively via keyboard input.

Faulty native command:

  • type with \n in the text

Workaround:
Use page.keyboard.press('Shift+Enter') followed by page.keyboard.press('Space') for line breaks, and type text line by line with page.keyboard.type(). For mentions, type the name, wait 500ms for the menu to appear, then press space to validate the mention turning blue. Sending real OS events via Playwright bypasses React/Lexical protections.

Summary for RTILA Support

  1. Analyze rejection of type and keyboard commands:
    Verify why engine returns unknown command when these commands use variables containing physical line breaks or target Rich Text editors (contenteditable). Ensure they send real keyboard events (like Playwright), not just execCommand.
  2. Fix IF conditions of type script:
    Inject the state object into JS scope so that state.variables.xxx works. Currently, it shows state is not defined.
  3. Add support for variable_contains:
    This condition type is very useful and expected.
  4. Check robustness of for_each with empty else:
    Ensure loops proceed properly to next iteration without crashing.
2

Hi Alexandre,

Thank you very much for your detailed report and sorry for the delay. We confirm its receipt and will take the time to review every point. We will get back to you with full feedback within the next two days.

Thanks again for your support we really appreciate it!

3

For your information, I built my entire project using the RTILA X AI agent in chat. It is with this agent that I requested the RTILA X debrief in order to correct the errors encountered. I am using the GLM 5.2 model via Openrouter.