(1) As described in  Issue 753238 , newly open tabs should be closed if we opened an app window. Also, (2) as described in  Issue 764607 , the newly opened app window should be focused.

To achieve (1) we need to close the source WebContents of the navigation. We can't do this synchronously as it could lead to UAF for the WebContents. We will have to post a task to close the WebContents. For (2), we will need to post a task to open the app window.

Ideally we would just post a task to close the webcontents and another one to open the application. But, there is no guarantee that the WebContents will still be alive by the time our task runs and similarly there is no guarantee that the profile (an argument necessary for opening the app), will be alive by then.

Deferring the navigation ensures both the WebContents and the Profile are still there by the time we run our tasks. We have to options to defer the navigation:

1. Re-add code to InterceptNavigationThrottle to perform the "should ignore" checks asynchronously.
2. Introduce our own NavigationThrottle which would defer navigations for empty tabs that open an application windows.

The benefit of 1. is that it's very easy to do. The downside is that we would run all of our checks in a task, thus introducing delays in navigations. 2. is more work and means having two separate Throttle for Apps, albeit two different types of apps. But it will post tasks only when required.
 

(1) As described in  Issue 753238 , newly open tabs should be closed if we opened an app window. Also, (2) as described in  Issue 764607 , the newly opened app window should be focused.

To achieve (1) we need to close the source WebContents of the navigation. We can't do this synchronously as it could lead to UAF for the WebContents. We will have to post a task to close the WebContents. For (2), we will need to post a task to open the app window.

Ideally we would just post a task to close the webcontents and another one to open the application. But, there is no guarantee that the WebContents will still be alive by the time our task runs and similarly there is no guarantee that the profile (an argument necessary for opening the app), will be alive by then.

Deferring the navigation ensures both the WebContents and the Profile are still there by the time we run our tasks. We have to options two defer the navigation:

1. Re-add code to InterceptNavigationThrottle to perform the "should ignore" checks asynchronously.
2. Introduce our own NavigationThrottle which would defer navigations for empty tabs that open an application windows.

The benefit of 1. is that it's very easy to do. The downside is that we would run all of our checks in a task, thus introducing delays in navigations. 2. is more work and means having two separate Throttle for Apps, albeit two different types of apps. But it will post tasks only when required.
 

(1) As described in  Issue 753238 , newly open tabs should be closed if we opened an app window. Also, (2) as described in  Issue 764607 , the newly opened app window should be focused.

To achieve (1) we need to close the source WebContents of the navigation. We can't do this synchronously as it could lead to UAF for the WebContents. We will have to post a task to close the WebContents. For (2), we will need to post a task to open the app window.

Ideally we would just post a task to close the webcontents and another one to open the application. But, there is no guarantee that the WebContents will still be alive by the time our task runs and similarly there is no guarantee that the profile (an argument necessary for opening the app), will be alive by then.

Deferring the navigation ensures both the WebContents and the Profile are still there by the time we run our tasks. We have two options to defer navigations:

1. Re-add code to InterceptNavigationThrottle to perform the "should ignore" checks asynchronously.
2. Introduce our own NavigationThrottle which would defer navigations for empty tabs that open an application windows.

The benefit of 1. is that it's very easy to do. The downside is that we would run all of our checks in a task, thus introducing delays in navigations. 2. is more work and means having two separate Throttle for Apps, albeit two different types of apps. But it will post tasks only when required.
 

(1) As described in  Issue 753238 , newly open tabs should be closed if we opened an app window. Also, (2) as described in  Issue 764607 , the newly opened app window should be focused.

To achieve (1) we need to close the source WebContents of the navigation. We can't do this synchronously as it could lead to UAF for the WebContents. We will have to post a task to close the WebContents. For (2), we will need to post a task to open the app window.

Ideally we would just post a task to close the webcontents and another one to open the application. But, there is no guarantee that the WebContents will still be alive by the time our task runs and similarly there is no guarantee that the profile (an argument necessary for opening the app), will be alive by then.

Deferring the navigation ensures both the WebContents and the Profile are still there by the time we run our tasks. We have two options to defer navigations:

1. Re-add code to InterceptNavigationThrottle to perform the "should ignore" checks asynchronously.
2. Introduce our own NavigationThrottle which would defer navigations for empty tabs that open an application windows.

The benefit of 1. is that it's very easy to do. The downside is that we would run all of our checks in a task, thus introducing delays in navigations. 2. is more work and means having two separate Throttle for Apps, albeit two different types of apps. But it will post tasks only when required.


For these reasons, we will introduce a new NavigationThrottle.