google chrome - Inconsistency with listeners - onUpdated on one machine and onReplaced on another machine

Question

I'm using the next code in my eventPage.js (backgroundPage replacement by google) and I'm facing some weird inconsistency. This is the scenario:

First Machine:

Opening new tab ->

onActivated 
onUpdated  
onUpdated  
onUpdated

Entering URL ->

onUpdated
onUpdated 

entering another URL ->

onUpdated
onUpdated 

Second Machine:

Opening new tab ->

onActivated

Entering URL

onReplaced
onActivated

entering another URL

onReplaced 
onActivated

---

This is my code:

chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab)
{   
    console.log("onUpdated");
       });

chrome.tabs.onActivated.addListener(function(tabId, changeInfo, tab)
{
    console.log("onActivated");
   });

 chrome.tabs.onReplaced.addListener(function(tabId, changeInfo, tab)
 {
    console.log("onReplaced");
   });

After a lot of debugging I've found that the cause of this difference is the option "Predict network actions to improve page load performance" in Google Chrome Settings.

In the first machine the option above is not selected and is working as expected.

Is that expected behavior for the second machine?

From the documentation I can somehow understand the onReplaced status:

Fired when a tab is replaced with another tab due to prerendering or instant.

Although it is very poorly documented and there's no way knowing that that option is somehow related to the onUpdated onReplaced statuses but I really don't understand the onActivated statuses in the second machine and why there's a difference between the first machine and the second machine.

I couldn't find any documentation about this behavior on the web. On stackoverflow I could hardly find one question that mentions the onReplaced listener but didn't had any info I can use.

Thanks

Answer 1

Having the "Predict network actions..." option checked, causes Chrome to try to predict your next action (i.e. what resource or page you are likely to request next) and load it in the background (before you make the request). As soon as you do actually request that resource or page, Chrome will not have to first load it and then serve it to you; rather it just serves the pre-loaded instance. This improves performance (as long as the prediction of your next actions is accurate).

To serve a pre-loaded page, Chrome replaces the current tab (that's when the onReplaced is triggered) with a tab that has the page already loaded in the background (the replacing tab becomes active, thus the onActivated event). Because the content has been loaded in the replacing tab beforehand, there is no onUpdated event.

---

From Chrome's whitepaper on prerender:

Prerendering extends the concept of prefetching. Instead of just downloading the top-level resource, it does all of the work necessary to show the page to the user—without actually showing it until the user clicks. Prerendering behaves similarly to if a user middle-clicked on a link on a page (opening it in a background tab) and then later switched to that tab. However, in prerendering, that “background tab” is totally hidden from the user, and when the user clicks, its contents are seamlessly swapped into the same tab the user was viewing. From the user’s perspective, the page simply loads much faster than before.

Web developers can trigger prerendering as described below. Beginning in Chrome 17, Chrome itself will initiate prerendering in some cases, based on the user's interactions with the address bar.