Do you have a crash ID from chrome://crashes ?

Crash reporting is enabled but it does not show up as a crash in chrome://crashes. I let it crash several times and restarted Chrome several times as well.

Some more info on this: We have several places in our web app that use the same drag'n drop plugin and the app does not crash in those places. Our suspicion is that it has to do with the rendered waveform on those elements. They are rendered using two canvas elements.

Tried the issue on Mac retina and could not find the Edit spotlight option, though unable to reproduce the crash while dragging the image icons.Could you please review the attached screen cast and let us know if any.

Deleted: 634348_Aug_8.mp4 1.2 MB

	634348_Aug_8.mp4 1.2 MB View Download

@Durga As mentioned before, you need a special subscription for that feature. I provided you with a sub for a month and you should have the spotlight feature now. 👍

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Hi Jan -- if you still don't have a crash ID, could you give me a special subscription to debug this? Thanks! (cbiesinger either at chromium or google, whatever works better for you)

@cbiesinger Do you have a SoundCloud account with either of those email addresses? You can also send me your SoundCloud profile name via mail and I can add a subscription to it.

Thanks Jan.

So I tried to reproduce this bug.
Windows 10: Works (Chrome 54) (spotlight entry is blank while I drag it)
Mac 10.11.6: Works (Chrome 52 and 54 debug)  (spotlight entry is blank while I drag it)
Linux: Breaks the compositor (?), the whole screen fills with garbage. But after switching to a console and back the screen recovered. Tab did not crash. Chrome 54. Not a regression, happened already in r310003 (Jan 2015).


At any rate -- this does not seem to be a layout issue. Something paint/compositing related maybe. I'll hand this off to the related team. Hopefully, they can assist you.
(If any of you need a soundcloud password, feel free to ask me within the next month)

Also note: Generating the drag image (?) takes a few seconds, before which the page is not interactive. That's despite the image turning out to be blank. This is on all platforms I tested.

It seems like it crashes for me (Chrome Canary 54) also during the generation process of the drag image.

pdr@ was the last to look at DragImage, I think. Feel free to re-assign.

This is the craziest bug. I suspect we're crashing while drawing an accelerated canvas through the dragImage codepath.

We're going to try two things to narrow this down:
1) ericrk is going to see if he can get a dcheck to hit when reproing on windows.
2) I'm going to see if we dcheck on a retina mac.

Debugging on linux is difficult since it brings down my machine. Since this repros back to M51, it's unlikely to be my recent changes, but we still need to find the culprit.

(For me, on Linux, I could recover by switching to a console (Ctrl+Alt+F1) and back (Ctrl+F7), but yes that experience sucked. Remote debugging might help? But windows/mac might indeed be better :) )

Ericrk was able to find we're running over an IPC limit. We think this is likely a dupe of https://bugs.chromium.org/p/chromium/issues/detail?id=482383.

I've attached a minimized example. Soundcloud has "text-indent: -100000px;" on one of their buttons which causes us to try to allocate a massive drag image (~100000px x 36px). Increasing the size of the div or text-indent causes this to repro on non-retina machines.

We need to change LayoutObject::absoluteElementBoundingBoxRect() to take into account clipping. At a minimum, we should clip to the viewport. @chrishtr, is this something GeometryMapper can fix?



A second bug is that we crash when trying to send a massive image to the browser; this is  https://crbug.com/482383 .

Deleted: repro.html 351 bytes

repro.html 351 bytes View Download

@pdr: sorry for the absurdly slow response time.

How is absoluteElementBoundingBoxRect involved exactly? I just codesearched and
it doesn't seem that method is called at all in any code?

Hmm, we can probably remove absoluteElementBoundingBoxRect. absoluteBoundingBoxRectIncludingDescendants is the call now, it's called by LocalFrame when creating the drag image: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/LocalFrame.cpp?l=217