Issue metadata
Sign in to add a comment
|
Typing "<d" in the omnibox very slow with past inputs full of words starting with 'd' |
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Steps to reproduce the problem: 1. Type data: (which automatically completes for me - data:text/html,<!doctype html><input type=text>). 2. Select <input type=text>. 3. Type <div> instead. What is the expected behavior? I can keep typing. What went wrong? The browser hangs. I have not waited longer than a minute. Did this work before? Yes Chrome 51 maybe Chrome version: 52.0.2743.116 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 22.0 r0 I have a minidump, but since it may contain personal details, I cannot attach it. I plan to upload it to Google Drive later today (the corporate proxy blocks Google Drive for some reason) and you will be able to request access, but I can send it via e-mail to Chrome team members until then. This obviously does not reproduce everywhere. I have a different user profile in which this does not happen. I guess it is something in my typed query history. I tend to type data: URLs a lot (for quick reduced test cases for Chrome issue reports), they are sometimes a bit log.
,
Aug 28 2016
Does it hang on Canary?
,
Aug 28 2016
I do not have a canary available now. I will check it later today. Should I send the minidump?
,
Aug 28 2016
I'm not in a good position to make use of it right now.
,
Aug 28 2016
It does not reproduce on a different computer with a synchronized profile that should have the same (I guess not exactly the same) typed query history. When I type <d, it automatically completes to - data:text/html,<!doctype html><div style="border-image: repeating-linear-gradient(0deg, brown, orange 40%, red); border-image-slice: stretch; border-style: solid; border-width: 50px;">a</div>
,
Aug 29 2016
,
Aug 29 2016
Will it help if I also share the typed query history file?
,
Aug 30 2016
Hmm. The data in the minidump says the omnibox is trying to mark up an item in the dropdown that has at least 4817 characters. I don't know what the item is -- the debugger just says the test strings have been optimized away. Try putting <d into about:omnibox and see if that hangs; if not, hopefully it would say something useful here. Here's the stack if it helps anyone. chrome.dll!u_getUnicodeProperties_56(int c, int column) Line 524 C chrome.dll!uscript_getScript_56(int c, UErrorCode * pErrorCode) Line 560 C chrome.dll!gfx::`anonymous namespace'::GetScriptExtensions(int codepoint, UScriptCode * scripts) Line 84 C++ chrome.dll!gfx::`anonymous namespace'::ScriptSetIntersect(int codepoint, UScriptCode * result, unsigned int * result_size) Line 102 C++ chrome.dll!gfx::`anonymous namespace'::ScriptInterval(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & text, unsigned int start, unsigned int length, UScriptCode * script) Line 190 C++ > chrome.dll!gfx::RenderTextHarfBuzz::ItemizeTextToRuns(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & text, gfx::internal::TextRunList * run_list_out) Line 1293 C++ chrome.dll!gfx::RenderTextHarfBuzz::EnsureLayoutRunList() Line 1550 C++ chrome.dll!gfx::RenderTextHarfBuzz::GetDisplayText() Line 798 C++ chrome.dll!gfx::RenderTextHarfBuzz::GetGraphemeIterator() Line 1571 C++ chrome.dll!gfx::RenderTextHarfBuzz::IsValidCursorIndex(unsigned int index) Line 1062 C++ chrome.dll!gfx::RenderText::ApplyStyle(gfx::TextStyle style, bool value, const gfx::Range & range) Line 757 C++ chrome.dll!OmniboxResultView::CreateClassifiedRenderText(const std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > & text, const std::vector<AutocompleteMatch::ACMatchClassification,std::allocator<AutocompleteMatch::ACMatchClassification> > & classifications, bool force_dim) Line 476 C++ chrome.dll!OmniboxResultView::InitContentsRenderTextIfNecessary() Line 617 C++ chrome.dll!OmniboxResultView::OnPaint(gfx::Canvas * canvas) Line 680 C++ chrome.dll!views::View::Paint(const ui::PaintContext & parent_context) Line 851 C++ chrome.dll!views::View::PaintChildren(const ui::PaintContext & context) Line 1411 C++ chrome.dll!OmniboxPopupContentsView::PaintChildren(const ui::PaintContext & context) Line 479 C++ chrome.dll!views::View::Paint(const ui::PaintContext & parent_context) Line 855 C++ chrome.dll!views::View::PaintChildren(const ui::PaintContext & context) Line 1411 C++ chrome.dll!views::View::Paint(const ui::PaintContext & parent_context) Line 855 C++ chrome.dll!ui::Layer::PaintContentsToDisplayList(cc::ContentLayerClient::PaintingControlSetting painting_control) Line 749 C++ chrome.dll!cc::RecordingSource::UpdateAndExpandInvalidation(cc::ContentLayerClient * painter, cc::Region * invalidation, const gfx::Size & layer_size, int) Line 175 C++ chrome.dll!cc::PictureLayer::Update() Line 112 C++ chrome.dll!cc::LayerTreeHost::DoUpdateLayers(cc::Layer * root_layer) Line 1015 C++ chrome.dll!cc::SingleThreadProxy::DoBeginMainFrame(const cc::BeginFrameArgs & begin_frame_args) Line 813 C++ chrome.dll!cc::SingleThreadProxy::BeginMainFrame(const cc::BeginFrameArgs & begin_frame_args) Line 801 C++ chrome.dll!base::internal::Invoker<base::IndexSequence<0,1>,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall cc::SingleThreadProxy::*)(cc::BeginFrameArgs const &)>,void __cdecl(cc::SingleThreadProxy *,cc::BeginFrameArgs const &),base::WeakPtr<cc::SingleThreadProxy>,cc::BeginFrameArgs const &>,base::internal::InvokeHelper<1,void,base::internal::RunnableAdapter<void (__thiscall cc::SingleThreadProxy::*)(cc::BeginFrameArgs const &)> >,void __cdecl(void)>::Run(base::internal::BindStateBase * base) Line 362 C++ chrome.dll!base::debug::TaskAnnotator::RunTask(const char * pending_task, const base::PendingTask &) Line 51 C++ chrome.dll!base::MessageLoop::RunTask(const base::PendingTask & pending_task) Line 479 C++ chrome.dll!base::MessageLoop::DoWork() Line 605 C++ chrome.dll!base::MessagePumpForUI::DoRunLoop() Line 174 C++ chrome.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate) Line 56 C++ chrome.dll!base::RunLoop::Run() Line 36 C++ chrome.dll!ChromeBrowserMainParts::MainMessageLoopRun(int * result_code) Line 1908 C++ chrome.dll!content::BrowserMainLoop::RunMainMessageLoopParts() Line 974 C++ chrome.dll!content::BrowserMainRunnerImpl::Run() Line 155 C++ chrome.dll!content::BrowserMain(const content::MainFunctionParams & parameters) Line 46 C++ chrome.dll!content::RunNamedProcessTypeMain(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & process_type, const content::MainFunctionParams & main_function_params, content::ContentMainDelegate * delegate) Line 420 C++ chrome.dll!content::ContentMainRunnerImpl::Run() Line 787 C++ chrome.dll!content::ContentMain(const content::ContentMainParams & params) Line 20 C++ chrome.dll!ChromeMain(HINSTANCE__ * instance, sandbox::SandboxInterfaceInfo * sandbox_info) Line 87 C++ chrome.exe!MainDllLoader::Launch(HINSTANCE__ * instance) Line 186 C++ chrome.exe!wWinMain(HINSTANCE__ * instance, HINSTANCE__ * prev, wchar_t * __formal, int __formal) Line 264 C++
,
Aug 30 2016
It does not hang if I type just <d. I went to chrome:omnibox and here are the lengthy suggestions (yep, test cases) - data:text/html,<!doctype html><div style="column-count: 2">gfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jk</div> data:text/html,<!doctype html><div style="column-count: 3">gfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jkgfdgdfgdfgdf kg dfgkdf kg dfkg dfkg dfgjdfkg djfg dfjkgndfjgh dfjkg dfjkg dfjg dfjkgh jk</div>
,
Aug 30 2016
OK, I suspect (a) this is not a hang but just a very slow operation, and (b) it's unlikely to trip most people because it seems to require some pathological input. I'm going to remove the hang tag. You may want to capture a trace of this happening, especially if you can reproduce it on a clean profile, perhaps in a case that isn't so pathological (maybe put in test inputs that are only a fraction of the full length of those others?). This would make it clearer how to triage this, e.g. if the primary problem is HarfBuzz, RenderText, or the wrapping omnibox code.
,
Aug 30 2016
There are no special characters there (I filtered A-Z[\]^_`a-z) - > for (x of autocompleteSuggestion.contents) if (x.charCodeAt() > 122 || x.charCodeAt() < 65) console.log(x, x.charCodeAt()) : 58 / 47 , 44 < 60 ! 33 32 > 62 < 60 32 = 61 " 34 - 45 : 58 32 3 51 " 34 > 62 32 < 60 / 47 > 62
,
Aug 30 2016
Not sure why that's relevant? I don't believe I suggested there were special characters.
,
Aug 30 2016
I wrote this before you submitted your comment, but submitted the comment after you submitted yours (the page was open for a long time and I did not get a collision alert when I submitted it). I did not notice the e-mail notification. Blabla. Sorry. :) 1. Should going through 8000 characters take over a minute? It really looks like a hang... I have a Core i5 quad core 2.3 GHz CPU (and 8 GB of RAM and an SSD, if it matters. But a lousy Intel(R) HD Graphics 5500 GPU). 2. Should the omnibox block the entire browser (I have seen this happening when the computer is slow, a lot)?
,
Aug 30 2016
I cannot reproduce it using a clean profile with the same lengthy URLs.
,
Aug 30 2016
@13: No, clearly this shouldn't take so long, but we need to figure out what's actually taking a long time. The stack in question here is trying to draw the matches in the dropdown, that needs to happen on the UI thread. So blocking Chrome's UI thread (which makes the browser look unresponsive) is unavoidable. @14: OK, capturing a trace would be even more valuable then.
,
Aug 30 2016
How would I capture a trace? Do you mean using chrome:tracing? If so, since the browser is frozen, how can I finish the trace and save it?
,
Aug 30 2016
As I noted in comment 10, I don't believe this is a hang. I think this is just really slow. Like, longer than a minute slow. However, there was a change in Chrome 53 ( https://codereview.chromium.org/1819753003 ) that may make this dramatically faster, depending on precisely what the problem was. I would try making a copy of your profile and then running anything 53 or later (so beta/dev/canary or Chromium trunk) on that copy and seeing if you can reproduce. If this no longer hangs, then we can probably cross our fingers and hope that change fixed it.
,
Aug 30 2016
Can you run a profiler? e.g. in the past I've had success running VerySleepy
,
Aug 30 2016
I am trying chrome:tracing first - which tracing buckets should I tick? browser omnibox views dwrite ui Anything else? It has been four minutes and Chrome is still frozen. I have not killed it yet.
,
Aug 30 2016
It took it about five minutes. I hope the chosen buckets are useful - https://drive.google.com/file/d/0Bxwga4EKqxwPajVhZWpsWVcxNTg/view?usp=sharing
,
Aug 30 2016
Actually, nothing confidential about it, I think (I hope). Attached.
,
Mar 21 2017
Mark, want to glance at this trace?
,
Mar 21 2017
I see what looks like hundreds of consecutive calls to RenderTextHarfBuzz:EnsureLayoutRunList, all stemming from two calls to View:Paint. Precisely, the tree looks: Layer::PaintContentsToDisplayList -> View::Paint -> View::PaintChildren -> View::Paint -> View::PaintChildren and this last PaintChildren call has two View::Paint blocks, each of which has a bazillion calls to RenderTextHarfBuzz:EnsureLayoutRunList. Tagging with Blink->Fonts for the RenderTextHarfBuzz interaction. It's not clear to me whether this is a problem with Views making repeated calls to RenderTextHarfBuzz or if the problem is in RenderTextHarfBuzz itself. Maybe they can look closer? I think it's probably a bad loop (O(n^something) for this pathological input) instead of, say, O(n).
,
Mar 21 2017
+msw +tapted for render text stuff
,
Mar 21 2017
,
Mar 21 2017
Hmm, EnsureLayoutRunList should only be called once (or 2+ with a bug?) per RenderText instance paint, but a bazillion calls seems quite broken (Mark, can you tell if those are all on the same instance or different instances?). +CC Oshima, per your work on EnsureLayoutRunList / update_layout_run_list_. This may be the omnibox popup/dropdown highlighting many matches in the string (as N RenderText instances or N styles applied via RenderText::Apply*). I wonder if stubbing out styling in OmniboxResultView::CreateClassifiedRenderText or similar improves things. A reliable repro case would help with debugging. Since I'm not actively working in this area, it's unlikely that I'll pick up this bug myself. Most folks that have helped with RenderText more recently have also moved on to other work, afaik.
,
Mar 22 2017
I looked at RTHB performance in a mac_views_browser build on Mac. I've attached a CPU trace with the first test case in #c9. In a debug build, it's slow, but nothing would hang really. An analysis on Windows may give different results. For me, <2% of the time is spent under View::PaintChildren (1.5% in OmniboxResultView::OnPaint) When looking at just the Omnibox (omnibox dropdown rendered by RenderTextMac), we get: 32% in RenderText::GetContentWidth() (called via Textfield::DoInsertChar()->OnAfterUserAction()->..->OmniboxViewViews::GetTextWidth()) * 31% in a call to RenderTextHarfBuzz::EnsureLayoutRunList * 30% is multiple calls to RTHB::ShapeRunWithFont() called via RTHB::CompareFamily 32% in RenderText::GetUpdatedCursorBounds() (called via Textfield::DoInsertChar()->UpdateAfterChange()) * 30% in a call to RenderTextHarfBuzz::EnsureLayoutRunList/ShapeRunWithFont/hb_shape * 18% is multiple calls to SkPaint::getTextWidths called via hb_font_t::get_glyph_h_advance 25% in OmniboxController::StartAutocomplete() (called via Textfield::DoInsertChar()->OnAfterUserAction()->..->OmniboxViewViews::OnAfterPossibleChange()) * spread across all the various providers Switching the omnibox popup to RTHB didn't seem to change much (but also Instruments started behaving weird). It is possible to get multiple calls being made to ShapeRunWithFont, from the multiple `CompareFamily` invocations in RTHB::ShapeRun. But this didn't really explode on Mac. After adding some tracing I don't get any missing glyphs, so the first CompareFamily tends to bail out - maybe that's not happening on Windows. A missing glyph for a particular character could scan through a bunch of fonts and increase the time of that first 32% linearly in the number of fallback fonts. Looking at RTHB::ShapeRun, there's a couple of #if defined(OS_WIN) code blocks that invoke additional calls to CompareFamily https://cs.chromium.org/chromium/src/ui/gfx/render_text_harfbuzz.cc?q=RenderTextHarfBuzz::Shape+package:%5Echromium$&l=1487 Part of this is maybe https://codereview.chromium.org/1009533003 -> "Add Segoe UI and its set of linked fonts to the font back list on Windows." (there's more history in blame though). For more general performance, Karan looked at possible ways of prioritising fallback lists, but really I think the fix here is to do what Blink does and just cache every possible text run onto the gfx::FontList object itself (subject to some length limits). There are only so many words in a typical dictionary (or so many hostname segments). I guess that doesn't help data urls, but they shouldn't get edited all that often. But before we can do that, we need to prevent Chrome's UI code arbitrarily deriving new FontLists: they need to always come from ResourceBundle, or they won't be cached. I guess I'm sorta working on that :/
,
Mar 22 2017
Note that using Chrome 57, I cannot reproduce the issue anymore. It is a little slow, but nothing like five minutes. Around half a second, or a second. (However, I needed to re-feed the long URLs to the Omnibox, as it stopped remembering them, for obvious reasons) Interestingly, the first query I noted (the one that starts with "column-count: 2") is significantly slower than the second query (probably because it only highlights all of the "d" for the first query, it does not do that for the second query, which is weird, but fine). Unfortunately, I do not think I kept that profile. I created a task for storing it, but did not get to it... Sorry about that.
,
Mar 22 2017
re: RenderText caching Back when we were still on RenderTextUniscribe, I had a CL that to add a singleton cache for TextRuns - so that they could be shared even between different RenderText instances. The idea is even when RenderTexts are re-created (as is commonly done when for example text is drawn using the state-less Canvas::DrawString API - or as a result of calls to ElideString() which is also stateless), it could still benefit from the caching - since the cache will be keyed by font/style/text content. The idea was that TextRuns would refcounted and shared between RenderText instances (all done on UI thread so no locking needed). At the time we didn't go with this approach because this was before views::Label and friends actually held RenderText instances and we thought converting those would give us a lot of benefit already. However, I still think this generalized caching approach is a good idea - mainly because there's probably still lots of places that don't cache RenderText instances and there are distinct RenderText instances that draw the same content (e.g. BMB in two different windows that show the same bookmarks). There was also a concern of the memory use of such a cache, but the nice thing about an explicit cache like that is we can control that. It could even respond to memory pressure signals when memory is low and shrink appropriately.
,
Mar 22 2017
> Mark, can you tell if those are all on the same instance > or different instances? No, I can't tell.
,
Mar 22 2017
It's not 100% clear to me: * It sounds like we struggle to reproduce the original bug, but believe there is still potentially slowness here. Do we have repro cases that are definitely slower than we'd like? Can we get some? Then we can measure concrete benefits from changes. * tapted wants to cache things on FontList, which is apparently blocked on his ongoing typography work. asvitkine suggests caching as well, but it sounds like maybe in a different way/different place? How do these proposals overlap?
,
Mar 22 2017
Caching may help more generally, but a potential quick fix might be only highlighting the first N matches in omnibox results, or even truncating the strings shown (ellipsis eliding is done after shaping, so that may not help, not sure if fade eliding would help). Hopefully an automated [performance] test for either fix would show gains and guard against regressions.
,
Mar 27 2017
(removing Blink>Fonts as chrome UI does not use blink)
,
Jun 19 2017
tapted@, can you give a brief update on your caching work?
,
Jun 19 2017
I'm not actively working on it that specifically. It's a long-term vision just to collapse gfx::Font and blink::Font into the same class. blink::Font already has a cache. E.g. via its use of blink::CachingWordShaper which reaches into blink::Font::GetShapeCache(). We don't need two Font classes in Chrome. I am working on deploying RenderTextHarfbuzz more widely on Mac, so any changes there I'm making with this end goal in mind. Text rendering in blink:: code on Mac doesn't use CoreText/RenderTextMac for typesetting, so cutting out that dependency would be a first step.
,
Jun 20 2017
> It's a long-term vision just to collapse gfx::Font and > blink::Font into the same class. Is there a bug tracking this? I'd like to suggest that we mark this bug as blocked on that one. I have a general sense that this bug--the speed of drawing suggestions--isn't much of a problem, or at least not enough to try to do something until the fonts are collapsed into one class. Plus perhaps bug 712268 will tackle some of this slowness. If anyone on this bug objects to my putting this in the low-priority queue, awaiting those changes, please say something.
,
Jun 22 2017
> Is there a bug tracking this? no. (note I have no plans to work on this for a year or more which will be enough time for sheriffbot to start complaining).
,
Jul 24 2017
Marking as low-priority per comment #36. (Didn't hear any objections.)
,
Aug 14 2017
For later consumption: likely related to but probably a generalization of the rendering performance issues discussed in bug 267710 (which is likely mostly about eliding).
,
Jan 9 2018
The NextAction date has arrived: 2018-01-09
,
Jan 19 2018
,
Jan 8
The NextAction date has arrived: 2019-01-08
,
Jan 8
Punting again per comment #36. I don't think anything has changed here. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by phistuck@chromium.org
, Aug 28 2016Labels: Stability-Hang
Status: Untriaged (was: Unconfirmed)