Browser Extension Development: Are Multiple waitForAnyElement Calls Really Necessary?

September 20, 2025 by esx_ai

While working on Weibo auto-fill features recently, someone asked me a good question: Why does your handleWeiboFill function call waitForAnyElement multiple times? It looks like you’re doing the same thing over and over.

That’s actually a pretty sharp observation! At first glance, it does seem like we’re calling the same function repeatedly. But when you dig into what each call is actually doing, you’ll see they’re all serving different purposes.

What Each Call Actually Does

First Call: Quick Check for Existing Editor


let editorResult = await waitForAnyElement(selectors, {
  visibleOnly: true,
  timeout: 15000
})

What’s happening here: Checking if the editor is already on the page (maybe the user was quick and already opened the post editor)

Why we do this: This is the fastest path - if the editor’s already there, we can start filling content right away without clicking any buttons

Second Call: Waiting After Button Click


editorResult = await waitForAnyElement(selectors, {
  visibleOnly: true,
  timeout: 5000
})

What’s happening here: After clicking the “Post Weibo” button, waiting for the editor to actually load onto the page

Why we do this: Just clicking the button isn’t enough - we need to make sure the editor is actually present before we can interact with it

Third Call: Fallback Search


editorResult = await waitForAnyElement(universalSelectors, {
  visibleOnly: true,
  timeout: 5000
})

What’s happening here: If the previous approaches didn’t work, try with more generic selectors

Why we do this: Weibo might redesign their interface at any time, changing class names and breaking our specific selectors. This gives us a backup plan.

Fourth Call: Verifying Editor Usability


const visible = await waitForAnyElement(selectors, {
  visibleOnly: true,
  timeout: 2000
})
if (!visible || !isVisibleStrict(editor)) {
  throw new Error("Weibo editor is not interactive")
}

What’s happening here: Even if the editor is on the page, it might be hidden or not yet activated - we need to confirm it’s actually usable

Why we do this: Many websites load DOM elements first but require user interaction to fully activate them. Missing this check often leads to failed fill operations.

Why One Call Isn’t Enough

While it might look like we’re calling the same function repeatedly, each call is checking for different things:

First: Is the editor already open?
Second: Did the editor load after our button click?
Third: Can we find the editor with fallback selectors?
Fourth: Is the editor actually interactive and usable?

The waitForAnyElement function is smart enough to handle both immediate returns for existing elements and waiting for async-loaded ones. Same function, completely different waiting targets.

If we only called it once, we’d miss important scenarios:

Newly loaded editors after user interactions
Editors that are present but hidden or inactive
Sites that change their markup and break our selectors

Making the Code Look Cleaner

The current approach makes the logic clear, but it does look a bit repetitive. Here are a couple of ways to clean it up:

Option 1: Wrap it in a State Machine


async function getEditorForWeibo() {
  // Fast path → Click button → Fallback → Verify usability
  // Handles all waiting logic internally
  return await findEditorWithRetry()
}

Then the calling code becomes much simpler:


const editor = await getEditorForWeibo()

Option 2: Enhance the Wait Function


// Add mode parameters to handle all scenarios in one call
await waitForAnyElement(selectors, {
  modes: ["exist", "interactive", "fallback"],
  timeout: 15000
})

Final Thoughts

Multiple waitForAnyElement calls aren’t just for show - each one serves a distinct purpose at different stages of the interaction. Browser extension development often requires this kind of thoroughness to handle all the edge cases and ensure reliability.

That said, there’s definitely room to make the code cleaner through better encapsulation. Personally, I prefer the state machine approach - it keeps the complex waiting logic hidden while providing a clean interface.

When you’re working on similar functionality, it’s worth taking a moment to consider whether your waiting logic covers all the possible scenarios. Sometimes that extra wait call can save you from a whole category of mysterious bugs.