IllegalStateException: Drag shadow dimensions must be positive

[sentry-io]

Sentry Issue: WORDPRESS-ANDROID-3T2

IllegalStateException: Drag shadow dimensions must be positive
    at android.view.View.startDragAndDrop(View.java:24057)
    at android.widget.Editor.startDragAndDrop(Editor.java:1210)
    at android.widget.Editor.performLongClick(Editor.java:1236)
    at android.widget.TextView.performLongClick(TextView.java:11352)
    at android.view.View.performLongClick(View.java:6664)
...
(8 additional frame(s) were not displayed)

Drag shadow dimensions must be positive

[designsimply]

90-day impact: ~16 per day
Users affected in the last 90 days: 1000
First seen in: 12.9
Limited to: 99% Android 9

^{https://sentry.io/share/issue/2ae8f76166ec4b4f9e144906d6611fb3/}

Possibly related: https://stackoverflow.com/questions/52073822/illegalstateexception-drag-shadow-dimensions-must-be-positive

[sentry-io]

Sentry issue: WORDPRESS-ANDROID-3VJ

[designsimply]

90-day impact: ~22 per day
Users affected in the last 90 days: 1400
Limited to: 99% Android 9
^{https://sentry.io/share/issue/2ae8f76166ec4b4f9e144906d6611fb3/}

90-day impact: ~3 per day
Users affected in the last 90 days: 190
Limited to: Android 9
^{https://sentry.io/share/issue/bdb7e2949c724104aa5de7a91d087ab4/}

[designsimply]

90-day impact: ~33 per day
Users affected in the last 90 days: 1800
Limited to: 98% Android 9
^{https://sentry.io/share/issue/2ae8f76166ec4b4f9e144906d6611fb3/}

90-day impact: ~4 per day
Users affected in the last 90 days: 276
Limited to: Android 9
^{https://sentry.io/share/issue/bdb7e2949c724104aa5de7a91d087ab4/}

[khaykov]

After some investigation, one possible cause for this issue is drag and drop of text in editor. I found one known report of this issue when a line break is selected, and you try to drag it. I was not able to reproduce this, unfortunately.

[designsimply]

Users affected in the last 90 days: 2182
_{1, 2}

[designsimply]

Users affected in the last 90 days: 2181
_{1, 2}

Note: the 2nd issue seems to be limited to Huawei devices.

[ashiagr]

It appears these lines in Aztec editor could be causing this issue.

As this issue is limited to: 99% Android 9, it could be Android platform specific issue. Found related issues in Android Issue Tracker:
Issue 1
Issue 2

These issues were reproducible in Android 9 Pie only. They were accepted by Google, fixed and told to be available in a future build.

At P we unintentionally changed the behavior to:

• the system server keeps processing the first drag operation.
• the application loses the drag token and the user local state.
• cancelDrag() no longer cancels the ongoing operation.
• DragEvents are still delivered without the user local state.

[designsimply]

Users affected in the last 90 days: 2146
_{1, 2}

[designsimply]

I searched for "Drag shadow dimensions must be positive" in Sentry and found approximately 8,247 events for 1,651 users in the last 90 days.

For Sentry Issue WORDPRESS-ANDROID-3T2—the issue from the search results with the largest number of users affected—64 events have been tracked for this crash in 14.6.1 since it was released 9d ago on Apr 22.

[designsimply]

I searched for "Drag shadow dimensions must be positive" in Sentry and found approximately 8,876 events for 1,645 users in the last 90 days.

220 events have been tracked for crash WORDPRESS-ANDROID-3T2 in 14.7 and 14.7.1 since they were released 15d and 4d ago respectively.

Events in the last 90d: 7,800
Events in the last 15d for 14.7: 145
Events in the last 4d for 14.7.1: 75
Users affected in the last 90d: 1,500
Also see: 90d graph

[mkevins]

It seems this issue is also present in Android 10 (so far ~ 76% Android 9, 23% Android 10). Also, this issue seems to occur in both Aztec and Gutenberg editors.

JS snippet to examine editor use

Pasted in browser console in sentry:

// query API for events
let events = await fetch('https://sentry.io/api/0/issues/1135692615/events/?full=1').then(raw => raw.json());

Then, to examine editor usage for the various events:

// get editor counts
events.map(({entries: [,,{data: {values}}]}) =>
  values.map(({message}) =>
    message.includes('editor_session_start')
      ? message.includes('classic')
        ? 'aztec'
        : message.includes('gutenberg')
          ? 'gutenberg'
          : undefined
      : undefined
  ).filter(editor => editor)
).reduce((sum, editors) =>
  !! editors.length
    ? editors.every(editor => editor === 'gutenberg')
      ? {...sum, gutenberg: sum.gutenberg + 1}
      : editors.every(editor => editor === 'aztec')
        ? {...sum, aztec: sum.aztec + 1}
        : {...sum, mixed: sum.mixed + 1}
    : sum
, {gutenberg: 0, aztec: 0, mixed: 0});

Which gave: {gutenberg: 7, aztec: 52, mixed: 4}, indicating that both editors exhibit this behavior (also, "mixed" simply means that the breadcrumbs for this event included session start events for both editors). Unfortunately, this did not seem to give any clues.

Finally, I searched for "Dropped" in the breadcrumb messages, but did not find this log entry:

// look for Dropped log
events.map(({entries: [,,{data: {values}}]}) =>
  values.map(({message}) =>
    message.includes('Dropped')
      ? message
      : undefined
  ).filter(message => message)
);

I attempted to reproduce this by several combinations of drag and drop, including having newlines at the beginnings and endings of the dragged text, as well as dropping to positions before and after newlines. I also tried various combinations of dragging images, rich text, and mixed content, with and without the soft keyboard visible, and in both Aztec and Gutenberg editors. I have not been able to reproduce this issue, however I did notice something odd while trying (via Pixel 3 XL API 28 emulator): when I dragged a clip of text, the caret position seemed to be "scaled down", i.e. it remained at a fraction of the x and y values from where I expected it to be:

Also, when I dragged newlines from a textarea (using split screen with Chrome open), the newlines appeared as escaped characters, instead of actual newlines, or <br> tags.

[designsimply]

A 90d graph of results for "Drag shadow dimensions must be positive" in a Sentry search returns 2,050 events:

The majority of those appear to be in this Sentry issue:

Events in the last 90d: 8,500
Users affected in the last 90d: 1,300
_{WORDPRESS-ANDROID-3T2: https://sentry.io/share/issue/2ae8f76166ec4b4f9e144906d6611fb3/}

[designsimply]

A 90d graph of results for "Drag shadow dimensions must be positive" in a search at Sentry > Discover returns 1,512 events:

The majority of those appear to be in this Sentry issue:

Events in the last 90d: 9,100
Users affected in the last 90d: 989
_{WORDPRESS-ANDROID-3T2: https://sentry.io/share/issue/2ae8f76166ec4b4f9e144906d6611fb3/}

[mzorz]

Ok so by looking into one of the logs collected in Sentry I could see one of the crashes on Aztec happened shortly after an image failed to upload (also, there's a bug there we need to check: the image they tried to upload was a .webp image which is unsupported in FluxC and as such it will always fail, will open a separate issue on this).

So I figured given the crash was a few seconds after the failure, I'd imagine the user would go and try open the Post with the failed image to see what happened, and trying to tap retry or doing something with or around the boundaries of the image.

So that's what I started looking for, and was able to reproduce 3 times already on a Pixel 3 XL API 29 emulator 🎉 , here's a video (crash happens towards the end)

https://cloudup.com/cd_D1uIwAX8

Steps to reproduce (first, make sure to set "use block editor" to off for your test site):

1. add some text
2. add a webp image above(I downloaded one with the browser and then used Aztec's media picker to insert). Probably any image will do, but just narrowing down the same steps as per what the user seemingly did here.
3. exit the editor, then open the errored post again
4. place the cursor right at the end of the image
5. select the image by moving the start cursor to the top (it didn't always work)
6. now long press -> the logcat shows the exception right away, and then the application enters an ANR state even when you still can seemingly move the cursor around.
7. 5 seconds later, the ANR dialog appears.

2020-08-25 13:55:42.298 22555-22555/org.wordpress.android E/AndroidRuntime: FATAL EXCEPTION: main
    Process: org.wordpress.android, PID: 22555
    java.lang.IllegalStateException: Drag shadow dimensions must be positive
        at android.view.View.startDragAndDrop(View.java:25408)
        at android.widget.Editor.startDragAndDrop(Editor.java:1183)
        at android.widget.Editor.performLongClick(Editor.java:1209)
        at android.widget.TextView.performLongClick(TextView.java:12201)
        at android.view.View.performLongClick(View.java:7196)
        at android.view.View$CheckForLongPress.run(View.java:27309)
        at android.os.Handler.handleCallback(Handler.java:883)
        at android.os.Handler.dispatchMessage(Handler.java:100)
        at android.os.Looper.loop(Looper.java:214)
        at android.app.ActivityThread.main(ActivityThread.java:7356)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)
2020-08-25 13:55:42.298 22555-22555/org.wordpress.android E/WordPress-EDITOR: HTML content of Aztec Editor before the crash:
2020-08-25 13:55:42.300 22555-22555/org.wordpress.android E/WordPress-EDITOR: ok trtrty now\n\nty now<img class="uploading size-full" data-wpid="2" src="/storage/emulated/0/Download/1.webp" />df adsf a

Been reading the issues mentioned here by @ashiagr and it seems the issue has been fixed on the platform side.

I wonder if we can workaround it so, I'm investigating a bit further how the OnDragListener works.
This document here explains how the View.OnDragListener callback works against the OnDragListener() interface, which takes precedence. https://developer.android.com/guide/topics/ui/drag-drop#AboutDragListeners. The precedence seems good but, the documentation indicates that the first event received by the OnDragListener is already when the ShadowBuilder has been called.

Ideally, I'm hoping to be able to provide our own ShadowBuilder for drag operations started from within Aztec, but so far this seems to be all internal to the view.

Will continue investigating an I'll update here with what I can find.

[mzorz]

Re: this:

(also, there's a bug there we need to check: the image they tried to upload was a .webp image which is unsupported in FluxC and as such it will always fail, will open a separate issue on this).

Opened issue here #12822