New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 784682 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

TabStats: is_auto_discardable is never set

Project Member Reported by michae...@chromium.org, Nov 14 2017

Issue description

The TabStats field |is_auto_discardable| is never set.[1]

TabManager::CompareTabStats() looks at that field first, so it's the most important from the tab importance perspective. When tabs are sorted by importance, non-auto-discardable tabs should be at the top of the list in chrome://discards. This is not the case. This can be tested by using an extension to prevent auto-discard for a tab and seeing that tab's location in the list at chrome://discards.

However, the corresponding |is_auto_discardable| field in TabManager::WebContentsData::Data *is* set, and that's the version used to check whether a tab can be discarded in TabManager::CanDiscardTab(). So this doesn't lead to a runtime issue: An extension can protect a tab via chrome.tabs.update(), and that tab will correctly be protected from auto-discarding.

Here are two possible fixes:

1. Set |is_auto_discardable| in TabManager::AddTabStats() using
   GetWebContentsData(contents)->IsAutoDiscardable().
2. Drop |is_auto_discardable| from TabStats and do not use it in
   TabManager::CompareTabStats(). It's already enforced via
   TabManager::CanDiscardTab().

As a general question, when should a field in TabManager::WebContentsData::Data have a copy in TabStats?

[1] https://cs.chromium.org/search/?q=is_auto_discardable&sq=package:chromium&type=cs
 
CompareTabStats() is also used in tab_manager_delegate_chromeos.cc to sort candidates for OOM process killing. I think the CanDiscardTab() check there still ensures that non-auto-discardable tabs cannot be discarded, but I'm not sure if there are any other possible effects to sorting candidate tabs incorrectly there.
Cc: chrisha@chromium.org fdoray@chromium.org
+chrisha@ and fdoray@ 

This field has been added in https://codereview.chromium.org/2167843004/ , there's a similar field in the TabManager::WebContentsData::Data class that seems to be used but this one seems to always be set to true.

Chris/François: Any idea why we don't set this flag? 

Comment 4 by fdoray@chromium.org, Nov 14 2017

* The field in TabManager::WebContentsData can be set by an extension and is used in TabManager::CanDiscardTab(). The field in TabStats is indeed useless. I'm removing TabStats as part of the TabManager refactor.
Status: WontFix (was: Untriaged)
As Francois points out, TabStats is disappearing. And yes, the field can only be modified via the extension API. Finally, the new chrome://discards page will surface this data.

Let's mark this WontFix, as the ongoing refactor is removing the offending class.

Sign in to add a comment