NSRangeException: Aztec.TextStorage attributedSubstringFromRange:: Out of bounds

[sentry[bot]]

Sentry Issue: WORDPRESS-IOS-1W6P

NSRangeException: NSMutableRLEArray replaceObjectsInRange:withObject:length:: Out of bounds
  ?, in <redacted>
...
(34 additional frame(s) were not displayed)

This one seems like it could be due to the device just not having enough memory🤔

[designsimply]

7-day impact: 29 (new crash) Users affected in the last 7 days: 22 First seen in: 13.2.3.1

^{https://sentry.io/share/issue/94e42b8dcb934785a6c2d37238fcb1d2/}

[designsimply]

22-day impact: ~7 per day Users affected in the last 22 days: 86 First seen in: 13.2.3.1

^{https://sentry.io/share/issue/94e42b8dcb934785a6c2d37238fcb1d2/}

[designsimply]

@koke is it reasonable to assume this one is due to not having enough memory free on the device? I looked through several of the crashes and many had <100MB free and some had as much as 290MB free.

[koke]

I don't think it's related to memory. Looking at the crash I see:

• This seems to happen in WordPress.AztecPostViewController
• There is UITextDragAssistant in the stack trace, and other class names that seem to point to this happening when using drag and drop on text
• This was first encountered in 13.2.3.1

The only change in 13.2.3.1 that seems relevant is #12548 (cc @SergioEstevao)

I've been messing around selecting things and trying to drag text around in the editor but I haven't been able to reproduce.

However that code in #12548 is modifying the current selection in the text view. So it might be that memory pressure has something to do with it. In my testing, if I try to drag and drop a link when the editor doesn't have the focus, the code that brings the focus runs before the link appears draggable, but if the device is being slow, I could imagine the dragging UI appearing first, and while the user is dragging the link the shouldInteractWithURL method would get called and change the selection causing the crash.

@SergioEstevao I don't fully understand the implementation in #12548. If I implement the delegate method but just return false it seems to behave as expected, and it would be less likely to interfere with other moving parts in UIKit. Any reasons not to do that?

[SergioEstevao]

@SergioEstevao I don't fully understand the implementation in #12548. If I implement the delegate method but just return false it seems to behave as expected, and it would be less likely to interfere with other moving parts in UIKit. Any reasons not to do that?

That works for version for iOS 13.1 and above but not on 13.0

I can add a platform check just to make sure we only run it on 13.0, like we did for Gutenberg mobile:

func textView(_ textView: UITextView, shouldInteractWith URL: URL, in characterRange: NSRange, interaction: UITextItemInteraction) -> Bool {
        if #available(iOS 13.1, *) {
            return false
        } else if #available(iOS 13.0.0, *) {
            // Sergio Estevao: This shouldn't happen in an editable textView, but it looks we have a system bug in iOS13 so we need this workaround
            let position = characterRange.location
            textView.selectedRange = NSRange(location: position, length: 0)
            textView.typingAttributes = textView.attributedText.attributes(at: position, effectiveRange: nil)
            textView.delegate?.textViewDidChangeSelection?(textView)
        } else {
            return false
        }

        return false
    }```

[koke]

Gotcha, I remember 13.0 was related somehow, but I missed the connection. Currently 13.0 usage is around 1% and dropping. I think I would be ok with the buggy behavior on 13.0 if it gets us out of the crash

[sentry[bot]]

Sentry Issue: WORDPRESS-IOS-5QA

NSRangeException: NSMutableRLEArray replaceObjectsInRange:withObject:length:: Out of bounds
  File "main.swift", line 7, in main
...
(34 additional frame(s) were not displayed)

Events in the last 90 days: 2,900 Users affected in the last 90 days: 369

[designsimply]

I searched Sentry for "NSMutableRLEArray replaceObjectsInRange:withObject:length:: Out of bounds" and found no crashes recorded for that error in 14.3.0.3 on iOS 13.3. No crashes for iOS 13.0 or 13.1 either.

Note that there are still crashes happening for the same error on 14.3.0.3 on iOS 13.3.1 though.

[designsimply]

Sentry Issue: WORDPRESS-IOS-5QA Events in 14.3.0.3 since it was released 18d ago on Mar 9: 80

[designsimply]

Events in the last 90d: 3,500 Events in the last 11d for 14.9: 34 in 14.9 since it was released on 2020-06-01 Users affected in the last 90d: 380 _{https://sentry.io/share/issue/f975828a305e4efb9e2ad4ac9d6e273d/}

[designsimply]

Events in the last 90d: 4,000 Users affected in the last 90d: 351 Events in the latest release: 16 (15.3 released 13d ago on 2020-07-24) _{https://sentry.io/share/issue/f975828a305e4efb9e2ad4ac9d6e273d/}

Note: seems to be happening less and less often in the latest releases.

[designsimply]

Events in the last 90d: 642 Users affected in the last 90d: 319 _{WORDPRESS-IOS-5QA: https://sentry.io/share/issue/f975828a305e4efb9e2ad4ac9d6e273d/}

[designsimply]

Events in the last 90d: 522 Users affected in the last 90d: 267 _{WORDPRESS-IOS-5QA: https://sentry.io/share/issue/f975828a305e4efb9e2ad4ac9d6e273d/}

[designsimply]

Events in the last 90d: 4,400 Users affected in the last 90d: 157 _{WORDPRESS-IOS-5QA: https://sentry.io/share/issue/f975828a305e4efb9e2ad4ac9d6e273d/}

40% reduction in users affected compared to the last time we checked, and this issue has been open for over 14 months and it's labeled as low priority. @jkmassel is it okay to close this issue?

[guarani]

Noting that this might affect block editor users despite Aztec being in the name. Logs show that the block editor was opened prior to the crash:

🔵 Tracked: editor_session_start <blog_id: xyz, blog_type: wpcom, content_type: gutenberg, editor: gutenberg, entry_point: postsList, has_unsupported_blocks: 0, post_type: post, session_id: xyz, startup_time_ms: 175, unstable_gallery_with_image_blocks: true, unsupported_blocks: []>

Started a thread on Slack: p1712607058564289-slack-C012H19SZQ8

[twstokes]

I can confirm that this is also occurring in the block editor @guarani (it uses Aztec components). One commonality I'm seeing with the crashes is Arabic encodings in the content.

[dangermattic]

Thanks for reporting! 👍

[sentry[bot]]

Sentry Issue: WORDPRESS-IOS-5QA

[sentry[bot]]

Sentry Issue: JETPACK-IOS-BN