I have a content script running on every page. It updates the html of the page, which seems to take more time on longer pages (the script walks the DOM a lot of times). On longer pages the script could take up to 10-20 seconds to finish, and it seems that when it takes too long chrome stops the script, because on these pages I see only a part of the page changed.
The weird part is that when I add several alerts somewhere in the code, dividing the runtime to several parts, the script runs perfectly fine and changes the entire page. However when the alert is removed, the script is again stopped prematurely, and only a part of the page gets changed.
My only conclusion is that chrome stops scripts that run too long, so my question is – is that true? And if so – what can be done about it? (besides using annoying pop-up alerts)
I have another theory, the script stops because somehow there is a conflict when simultaneous commands try to change the DOM. Does this make more sense?
More details about the architecture: The background page gets a message from the content script. This message includes a callback function (the function that actually changes the HTML). This function is then called from the background page several times, relative to the length of the page. If I insert an alert inside the callback function, every call is run without problems. If however I remove it, only the first call from the background page is made, and further calls don’t do anything (although the background page code keeps running).
I found out what was the problem. I was using the callback given by the message from the content script to the background html page. This callback can be run only once, because there is only one response allowed for each message send to the background page.
Some sort of bug in chrome causes many responses to work when I added an alert inside the callback function.
The problem was solved by breaking down the content of the message into several messages.