Thanks for bringing this to our attention.  The fiddle and SO post are helpful.  Right now, it seems that we don't let any keys through while dragging.  Since developers can prevent the default action of F8, I think we would need to explore a new UI feature to allow this.  Maybe some button like 'pause after 5 seconds'?

jjtusan@, could you please explain the use case behind this request?  In what scenarios would you want to debug while dragging, and when would debugging start?  Does the SO suggestion of using a setTimeout work for you?

Hello, 
What developers did you mean that can prevent default action of F8? Did you mean javascript or DevTools developers? I'm not sure if I understood you correctly, but if someone overwrites default action, it's his "fault". I don't think there is a need for new UI feature, old one would be enough if works as expected.

To describe my use case, I've been developing own library for dragging/sorting elements in forms. I've been adding/removing css classes to elements and moving elements based on mouse position. I had there some bug that I was unable to  catch using "debugger". I tried to set right conditions and run debugger only in certain situation, but I was unsuccessful. When I run debugger without any conditions in all situations, I was unable to actually debug my code because there are multiple dragging events fired every second. So, to sum it up, it would be easier if I could just drag the element and once I notice presence of the bug I would just hit the F8 and debug the current state of code.

About the other solutions, yes, setTimeout did work. I have updated jsFiddle to demonstrate it https://jsfiddle.net/buksy/53synm38/1/ .

But, what if I decide I want to add another functionality when user presses right mouse button (while dragging element and holding left button). I couldn't because I can't catch other mouse events while dragging (try to drag element and press right mouse, console.log message should be written, or try just to scroll page using mouse wheel, it doesn't work either).

The bug about not being able to catch other mouse events while dragging element is also present in FF 46.0.1 (You can test at this fiddle in FF https://jsfiddle.net/53synm38/2/ ). So this might not be a chromium bug, but OS bug. I can't test on Windows if it doesn't work there neither in both browsers.

According to the HTML5 drag-and-drop spec, all user input gets suppressed during a drag operation:

> From the moment that the user agent is to initiate the drag-and-drop operation, until the end of the drag-and-drop operation, device input events (e.g., mouse and keyboard events) must be suppressed.
http://w3c.github.io/html/editing.html#initiated

It's not clear if that includes OS- and app-level keyboard shortcuts. For example, Esc seems to work, but Ctrl+Q does not. Assuming app-level shortcuts can be captured, hitting F8 should be the proper way to trigger the debugger. If not, non-input based solutions (like setTimeout) will be the best we can offer, given the design of drag-and-drop.

Shouldn't the HTML dictate only browser behaviour regarding the DOM elements? (IMHO) User should have an option to override default functionality, and if developer tools are active, I'd expect suppressing functionality of drag&drop to be overriden by keyboard shortcuts of D. tools.

I've just worked on page where some DOM element was rendered over whole page on text drag by some script. I need to remove this behaviour, so the easiest solution would be to pause execution, inspect rendered element and find what script inserted it. Now I have to create button with timer to run debugger and just inspect the element.

Who decides whether OS & App level keyboard shortcuts should be suppressed or not? What will be next step regarding this "feature?" ?

I agree with you that we should be supporting this use case.  I did some investigating and found the place where we mark a KeyboardEvent as handled.
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/WebViewImpl.cpp?q=doingdraganddrop&sq=package:chromium&l=2153&dr=C

Blink's logic in WebViewImpl says to suppress events during drag and drop, so when the event is passed down the chain to the renderer host, it thinks the event has been consumed and doesn't pass it along to the DevTools window.

So it turns out it's not your OS or App's fault, but Blink.

Next steps are I'll continue to work on this.  If you have the time and would like to contribute a patch, we'd welcome that too!

For reference, I've modified your original fiddle for testing
https://jsfiddle.net/53synm38/3/

Possible approaches for reference:
- Try to let DevTools handle the event immediately from WebViewImpl::handleInputEvent() before the m_doingDragAndDrop check.  Somehow get the inspector's agent, check that it is attached, and forward the event to some handler that holds a list of whitelisted events.

- We can introduce a new value in the WebInputEventResult enum that distinguishes between events that are "suppressed" and those that are "suppressed_by_drag_and_drop", which lead to a new ack_result of "INPUT_EVENT_ACK_STATE_SUPPRESSED_BY_DRAG".  This ack_result will eventually get passed to render_widget_host_impl.  From there, we could modify the event so that Browser::HandleKeyboardEvent knows to let DevTools handle it, but nobody else.
https://cs.chromium.org/chromium/src/third_party/WebKit/public/platform/WebInputEventResult.h

Given the team's current priorities and resources, we won't realistically get around to this.  Archiving for now.

In 2017, we added some new Event Listener Breakpoints [1] for "drag", "dragstart", "dragend".  While these do not pause execution *while* dragging, they might be useful in pausing in the original scenario.

[1] https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints#event-listeners

Could you update the OS field in this ticket? This is not just linux issue. I've just tested and the bug is present on win 10 too.