QWebEngineScripts do not run on new tabs sometimes

Sometimes userscripts don't run on pages even when they should. I'm sorry for being vague but I am not sure of the extent of the problem. We have been able to reproduce one case of the bug for sure, but I believe I have seen it during casual browsing in other situations so it requires further investigation.

As reported here, child tabs opened from javascript with repeated calls of window.open do not have userscripts running on them.

I have attached a script to reproduce the issue. It is a PyQt script but the logic is simple if someone wants to turn it into a C++ application. I will try if you insist but I have little enough knowledge of Qt that it took me a week just to get a tabbed browser in python. All it does is:

1. make a tabbed browser
2. allow javascript to open new windows
3. install a QWebEngineScript into the default profile that just sets document.title
4. in a new tab open a page that has a script on it which calls window.open(someOtherPage) twice
5. check the titles of those two new tabs and see if they have been set by the userscript (they should have been)
6. close the two new tabs and refresh the first tab
7. repeat step 5

I am using data: urls in the provided test script just so it is self contained but have also tried it with other schemes. I am not sure why the repetition is required when the reporter of the issue linked above didn't need to do that.

I am not in a position to investigate this further (my rig can't even build debug builds from dev) so hesitate to speculate on the cause but I did make a start on 5.9 and noticed that renderViewDestroyed is being called with 0 when a tab closes in the above test. Since it is called from OnDestroy I don't see how it makes sense for it to be passed a NULL but when it does get that as an arg it clears the list of global scripts. I am not sure what the relationship is between UserResourceControllers and RenderView (one-to-one, many-to-one) but when I put a if (renderView == globalScriptsIndex) return; check in there it seemed to make the problem go away, in my limited manual test (I didn't run the whole test suite...).