New issue
Advanced search Search tips

Issue 673694 link

Starred by 0 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Dec 2017
Cc:
Components:
EstimatedDays: ----
NextAction: 2017-12-19
OS: All
Pri: 3
Type: Bug

Blocking:
issue 770046



Sign in to add a comment

(Non-MD) password settings + OOPIF = failure to update sometimes

Project Member Reported by vabr@chromium.org, Dec 13 2016

Issue description

Pre-requisites:
  + Save some passwords anywhere (e.g., on https://rsolomakhin.github.io/autofill/)
  + Activate OOPIF in chrome://flags/#enable-site-per-process
  + Choose "Continue where I left off" in about:settings

Repro steps:
  1. Start Chrome, open chrome://settings/passwords in a tab.
  2. Close Chrome.
  3. Start Chrome again.

Expected: chrome://settings/passwords loads and shows you the saved entries.

Actual: chrome://settings/passwords loads, but never finishes populating the "Saved passwords" list.

Note: This works fine with chrome://md-settings/passwords.


More details:

Without OOPIF, SessionRestore::RestoreSession() ultimately leads to options::PasswordManagerHandler::RegisterMessages() registering the "updatePasswordLists" message. Later, the JS (method didShowPage of chrome/browser/resources/options/password_manager.js) in the settings page uses this message to request obtaining credentials to be shown.

With OOPIF, the above RegisterMessages() call is done once more, shortly after session restore, with the following stack:
#1 0x7f90c1dc731f options::PasswordManagerHandler::RegisterMessages()
#2 0x7f90bddef673 content::WebUIImpl::AddMessageHandler()
#3 0x7f90c1dc6118 options::OptionsUI::AddOptionsPageUIHandler()
#4 0x7f90c1dc5e92 options::OptionsUI::OptionsUI()
#5 0x7f90c1d479cf (anonymous namespace)::NewWebUI<>()
#6 0x7f90bddebaa0 content::WebUIControllerFactoryRegistry::CreateWebUIControllerForURL()
#7 0x7f90bddc8704 content::WebContentsImpl::CreateWebUI()
#8 0x7f90bddd70bb content::WebContentsImpl::CreateWebUIForRenderFrameHost()
#9 0x7f90bdabd549 content::RenderFrameHostImpl::UpdatePendingWebUI()
#10 0x7f90bdac33c4 content::RenderFrameHostManager::UpdateStateForNavigate()
#11 0x7f90bdac2cbb content::RenderFrameHostManager::Navigate()
#12 0x7f90bdaa83dc content::NavigatorImpl::NavigateToEntry()
#13 0x7f90bdaa8ece content::NavigatorImpl::NavigateNewChildFrame()
#14 0x7f90bdab1099 content::RenderFrameHostImpl::OnOpenURL()
#15 0x7f90bdab0ecf _ZN3IPC8MessageTI25FrameHostMsg_OpenURL_MetaSt5tupleIJ27FrameHostMsg_OpenURL_ParamsEEvE8DispatchIN7content19RenderFrameHostImplES8_vMS8_FvRKS3_EEEbPKNS_7MessageEPT_PT0_PT1_T2_
#16 0x7f90bdaaefe2 content::RenderFrameHostImpl::OnMessageReceived()
#17 0x7f90bdca43fe content::RenderProcessHostImpl::OnMessageReceived()
#18 0x7f90bec25225 IPC::ChannelProxy::Context::OnDispatchMessage()
#19 0x7f90bec2875a _ZN4base8internal7InvokerINS0_9BindStateIMN3IPC12ChannelProxy7ContextEFvRKNS3_7MessageEEJ13scoped_refptrIS5_ES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#20 0x7f90c01cdfbe base::debug::TaskAnnotator::RunTask()
#21 0x7f90c01ff5bd base::MessageLoop::RunTask()
#22 0x7f90c01fff76 base::MessageLoop::DoWork()
#23 0x7f90c02022ba base::(anonymous namespace)::WorkSourceDispatch()
#24 0x7f90b9343e04 g_main_context_dispatch
#25 0x7f90b9344048 <unknown>
#26 0x7f90b93440ec g_main_context_iteration
#27 0x7f90c0202016 base::MessagePumpGlib::Run()
#28 0x7f90c01ff311 base::MessageLoop::RunHandler()
#29 0x7f90c0233774 base::RunLoop::Run()
#30 0x7f90c131afea ChromeBrowserMainParts::MainMessageLoopRun()
#31 0x7f90bd9919a9 content::BrowserMainLoop::RunMainMessageLoopParts()
#32 0x7f90bd99513f content::BrowserMainRunnerImpl::Run()
#33 0x7f90bd98caee content::BrowserMain()
#34 0x7f90be180477 content::RunNamedProcessTypeMain()
#35 0x7f90be180ef3 content::ContentMainRunnerImpl::Run()
#36 0x7f90be17f930 content::ContentMain()
#37 0x7f90c0c674a3 ChromeMain
#38 0x7f90b6949f45 __libc_start_main

For some reason, this results in the "updatePasswordLists" message not being handled any more. Reloading the page or navigating to it from scratch makes the page work again.
 

Comment 1 by vabr@chromium.org, Dec 13 2016

This could be up to 2 issues:
(1) The PasswordManagerHandler::RegisterMessages() not being idempotent, and
(2) the OOPIF code resulting in RenderFrameHostManager::Navigate() in the already session-restored frame.

I don't know enough about OOPIF to decide whether (2) is a bug.
It seems likely that (1) is a bug. However, given that it's somewhat rare to encounter, and no longer present in the MD settings, I don't think this is a high priority. For the passwords side, I'm happy to keep this open in case we see more reports of the bug until MD launches.

Comment 2 by kolos@chromium.org, Sep 29 2017

Blocking: 770046

Comment 3 by nasko@chromium.org, Dec 16 2017

NextAction: 2017-12-19
Given that chrome://settings/passwords is now MD by default, should this bug be closed?

Comment 4 by battre@chromium.org, Dec 18 2017

Status: WontFix (was: Available)
Yes, I don't see the signatures on crash anymore.
The NextAction date has arrived: 2017-12-19

Sign in to add a comment