Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Predator and CL could not provide any possible suspects.

Using Code Search for the file, "autocomplete_input.cc" suspecting the below Cl might have caused this issue

Suspect CL: https://chromium.googlesource.com/chromium/src/+/0b180e48e0c416729c0913bc41574a1c9b874306

krb@ -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

That CL was reverted in Feb. I would first suspect something along the lines of 542780.

Marking as Untriaged.  The triage engineer should look at the test case to identify the cause.

This got filed and auto-closed a couple other times in the past - seems flaky*

1) 
https://bugs.chromium.org/p/chromium/issues/detail?id=823305 / linux debug / ifratric_pdf_generic fuzzer (Justin had a couple notes)
CF: https://clusterfuzz.com/v2/testcase-detail/5281762859810816?noredirect=1
Gesture: ["mousemove_relative --sync,-48 108","key,Up Return Escape Escape","key,ctrl+w","mousemove,333 882","key,Tab Down Down Up Delete Right Tab B","key,ctrl+minus"]


2)
https://bugs.chromium.org/p/chromium/issues/detail?id=846006 / linux debug / inferno_flicker fuzzer (no notes)
CF: https://clusterfuzz.com/v2/testcase-detail/5716443501690880?noredirect=1
Gesture: ["key,ctrl+plus","key,Right BackSpace k Escape B Q BackSpace Up Tab","key,control+w","key,space q Left Tab Down space","key,ctrl+plus","mousemove_relative --sync,-13 177","key,F2","mousemove,747 445","mousedown,1","mousemove_relative,0 1","mousemove_relative,0 -","mousemove,1175 517","mouseup,1","key,ctrl+plus","key,ctrl+plus","type,'5LP\\I\\7P?8Xy#:G'","mousemove,1241 337","mousedown,1","mousemove_relative,0 1","mousemove_relative,0 -","mousemove,417 285","mouseup,1","mousemove,90 30","mousedown,1","mousemove_relative,0 1","mousemove_relative,0 -","mousemove,816 103","mouseup,1","mousemove --sync,7 332","mousemove,446 775","mousedown,1","mousemove_relative,0 1","mousemove_relative,0 -","mousemove,555 421","mouseup,1","mousemove_relative --sync,-86 86","key,ctrl+shift+space","Trigger:26"]


3)
Gesture for this new one is ["key,control+w","key,Up Up Tab Up Delete n Delete"]

all three go through  OmniboxEditModel::OnUpOrDownKeyPressed(int)  -> UpdatePopup() -> UpdateInput(bool, bool) -> StartAutocomplete(bool, bool)

the culprit CL range here doesn't look suspicious imo, and the fix rev ranges for the other two cases don't look like they directly fixed the issue.

But still there is some codepath that can trigger that CHECK.

There's a common pattern in the gestures where something is closed then keyboard inputs send up/down to the omnibox which matches the stacks:

[ctrl-w] followed by ["Up Up Tab Up Delete n Delete"]
[ctrl-w] followed by ["space q Left Tab Down space"] 
[ctrl-w] followed by ["Tab Down Down Up Delete Right Tab B"]

I'm seemingly able to repro locally, with the clusterfuzz tools running the test on a virtual desktop (default), both at this rev and tip of tree, so I haven't dug into that yet.

Curious how to get timing information from the gesture inputs, or to see what the interaction looks like. I'll look at the fuzzers and test cases some more.

Tentatively deprioritizing P1->P2 as we get closer to M70 branch, since this has come up and gone away before. Still leaving started and targeting M70.

Still at the same place as friday - can repro but the tooling runs on a virtual desktop so I need to figure out how to inspect the state around these gestures (ctrl+w closes which window? Is there more than one - there has to be, I think?)

ClusterFuzz has detected this issue as fixed in range 593772:593774.

Detailed report: https://clusterfuzz.com/testcase?key=4978818109145088

Fuzzer: attekett_surku_fuzzer
Job Type: linux_debug_chrome
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  cursor_position_ <= text.length() || cursor_position_ == base::string16::npos. T
  AutocompleteInput::Init
  AutocompleteInput::AutocompleteInput
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_debug_chrome&range=580376:580378
Fixed: https://clusterfuzz.com/revisions?job=linux_debug_chrome&range=593772:593774

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4978818109145088

Additional requirements: Requires Gestures

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 4978818109145088 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.