Don't call restoreTabs(false) on background thread
The TabState replacement CriticalPersistedTabData makes the assumption that it is called from the UI thread. This is not the case in for restoreTabs(false) which is explicitly called on the background thread and causes the new Tab persistence system to crash. After a deep dive, I determined that restoreTabs(false) is equivalent to loadNextTab() because all the code in restoreTabs is skipped except for loadNextTab() (since setActiveTab is false). After studying loadNextTab() I found that the 'heavy lifting code' (e.g saving, deletion) is explicitly called on the background thread so calling loadNextTab() or restoreTabs(false) from the background thread is not necessary. Calling loadNextTab or restoreTabs(false) from the UI thread will not cause a performance regression as the 'heavy lifting' code is already delegated to the background thread and in doing so will result in the correct consumption of CriticalPersistedTabData. Bug: 1148972 Change-Id: I15cfd90125039cf957b88148881765a59fda4556 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2548503Reviewed-by:David Trainor <dtrainor@chromium.org> Reviewed-by:
Mark Pearson <mpearson@chromium.org> Commit-Queue: David Maunder <davidjm@chromium.org> Cr-Commit-Position: refs/heads/master@{#829318}
Showing
Please register or sign in to comment