-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistency: How should tabs.onUpdated behave with the History API? #328
Comments
Filed https://bugs.webkit.org/show_bug.cgi?id=248177 for Safari/WebKit. |
I think Firefox's single "completed" event makes the most sense, because no loading is involved in |
I'm not sure if that's sufficient. As the OP mentioned, doing that may cause the extension to inject / perform work multiple times for a page. Maybe that's on the developer to implement a tracking mechanism? Tracking becomes a little harder due to ServiceWorker implementation and the inability to rely on cache variables (still haven't seen vendor solutions for this). |
|
You are correct that different browsers handle the history.pushState event differently, which can cause inconsistencies in how extensions behave when listening for browser.tabs.onUpdated events. To address this issue, you can check the changeInfo.url property of the browser.tabs.onUpdated event to determine if the page URL has changed. This property will be undefined for events that do not involve a URL change, such as when a page's title changes or when a page finishes loading. By checking the changeInfo.url property, you can ensure that your extension only injects code once per URL change, regardless of how the browser handles the history.pushState event. |
Try the following:
browser.tabs.onUpdated
listener.history.pushState({}, "", "/test")
.Currently:
I think an event makes sense because the tab has updated. However, it would be useful to identify this as a slightly different type of event, since extensions may otherwise accidentally inject multiple times on the same page if they are unaware of this edge case.
Related Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=106429
The text was updated successfully, but these errors were encountered: