Mind taking a look at his, nzolghadr@? I see you recently changed this function.

mmoroz@ it seems that this is a similar issue as  issue 627454 . Isn't it? I'll try to build the master and see whether the issue is reproducible with this test case or not.

Yeah, looks pretty similar. I've just kicked "redo fixed" job to ensure that this is a valid bug.

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

nzolghadr: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The stack trace here (and also in  issue 627454 ) seem to show a jump from V8Element::setPointerCapture to PointerEventManager::setPointerCapture, i.e., not through Element.

The second params are clearly different in V8Element::setPointerCapture and Element::setPointerCapture (ExceptionState& vs Element*).

Any chance the repro is "fooling" the V8 "binding"?

I ran the test locally. It does not make any crash.
mmoroz@ there is a weird stack trace in this crash which is the same as the previous issue. A direct jump from 
0x7f7d98863800 in setPointerCaptureMethod out/Release/gen/blink/bindings/core/v8/V8Element.cpp:1046:11

to

0x7f7d9997ee70 in blink::PointerEventManager::setPointerCapture(int, blink::EventTarget*) third_party/WebKit/Source/core/input/PointerEventManager.cpp:810:9

While it should have gone through EventHandler.cpp. Could that be due to some optimization in the compile for the release builds or something? Because whatever the setPointerCapture function in PointerEventManager.cpp is using should have been initialized when creating an EventHandler object.

What happened to the re-run you triggered. Did it pass?

yukishiino@: could you please comment if the jump in the stack trace from
  V8Element::setPointerCapture
to
  PointerEventManager::setPointerCapture
(w/o going through Element::setPointerCapture) is at all a V8 optimization? If not, the repro might be fooling the V8 binding here.

mmoroz@ any update on this one? Can I close this if this is not reproducible?

nzolghadr@, I'm sorry for missing your question in c#11!

Metadata section of the report shows:
<...>
[2016-08-09 18:19:57] clusterfuzz-linux-0363: Progression task errored out: Known crash revision 407792 did not crash.
[2016-08-09 18:19:57] clusterfuzz-linux-0363: Progression task errored out: Test case appears to be flaky.
<...>

and the report is marked as non-reproducible. Let's close it. Thanks for the follow-up!

Oops, WontFix should be a better status.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot