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

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

 Issue 796286  has been merged into this issue.

bokan@: https://chromium.googlesource.com/chromium/src/+/00710b48b6d06931a868dc6982b0daafd8875560 appears to have caused this regression. Calling Element::focus during layout results in script being executed by a focus event handler inside a ScriptForbiddenScope.

Taking a look today.

I reverted my patch. So focus can call script which isn't allowed. Does PerformPostLayoutTasks() necessarily need to be in a ScriptForbiddenScope or is that just incidental? I suppose if we shortened the scope to not include PerformPostLayoutTasks, we'd still have the problem since we might be in a nested layout and so script would still be forbidden.

Would it make sense to queue the focus event like we do for resize just below in PerformPostLayoutTasks()?

Queuing sounds reasonable to me, but I'm not that familiar with the best practices around script invocation.

Adam & Kentaro will be able to help

yukishiino: This is hitting the check added to BeforeCallEnteredCallback. I think someone is calling V8 APIs that may invoke an arbitrary script in a script-forbidden scope. Would you mind taking a look?

My patch was setting focus from layout which can call into an onfocus event listener. I've reverted the patch so there's nothing to do for this bug but I'd like to know how to fix this so I can reland. Many other events (e.g. resize) are enqueued and then dispatched at a predictable time in the lifecycle (just before rAF?). I'm wondering if this would be appropriate to do for onfocus as well?

ClusterFuzz has detected this issue as fixed in range 525740:525777.

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

Fuzzer: ochang_domfuzzer
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !ScriptForbiddenScope::IsScriptForbidden() in V8PerIsolateData.cpp
  [vdso]
  blink::BeforeCallEnteredCallback
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=524891:524927
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=525740:525777

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

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 4645869646512128 is verified as fixed, so closing issue as verified.

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

Re: #c12

+cc: haraken@ and tzik@

I think it's good to enqueue an onfocus event inside layout and to dispatch the onfocus event outside layout.  But I'm not an expert of task scheduling.

haraken@ and tzik@, do you have any concerns?

We should ask layout experts but in general it's wrong to dispatch an event while layout is on-going (because the dispatched event may trigger any arbitrary script). It makes sense to me to enqueue events that happen during layout.

@17: It is wrong to dispatch during layout, but I am not so sure about PerformPostLayoutTasks as the layout be finished by then...

@bokan: Do you have any idea why clusterfuzz marked this bug fixed?

Yes, I reverted the patch in  issue 795381 

I also wondered if maybe we could just reduce the scope of the script forbidden section to end before performing post layout tasks.