I would like to intercept location.reload(); via a Firefox API or by reading the JS on the page (remote & embedded) before it is loaded/executed or by any other means possible.
I have tried beforescriptexecute event listener (via GreaseMonkey & // @run-at document-start) but it is fired AFTER above is executed.
beforescriptexecute works nicely on REMOTE scripts since the event beforescriptexecute is fired before making the request (but then on the script src and not script content). It is different if the script is within normal script tag (and not remote), as per the example given. The beforescriptexecute fires and the script content can be rewritten but by then the window.setTimeout() has already fired and it is executing.
Another approach would be to verify whether a reload was initiated by the user (F5, refresh button etc in bowser scope) or via JavaScript on page-content scope.
I’m not sure what GreaseMonkey is doing but normally you would register an observer for the content-document-global-created notification. If you want to be E10S-compatible then you need to do this from a process script. If you register your beforescriptexecute handler from that notification then it should run before any page scripts get to run.
I’m mostly certain that Add-on SDK will do as well, via page-mod module with contentScriptWhen: "start". From what I remember, the Add-on SDK does exactly what I explain above.
Problem is, I don’t think any of the high-level APIs will give you sufficient information to recognize specifically location.reload() as opposed to assigning to location.href for example. Browser code will call nsIWebNavigation methods one way or another, the load flags here don’t have the necessary information however.
I was wrong, there is nsIDocShell.loadType. So you can check the following:
var docShell = window.QueryInterface(Ci.nsIInterfaceRequestor)
.getInterface(Ci.nsIWebNavigation)
.QueryInterface(Ci.nsIDocShell);
alert(docShell.loadType);
The lower 16 bits are load types, the upper 16 bits represent the load flags. This way you could indeed recognize reloads, both triggered by content and by the user. Problem is, I guess that the docShell info only changes after the load starts - onLocationChange will fire too early. Also, you would still need a way to recognize reloads triggered by the user, nsIWebNavigation.reload() doesn’t seem to care who called it. This will most likely mean observing Browser:Reload and context-reload elements in the browser document.
I setup a webprogress listener and onStateChange i abort the request on STATE_START and then on STATE_STOP I do webProgress.DOMWindow.location = 'what i want'.
So to ensure its a reload you would check for STATE_START and also LOCATION_CHANGE_SAME_DOCUMENT.