+ Weifang FYI

To confirm, P3 is set correctly. Thanks!

>(1) Start long-tapping on a file in the list view mode.
(2) Click the button to switch to the view mode within 500[ms]. (you'd need to use mouse, as the cursor once disappears and track pad will not react until moving cursor for a moment).
(3) See if the file is dragged.

The repro steps were not clear to me.  Do you need to be finger tapping and be using a mouse? 

> This is a very edge case scenario, and its impact will be limited. However it'd be cleaner to cancel the tap handler's status (which memorizes the  elapsed time since starting touch, and the position, etc.) when such view change happened.

You are referring to somewhere in the code, I feel.  Where exactly are you referring to? 

> The repro steps were not clear to me.  Do you need to be finger tapping and be using a mouse? 
Yes, you need to use both finger tapping and a mouse click.

The point to be long-pressed in the window at (1) should be somewhere occupied by a file icon  after switching the view modes.
I've attached a video showing a repro case. (First attempt in the movie failed to repro it, because I clicked the button too late. The second trial is a success case.)
I used stylus pen in the movie, but exactly same thing happens with finger tapping.

"the tap handler" in the description refers this class.
https://chromium-review.googlesource.com/c/chromium/src/+/606068/22/ui/file_manager/file_manager/foreground/js/ui/file_tap_handler.js

Deleted: longpress-and-view-change.mp4 4.8 MB

	longpress-and-view-change.mp4 4.8 MB View Download

I am a new employee and I do not claim to be an expert on this code, but it seems to me that file_tap_handler.js does not have much to do with tap dragging files. I can delete the whole body of every function therein and still tap drag files. I can alter the tap dragging behavior by monkeying around with this source file instead:
src/ui/file_manager/file_manager/foreground/js/file_transfer_controller.js

Specifically, the tap dragging behavior seems to be determined by attachDragSource_ and the functions that it passes to addEventListener. The first line of code in attachDragSource_ simply sets the -webkit-user-drag CSS property to element, and it seems like that is all it takes to cause the behavior in question. If WebKit works this way, then should it be considered a bug in ChromeOS?