fix: avoid redundant page-favicon-updated events on setBounds#49464
fix: avoid redundant page-favicon-updated events on setBounds#49464codebytere merged 3 commits intoelectron:mainfrom
page-favicon-updated events on setBounds#49464Conversation
|
💖 Thanks for opening this pull request! 💖 Semantic PR titlesWe use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix. Examples of commit messages with semantic prefixes:
Commit signingThis repo enforces commit signatures for all incoming PRs. PR tipsThings that will help get your PR across the finish line:
We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can. |
page-favicon-updated events on setBounds
There was a problem hiding this comment.
Confirmed this corrects the issue. Please add a test here to validate the fix. You also need to sign your commit.
|
I wonder if this just works around an upstream issue that should really be fixed in Chromium. Why would |
There was a problem hiding this comment.
Hello @ANANYA542! It looks like this pull request touches one of our dependency or CI files, and per our contribution policy we do not accept these types of changes in PRs.
|
@ckerr , @codebytere Thanks for the reviews! |
|
@nikwen I tried looking into whether this should be handled upstream, but I couldn’t find a clear Chromium issue or documentation that explains exactly why DidUpdateFaviconURL fires on bounds/layout changes from what I could observe while testing locally, the callback was getting triggered even when the favicon URL itself didn’t actually change, but I don’t have a solid upstream reference yet that proves the root cause so for now I treated this more like an electron-side safeguard so app developers don’t get duplicate page-favicon-updated events I’m still pretty new to digging into Chromium internals and trying to understand how these observers propagate, so I might be missing some deeper context here if there’s an existing upstream issue or a better place to fix this, I’d definitely be happy to explore that direction too. |
|
I don't think you'd find an issue already filed upstream or any documentation on it. It would require reading the relevant Chromium code and debugging why the event fires multiple times. |
5fb281f to
906692a
Compare
codebytere
left a comment
There was a problem hiding this comment.
@ANANYA542 please rebase and remove yark.lock changes! We can then get this merged.
906692a to
198b23b
Compare
ckerr
left a comment
There was a problem hiding this comment.
@codebytere I've pushed up a rebase to e/e's main branch to resolve any remaining shear eg package.json & yarn.lock; should be ready for re-review
|
@ckerr Thanks for pushing the updates and rebasing! |
|
Congrats on merging your first pull request! 🎉🎉🎉 |
|
Release Notes Persisted
|
|
I have automatically backported this PR to "40-x-y", please check out #50084 |
|
I have automatically backported this PR to "41-x-y", please check out #50085 |
|
I have automatically backported this PR to "39-x-y", please check out #50086 |
Description of Change
Closes #49392
Fixes an issue where calling
setBoundson aWebContentsViewunintentionally triggers thepage-favicon-updatedevent even when the favicon has not actually changed.Currently, layout-related updates such as resizing or repositioning a
WebContentsViewcan cause redundant emissions ofpage-favicon-updated, which is unexpected and leads to duplicate callbacks in user code. This change ensures that the event is only emitted when there is a real change in the favicon data, preventing unnecessary and misleading notifications.This makes the
page-favicon-updatedevent more semantically correct and avoids side effects caused by purely visual or layout updates.Checklist
npm testpassesRelease Notes
Notes: Fixed an issue where calling
setBoundson aWebContentsViewcould trigger redundantpage-favicon-updatedevents even when the favicon had not changed.