Open phonedude opened 10 years ago
Twitter may be changing the URI without actually "loading" a new page in the traditional sense but instead relying on an Ajax query to get the new content.
http://stackoverflow.com/questions/824349/modify-the-url-without-reloading-the-page
More info on manipulating the state of the browser without reloading using HTML5 and JS: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history
Getting closer. I can detect the change in URI from the history manipulation but unless I call the native push state function, this breaks Twitter's rewriting methods.
var pushState = history.pushState;
html = "var nativePushState = window.history.pushState; window.history.pushState = function(a,b,c) { alert(a); alert(b); alert(c);nativePushState(a,b,c);};";
var headID = document.getElementsByTagName("head")[0];
var newScript = document.createElement('script');
newScript.type = 'text/javascript';
newScript.innerHTML = html;
headID.appendChild(newScript);
A better solution, but the browser complains about an illegal invocation.
the content script:
var headID = document.getElementsByTagName("head")[0];
var newScript = document.createElement('script');
newScript.type = 'text/javascript';
newScript.src = chrome.extension.getURL('script.js');
headID.appendChild(newScript);
script.js:
(function(){
var nativePushState = window.history.pushState;
window.history.pushState = function(a,b,c) {
// Do something
console.log('foo');
nativePushState(a,b,c); //Continue by calling native history.pushState
};
})()
Maybe better, chrome now has a native implementation of this for extensions to use: https://developer.chrome.com/extensions/webNavigation
Verified as occurring on Facebook.com as well.
The reason this is not captured is due to the webrequest handlers' filter being limited to main_frame, which prevents requests for things other than the main page (e.g., images) from going through the same negotiation logic as the main page. The following code, when isolated into a separate bare-bones extension, was able to detect when a tweet was selected on the main page. The trick is to filter on the Ajax request type and not the main page but in the Mink implementation, this has to be done intelligently so as to not be invoked on every page on the web, simply the ones that 'change the URI programmatically'.
chrome.webRequest.onCompleted.addListener(function(deets){
console.log("onHeadersReceived()");
console.log(deets.url);
},
{urls: ["<all_urls>"],types: ["xmlhttprequest"]},["responseHeaders"]);
This might relate to #124. We also have the Twitter-specific URI filter to handle Ajax-based navigation but that seems ad hoc.
This also occurs on Google Maps when entering an address/place, note that Mink does not re-query the aggregator.
Still verifiably an issue, replicable by clicking on a username on Twitter.
Mink functions to some extent on Twitter but navigation within Twitter.com is not consistently caught and processed.
it shows 3 mementos
https://twitter.com/phonedude_mln/status/504381080460611584
and the 3 mementos display doesn't change. it's like it doesn't recognize that a new page has been loaded
I haven't been able to duplicate this on other sites but it happens when navigating within twitter.