What causes "创建键盘操作失败" in xpzouying/xiaohongshu-mcp?

Re-acquire the content element (getContentElement) before inputTags if the DOM may have re-rendered.

创建键盘操作失败

Error message

创建键盘操作失败

What it means

This error wraps a failure to create a KeyActions chain on the content editor element while inputTags tries to move the caret down 20 times (arrow-key navigation, likely to move past pasted content). KeyActions() fails when rod cannot start a keyboard action sequence on the element, typically because the element or its page is gone or the CDP input domain errored.

Source

Thrown at xiaohongshu/publish.go:697

				return elem, nil
			}
		}
	}

	return findTextboxByPlaceholder(page)
}

func inputTags(ctx context.Context, contentElem *rod.Element, tags []string) error {
	if len(tags) == 0 {
		return nil
	}

	time.Sleep(1 * time.Second)

	for i := 0; i < 20; i++ {
		ka, err := contentElem.KeyActions()
		if err != nil {
			return errors.Wrap(err, "创建键盘操作失败")
		}
		if err := ka.Type(input.ArrowDown).Do(); err != nil {
			return errors.Wrap(err, "按下方向键失败")
		}
		time.Sleep(10 * time.Millisecond)
	}

	ka, err := contentElem.KeyActions()
	if err != nil {
		return errors.Wrap(err, "创建键盘操作失败")
	}
	if err := ka.Press(input.Enter).Press(input.Enter).Do(); err != nil {
		return errors.Wrap(err, "按下回车键失败")
	}

	time.Sleep(1 * time.Second)

	for _, tag := range tags {

View on GitHub (pinned to 332d196854)

Solutions

Re-acquire the content element (getContentElement) before inputTags if the DOM may have re-rendered.
Ensure the page/browser stays open for the whole publish flow.
Retry the publish; stale handles are usually resolved by a fresh run.
Reduce fragile caret-navigation (e.g. click at end of content instead of 20 ArrowDown presses) if errors persist.

Example fix

// before
for i := 0; i < 20; i++ {
    ka, err := contentElem.KeyActions()
    if err != nil {
        return errors.Wrap(err, "创建键盘操作失败")
    }
    ...
}
// after
// refresh element handle before keyboard work
contentElem, err = getContentElement(contentElem.Page(), 10*time.Second)
if err != nil {
    return err
}
for i := 0; i < 20; i++ {
    ka, err := contentElem.KeyActions()
    ...

Defensive patterns

Strategy: retry

Validate before calling

// ensure the editor element is still attached/visible before keyboard work
if visible, _ := isElementVisible(contentElem); !visible {
    return errors.New("编辑器不可见，重新获取元素")
}

Try / catch

err := publisher.Publish(ctx, opts)
if err != nil && strings.Contains(err.Error(), "创建键盘操作失败") {
    // stale element handle: retry publish with a fresh page
    time.Sleep(2 * time.Second)
    err = publisher.Publish(ctx, opts)
}

Prevention

Re-acquire element handles after any DOM-affecting step
Avoid closing or navigating the tab during publish
Keep browser memory pressure low for long runs
Batch keyboard steps with minimal unnecessary KeyActions chains

When it happens

Trigger: submitPublish/submitPublishVideo call inputTags with tags; inside the 20-iteration ArrowDown loop, contentElem.KeyActions() returns an error — element detached, page closed, or browser session dead.

Common situations: Content editor re-rendered (tiptap update) invalidating the element handle; tab closed during publishing; browser crashed under memory pressure; long-running session where the element handle went stale.

Related errors

AI-assisted analysis of xpzouying/xiaohongshu-mcp@332d196854 (2026-09-05). Data as JSON: /api/errors/57433243d8676ecc. Report an issue: GitHub.