orinj@, I know you're familiar with this area, so reassigning to you.  I doubt droger's change is the cause.  (But it doesn't matter what the cause is, if you know how to fix it. :-))

Interesting.  The unwanted "square" is almost certainly just the textual representation of some unknown data dropped into omnibox edit text -- data that shouldn't have been accepted.

Repro on Linux stable (70.0.3538.77) shows me that omnibox is accepting a newline character -- part of "\nWelcome to Chrome" and I guess rendering it with some odd representation.  So I'll look around for where text gets sanitized (or doesn't).  I don't think it's the logo itself, but maybe something around it that drags (it's quirky, I had to click various spots to get a drag).

I haven't worked with drag-and-drop text *content* before, but I can probably figure this out.  Can we just reject strings containing newlines outright instead of accepting them as part of edit text?  I don't know the right way to handle "\nvalid text\n\nmore valid text\n" and my instinct is to reject it, ideally with an error message.

We want to paste, sanitizing the newlines to whitespace. (Think copying text from a webpage into the omnibox.  It should just work, regardless of how the new lines in the text is represented.)

Good explanation, makes sense.  Looks like the problem may be deeper than expected, though.  I can't repro in dev build with latest code because StartDrag causes an Aw Snap page crash.  See drag-related calls in this stack trace:

Received signal 6
#0 0x7f5e1f38459f base::debug::StackTrace::StackTrace()
#1 0x7f5e1f384081 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f5e12f700c0 <unknown>
#3 0x7f5e10e00fcf gsignal
#4 0x7f5e10e023fa abort
#5 0x7f5e1f382e65 base::debug::BreakDebugger()
#6 0x7f5e1f2a95a6 logging::LogMessage::~LogMessage()
#7 0x7f5e14d9de2a blink::PaintController::~PaintController()
#8 0x7f5e14da6042 blink::PaintRecordBuilder::~PaintRecordBuilder()
#9 0x7f5e16d71e5c blink::DragController::DragImageForSelection()
#10 0x7f5e16d72533 blink::DragController::StartDrag()
#11 0x7f5e16976df8 blink::MouseEventManager::TryStartDrag()
#12 0x7f5e16976486 blink::MouseEventManager::HandleDrag()
#13 0x7f5e16976793 blink::MouseEventManager::HandleMouseDraggedEvent()
#14 0x7f5e169692bf blink::EventHandler::HandleMouseMoveOrLeaveEvent()
#15 0x7f5e1696884f blink::EventHandler::HandleMouseMoveEvent()
#16 0x7f5e16d8eb27 blink::PageWidgetEventHandler::HandleMouseMove()
#17 0x7f5e16d8e9f5 blink::PageWidgetDelegate::HandleInputEvent()
#18 0x7f5e16674e6f blink::WebViewImpl::HandleInputEvent()
#19 0x7f5e167a5608 blink::WebViewFrameWidget::HandleInputEvent()
#20 0x7f5e1ce44fcc content::RenderWidgetInputHandler::HandleInputEvent()
#21 0x7f5e1cfe4e57 content::RenderWidget::HandleInputEvent()
#22 0x7f5e1ce42b80 content::QueuedWebInputEvent::Dispatch()
#23 0x7f5e1ce4264c content::MainThreadEventQueue::DispatchRafAlignedInput()
#24 0x7f5e1cfe54eb content::RenderWidget::BeginMainFrame()
#25 0x7f5e0ef5ad9d cc::ProxyMain::BeginMainFrame()
#26 0x7f5e0ef5984f _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIMN2cc9ProxyMainEFvNSt3__110unique_ptrINS4_28BeginMainFrameAndCommitStateENS6_14default_deleteIS8_EEEEENS_7WeakPtrIS5_EEJSB_EEEvOT_OT0_DpOT1_
#27 0x7f5e0ef5971e _ZN4base8internal7InvokerINS0_9BindStateIMN2cc9ProxyMainEFvNSt3__110unique_ptrINS3_28BeginMainFrameAndCommitStateENS5_14default_deleteIS7_EEEEEJNS_7WeakPtrIS4_EENS0_13PassedWrapperISA_EEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#28 0x7f5e1f289c22 base::debug::TaskAnnotator::RunTask()
#29 0x7f5e1f31e379 base::sequence_manager::internal::ThreadControllerImpl::DoWork()
#30 0x7f5e1f3205b8 _ZN4base8internal7InvokerINS0_9BindStateIMNS_16sequence_manager8internal20ThreadControllerImplEFvNS5_8WorkTypeEEJNS_7WeakPtrIS5_EES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#31 0x7f5e1f289c22 base::debug::TaskAnnotator::RunTask()
#32 0x7f5e1f2b88bf base::MessageLoopImpl::RunTask()
#33 0x7f5e1f2b8f32 base::MessageLoopImpl::DoWork()
#34 0x7f5e1f2bb006 base::MessagePumpDefault::Run()
#35 0x7f5e1f2b8391 base::MessageLoopImpl::Run()
#36 0x7f5e1f2eb996 base::RunLoop::Run()
#37 0x7f5e1cff4aa2 content::RendererMain()
#38 0x7f5e1d0cbd27 content::RunZygote()
#39 0x7f5e1d0ccfe7 content::ContentMainRunnerImpl::Run()
#40 0x7f5e0e95847a service_manager::Main()
#41 0x7f5e1d0cb2e1 content::ContentMain()
#42 0x55c5751b71b3 ChromeMain
#43 0x7f5e10dee2b1 __libc_start_main
#44 0x55c5751b702a _start
  r8: 0000000000000000  r9: 00007ffe61f09ce0 r10: 0000000000000008 r11: 0000000000000246
 r12: 00007ffe61f0a7c8 r13: 00007ffe61f0a7b8 r14: 00007ffe61f0a7c0 r15: 00007ffe61f09f81
  di: 0000000000000002  si: 00007ffe61f09ce0  bp: 00007ffe61f09f20  bx: 0000000000000006
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007f5e10e00fcf  sp: 00007ffe61f09d58
  ip: 00007f5e10e00fcf efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Missed a key bit at the top:

[1:1:1112/151313.485835:FATAL:paint_controller.cc(29)] Check failed: new_display_item_list_.IsEmpty(). 

I wonder if this is failing in release builds, causing some bad data to flow into the drop.  I've noticed the text that ends up in omnibox is inconsistent: sometimes it's "\n" (shown as square), other times it's "elcome to Chrome", and sometimes it's what I'd expect, "Welcome to Chrome" -- so maybe we've got some nasty pointer bug happening after the FATAL.

Okay, I think this bug divides into two parts:

1) Drag data problem: The "Aw Snap" page crash mentioned above -- the inconsistency of behavior there is concerning, and probably lies much deeper than omnibox.

