Dragging content from LibreOffice DCHECKs content_shell |
||||
Issue descriptionVersion: ToT r405075 OS: Ubuntu 14.04 What steps will reproduce the problem? (1) Run a debug build of content_shell (2) Open Libre Office, make a new document, enter a line from a popular broadway musical. (3) Select all, drag the text over content_shell What is the expected output? Some drag and droppy stuff. What do you see instead? [130182:130182:0714/154555:2591598063333:FATAL:desktop_drag_drop_client_aurax11.cc(337)] Check failed: event.property == atom_cache_->GetAtom(kChromiumDragReciever) (0 vs. 571) #0 0x7f6edccce3fe base::debug::StackTrace::StackTrace() #1 0x7f6edcd359cf logging::LogMessage::~LogMessage() #2 0x7f6ed0977f91 views::DesktopDragDropClientAuraX11::X11DragContext::OnSelectionNotify() #3 0x7f6ed0979fe2 views::DesktopDragDropClientAuraX11::OnSelectionNotify() #4 0x7f6ed0991480 views::DesktopWindowTreeHostX11::DispatchEvent() #5 0x7f6edb2ae98f ui::PlatformEventSource::DispatchEvent() #6 0x7f6ecbf00754 ui::X11EventSourceGlib::ProcessXEvent() #7 0x7f6ecbeedc4a ui::X11EventSource::ExtractCookieDataDispatchEvent() #8 0x7f6ecbeedb5a ui::X11EventSource::DispatchXEvents() #9 0x7f6ecbf00915 ui::(anonymous namespace)::XSourceDispatch() #10 0x7f6ecf868ce5 g_main_context_dispatch #11 0x7f6ecf869048 <unknown> #12 0x7f6ecf8690ec g_main_context_iteration #13 0x7f6edcd6bd3f base::MessagePumpGlib::Run() #14 0x7f6edcd5330f base::MessageLoop::RunHandler() #15 0x7f6edcdfa1f4 base::RunLoop::Run() #16 0x7f6ede373ac6 content::BrowserMainLoop::MainMessageLoopRun() #17 0x7f6ede373821 content::BrowserMainLoop::RunMainMessageLoopParts() #18 0x7f6ede37da55 content::BrowserMainRunnerImpl::Run() #19 0x000001450596 ShellBrowserMain() #20 0x00000142e8e6 content::ShellMainDelegate::RunProcess() #21 0x7f6ee00d152b content::RunNamedProcessTypeMain() #22 0x7f6ee00d3842 content::ContentMainRunnerImpl::Run() #23 0x7f6ee00d0632 content::ContentMain() #24 0x000000537729 main #25 0x7f6ecc106f45 __libc_start_main #26 0x000000537615 <unknown> Aborted (core dumped)
,
Jul 14 2016
According to X11's most excellent documentation, the property atom can be None if the selection conversion failed: https://tronche.com/gui/x/xlib/events/client-communication/selection.html So I guess we need to handle this as an error case and just early return?
,
Sep 27 2016
Thanks to dcheng's excellent diagnosis, this bug is easy to fix. CL coming soon. Slightly more specific reproduction steps: (1) Build chrome or content_shell for Linux in debug mode and start it (chrome opens NTP by default, content_shell opens www.google.com -- this is fine) (2) Open Libre Office Word, type in the words "Crash Chrome" (any text works though) (3) Select the words "Crash Chrome" and drag them from Libre Office into Chrome's window
,
Sep 27 2016
,
Sep 30 2016
Updated reproduction steps, thanks to the code review. (1) Build chrome or content_shell for Linux in debug mode and start it pointed to https://codemirror.net/demo/folding.html (e..g, /out/Default/content_shell https://codemirror.net/demo/folding.html) (2) Open Libre Office Word, type in the words "Crash Chrome" (any text works though) (3) Select the words "Crash Chrome" and drag them from Libre Office into one of the text editor window Expected results: The words "Crash Chrome" should appear in the text editor window where it was dragged. Actual results: DCHECK-induced crash.
,
Sep 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/062909083c817c37f3156ba7f28e96d884dc7195 commit 062909083c817c37f3156ba7f28e96d884dc7195 Author: pwnall <pwnall@chromium.org> Date: Fri Sep 30 21:42:11 2016 Drag and drop improvements on X11. The XDND protocol has a mechanism for a drag source to advertise a list of supported data formats to the drop target, and a separate mechanism for the drop target to retrieve data from the drag source in any desired format. We currently assume that the drag source will be able to provide data in any of the formats it advertises. While reasonable, this assumption breaks due to misbehaving applications. We also deviate from the XDND specification when obtaining data from the drag source, by passing in an incorrect time stamp vaue. This CL combines fixes for the issues described above with the small refactorings to desktop_drag_drop_client_aurax11.cc that facilitated diagnosing and fixing the issues. BUG= 628099 TEST=manually ran reproduction steps before/after fix Review-Url: https://codereview.chromium.org/2372403002 Cr-Commit-Position: refs/heads/master@{#422228} [modify] https://crrev.com/062909083c817c37f3156ba7f28e96d884dc7195/ui/views/widget/desktop_aura/desktop_drag_drop_client_aurax11.cc
,
Sep 30 2016
,
Oct 3 2016
For posterity: the bug reproduces with LibreOffice 4.2.8.2 (in Ubuntu 14.04), but does not reproduce with LibreOffice 5. |
||||
►
Sign in to add a comment |
||||
Comment 1 by dcheng@chromium.org
, Jul 14 2016