Issue metadata
Sign in to add a comment
|
(Non-MD) password settings + OOPIF = failure to update sometimes |
||||||||||||||||||||||
Issue descriptionPre-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.
,
Sep 29 2017
,
Dec 16 2017
Given that chrome://settings/passwords is now MD by default, should this bug be closed?
,
Dec 18 2017
Yes, I don't see the signatures on crash anymore.
,
Dec 19 2017
The NextAction date has arrived: 2017-12-19 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by vabr@chromium.org
, Dec 13 2016