1418049 - Content script interaction with history.pushState()

Status: NEW

(WebExtensions :: General, enhancement, P3)

Description

[Tomislav Jovanovic :zombie]

Use case:

1) Extensions has content script for "example.com/foo".
2) user opens "example.com" which does history.pushState("/foo")

result: content script not inserted.

What's worse, there is no in-content event for pushState(), so the extension can't have a content script for all of "example.com/*" and check the page url + listen for change events.

(supposedly, there is a spec proposal for this, which I'll link if I can figure out where to look for it)

Comment 1

[Tomislav Jovanovic :zombie]

Unfortunately, I don't see a great answer here.

We probably _could_ listen for history changes, and inject the content script once the page does pushState("/foo"), but what happens when it then does pushState("/bar")?  Do we *also* load scripts for "example.com/bar"?  What if they conflict and were not meant to work together?


The new history event and letting extensions sort it out themselves seems like the least bad option.

Comment 2

[Luca Greco [:rpl] [:luca] [:lgreco]]

I tend to agree, an extension should already be able to listen for history events using webNavigation.onHistoryStateUpdated
(and by combining this webNavigation event and the WebExtensions messaging API, the extension can ask its content script to do something in response)

Comment 3

[Rob Wu [:robwu]]

Bug 1323433 would offer a way to run a content script for in-page navigations (such as in this bug).

Note that because a page can call history.replaceState/pushState long after the page has loaded, the script is not guaranteed to run at the specified runAt execution point.

Comment 4

[Rob Wu [:robwu]]

Bug 1323433 was closed. The API that injects content scripts upon history changes has very little actual usage in Chrome: https://bugzilla.mozilla.org/show_bug.cgi?id=1323433#c16

Given that extensions can already detect history.pushState/replaceState changes (comment 2) and that a dedicated API with a similar purpose isn't being used in Chrome, do you think that we should still try to support this scenario, or mark the bug as WONTFIX?

Comment 5

[jay.somedon]

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #2)

I tend to agree, an extension should already be able to listen for history
events using webNavigation.onHistoryStateUpdated
(and by combining this webNavigation event and the WebExtensions messaging
API, the extension can ask its content script to do something in response)

Hi,

I tried your workaround, but it didn't work, not sure if I got anything wrong. I had this code:

browser.webNavigation.onHistoryStateUpdated.addListener(someFunction)

and the content script hangs on this line. If I comment it out the script runs fine.