Autoload should work on elements that get updated
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 10.5k
- Forks
- 564
- PR merge metrics
- No merged PRs in 30d
Description
Describe the bug
Currently the autoload behavior will work when a element matches or doesn't match your anchor string which is great but I believe there is something missing from here.
I think whats missing is a update part of this 🤔 At times I have my extension add elements to the Github UI. However Github does a lot of updating but doesn't necessary removes the anchor? This causes my connected wxt element to disappear and never come back.
I think this is whats happening
1. Github updates via websocket
2. This causes a Mutation event
3. `waitElement` gets triggered and checks to see if the element exists.
4. Elements exists still because update happened to fast
Soo because these updates happen to fast and were relying on selecting the element at time of event, its possible that the element already exists but has completely been overwritten.
Reproduction
I don't have a repo but I run something similar to this on my extension code
export default defineContentScript({
matches: ["https://github.com/*"],
cssInjectionMode: 'ui',
async main(ctx) {
const ui = createIntegratedUi(ctx, {
// May be different on public github, we use github enterprise
anchor: '[id^="pullrequest-"]:not(.is-comment-editing):not(.is-comment-loading) > .timeline-comment-header',
position: 'inline',
onMount(container) {
const wrapper = document.createElement('div');
container.append(wrapper);
const root = ReactDOM.createRoot(wrapper);
root.render(
<h2> my extension </h2>
);
return root;
},
onRemove(mounted) {
mounted?.unmount();
},
},
});
Steps to reproduce
- Load a PR page in github.com
- You should then see the my extension text right below the PR description header
- Edit the description title
- while editing header should go away, then after save you will see header come back
- Github websocket system fires and removes the element
System Info
System:
OS: macOS 15.7.1
CPU: (10) arm64 Apple M1 Max
Memory: 12.56 GB / 64.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 22.14.0 - /Users/lornelas/.nvm/versions/node/v22.14.0/bin/node
Yarn: 1.22.5 - /Users/lornelas/.nvm/versions/node/v20.18.0/bin/yarn
npm: 10.9.2 - /Users/lornelas/.nvm/versions/node/v22.14.0/bin/npm
Watchman: 2025.09.01.00 - /opt/homebrew/bin/watchman
Browsers:
Chrome: 142.0.7444.135
Safari: 18.6
Used Package Manager
npm
Validations
- Read the Contributing Guidelines.
- Read the docs.
- Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
- Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
- The provided reproduction is a minimal reproducible example of the bug.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the autoload behavior around waitElement and reproduce it with the provided createIntegratedUi example on a GitHub pull-request page. Verify the UI returns after GitHub updates an existing anchor element, including the edit-and-save sequence described in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- frontend, tooling, web-dev
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100