Bug 202909 - Chromium test-case asserts with ASSERTION FAILED: startOffset <= endOffset
Summary: Chromium test-case asserts with ASSERTION FAILED: startOffset <= endOffset
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-10-13 14:29 PDT by Emilio Cobos Álvarez (:emilio)
Modified: 2024-04-05 10:41 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Emilio Cobos Álvarez (:emilio) 2019-10-13 14:29:09 PDT
On master (247b0314320d499ae788b6ea993aa1d98e2d607e / r250962), WebKitGTK build.

Running this test-case: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/fast/dom/Range/range-extract-contents-after-move-to-another-document-crash.html?rcl=753caf715d8f30f0c673f1b4b36dadfc75c3201f

Asserts like:

ASSERTION FAILED: startOffset <= endOffset
../../Source/WebCore/dom/Range.cpp(686) : WebCore::ExceptionOr<WTF::RefPtr<WebCore::Node> > WebCore::processContentsBetweenOffsets(WebCore::Range::ActionType, WTF::RefPtr<WebCore::DocumentFragment>, WTF::RefPtr<WebCore::Node>, unsigned int, unsigned int)
1   0x7fee8256f3d3 /home/emilio/src/WebKit/WebKitBuild/Debug/lib/libjavascriptcoregtk-4.0.so.18(WTFCrash+0x9) [0x7fee8256f3d3]
2   0x7fee8e2185f2 /home/emilio/src/WebKit/WebKitBuild/Debug/lib/libwebkit2gtk-4.0.so.37(_ZN3WTF15CrashOnOverflow10overflowedEv+0) [0x7fee8e2185f2]
3   0x7fee90711bc7 /home/emilio/src/WebKit/WebKitBuild/Debug/lib/libwebkit2gtk-4.0.so.37(+0xcad4bc7) [0x7fee90711bc7]
4   0x7fee90710e2b /home/emilio/src/WebKit/WebKitBuild/Debug/lib/libwebkit2gtk-4.0.so.37(_ZN7WebCore5Range15processContentsENS0_10ActionTypeE+0x1b5) [0x7fee90710e2b]
5   0x7fee90712fe4 /home/emilio/src/WebKit/WebKitBuild/Debug/lib/libwebkit2gtk-4.0.so.37(_ZN7WebCore5Range15extractContentsEv+0x28) [0x7fee90712fe4]
6   0x7fee8f7ac807 /home/emilio/src/WebKit/WebKitBuild/Debug/lib/libwebkit2gtk-4.0.so.37(+0xbb6f807) [0x7fee8f7ac807]
7   0x7fee8f7b1e74 /home/emilio/src/WebKit/WebKitBuild/Debug/lib/libwebkit2gtk-4.0.so.37(+0xbb74e74) [0x7fee8f7b1e74]
8   0x7fee8f7ac87b /home/emilio/src/WebKit/WebKitBuild/Debug/lib/libwebkit2gtk-4.0.so.37(_ZN7WebCore39jsRangePrototypeFunctionExtractContentsEPN3JSC14JSGlobalObjectEPNS0_9CallFrameE+0x23) [0x7fee8f7ac87b]
9   0x7fee2cafa16b [0x7fee2cafa16b]

Seems like it's handled safely so not filing as security sensitive.
Comment 1 Radar WebKit Bug Importer 2019-10-14 17:23:22 PDT
<rdar://problem/56271256>
Comment 2 Ahmad Saleem 2022-10-05 09:13:00 PDT
@ap - Is it something related to Webkit or this was specific to Chromium port? Thanks!
Comment 3 Alexey Proskuryakov 2022-10-07 11:41:58 PDT
This was filed against the Gtk port, and long after Chromium forked. So, not Chromium related, it's just reproducible with their test case.
Comment 4 Ahmad Saleem 2024-04-05 05:04:53 PDT
It does not reproduce this assert in WebKit Minibrowser (WK2 - Debug - 277105@main)

https://jsfiddle.net/9tj0f6L4/
Comment 5 Alexey Proskuryakov 2024-04-05 10:41:08 PDT
Cannot reproduce in run-webkit-tests either, WebKit1 or WebKit2. And this is cross-platform code, so unlikely to have been Gtk only.

It may be nice to land this test, as I couldn't find a specific fix. But realistically, seems not worth tracking that, and we may well have one anyway.