2) Omnibox newline acceptance problem: Even when dragging text from gedit into the omnibox, it does accept newlines.  If there's other valid text, it filters out newlines, but if I drag newline characters only, they're happily appended to omnibox edit text.  This results in "squares" or tiny diagonal NL glyphs.

I am going to address part 2 in this bug.  Part 1 is being tracked at new bug  https://crbug.com/904971 

This CL will fix the omnibox part of the problem: https://chromium-review.googlesource.com/c/chromium/src/+/1334558

After this, no more squares! :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0ce11f1683c4e9f4293c5121543ee5652ed65894

commit 0ce11f1683c4e9f4293c5121543ee5652ed65894
Author: Orin Jaworski <orinj@chromium.org>
Date: Fri Nov 16 18:38:39 2018

[omnibox] Fix drag and drop acceptance of unsanitized text

The omnibox was accepting raw text from drag data when such text
was left empty by stripping Javascript schemas and whitespace.
This allowed invalid omnibox edit text content, containing e.g.
newline characters which would then render with confusing glyphs.
This CL fixes the issue by using the sanitized text even if empty.

Bug:  904380 
Change-Id: Ia43a9429d200261a929e858681cb771e6b8bc91c
Reviewed-on: https://chromium-review.googlesource.com/c/1334558
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Commit-Queue: Orin Jaworski <orinj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608865}
[modify] https://crrev.com/0ce11f1683c4e9f4293c5121543ee5652ed65894/chrome/browser/ui/views/omnibox/omnibox_view_views.cc