<img> wider than its rendering column fails to paint on Android — silently in isolation, with an "invalid measurement" error alongside any other text (not a decode-timing race)
维护者通常 3 天内回复
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 55/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- android, react-native
- 领域
- mobile
调研方向
从 MeasurementStore.measure() 以及涉及 AsyncDrawable 和 ImageDecoder.setTargetSize 的 Android 图像路径开始。使用三个超大图像案例运行链接的最小复现，然后比较单行和多行测量行为，以及无效测量日志。完成的标准是：超大图像在渲染期间不再静默失败或消失。
由索引模型根据 Issue 内容生成。
描述
Describes the bug
An <img> tag whose declared width exceeds the actual width of the column EnrichedText renders it into fails to paint on Android. This is fully deterministic — not a timing race — and reproduces on the very first cold launch, every time.
I originally filed this issue theorizing an unsynchronized bounds race in AsyncDrawable (ImageDecoder.setTargetSize reading a still-zero Rect before the text-layout pass assigns real bounds). That was a plausible read of the source, but after extensive testing (cold cache, warm cache, a local low-latency image server, and the exact resolve-then-remount sequence a real consuming app uses, run concurrently across 16 images) I was never able to reproduce it. Everything I've actually observed — including the original production bug that led me to file this — is fully explained by the mechanism below instead, with no timing element at all. Retracting that theory.
The failure takes two different shapes depending on context:
- The
<img>is the only content in theEnrichedText— the failure is completely silent. No exception, no broken-image placeholder, nothing logged anywhere. - There's any other text in the same
EnrichedText(true of essentially all real admin-authored content — headings, paragraphs, etc. around an image) — the same failure now logs a concrete diagnostic:ReactNativeJNI: EnrichedTextView returned an invalid measurement. Min: [0,0] Max: [384,inf] Actual: [400,404.333]Maxis the real available column width;Actualis what the measure function reported back, driven by the embedded image's declared size.
This split traces to MeasurementStore.measure(): single-line content reports StaticLayout.getLineWidth(0), but multi-line content reports StaticLayout.width instead — and that can still exceed the nominal wrap width when one line contains an unsplittable inline image wider than the rest.
To Reproduce
Minimal repro app: https://github.com/ekrapfl/rne-html-repro-android-img-paint
npm install && npm run android(native dev build, Fabric).- Three cases render: an image that fits (paints normally), the same image declared far wider than the screen with no other content (renders at full size, overflowing the screen edge uncropped), and that same oversized image with a paragraph before it (reserves no visible space, shows nothing).
adb logcat | grep -i "invalid measurement"around the third case.
Expected behavior
An oversized declared width shouldn't cause total, silent render failure. At minimum, a diagnostic should surface consistently (right now it only does when there's other text in the same view); ideally the library would clamp/scale the image to the available column itself, the way a browser does with img { max-width: 100% }, rather than leaving every consumer to compute and inject a safe pixel width themselves.
Device tested
- Pixel 10 Pro XL emulator (
sdk_gphone16k_arm64), Android API 37 react-native-enriched-html1.1.1, React Native 0.86.3, Expo ~57.0.23, Fabric (New Architecture)
Additional context
One honest caveat: the visual failure reproduces reliably in the minimal repro above, on a fresh cold install, every time. The exact JNI log line was confirmed repeatedly against a full production app under a matching layout structure, but hasn't fired in the standalone repro despite matching nesting depth, padding, and styling — something about the fuller app context matters there that I haven't isolated. The visual symptom (reserves no space, never paints) is the same failure either way.
- 主要语言
- C
- 星标
- 1.4k
- 派生
- 74
- 平均合并
- 3 天 4 小时
- 30 天内合并 PR
- 18
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
software-mansion/react-native-enriched-html 的其他 Issue
-
难度 4/5 3-5 天 新手友好度 48/100
software-mansion/react-native-enriched-html#848 ·
维护者通常 3 天内回复
-
[Feature request] Vertical spacing (margins) for headings and lists in htmlStyle可能已有人在做 @henrikra 于 8 天前认领。 未关闭enhancement
难度 4/5 3-5 天 新手友好度 20/100
software-mansion/react-native-enriched-html#832 ·
维护者通常 3 天内回复
-
bug
难度 3/5 1-2 天 新手友好度 76/100
software-mansion/react-native-enriched-html#818 · 1 条评论 ·
维护者通常 3 天内回复
-
[iOS] Tags not parsed on iOS below a certain string length可能已有人在做 @hejsztynx 于 16 天前认领。 未关闭bug
难度 4/5 3-5 天 新手友好度 42/100
software-mansion/react-native-enriched-html#811 · 3 条评论 ·
维护者通常 3 天内回复
-
bug
难度 3/5 1-2 天 新手友好度 50/100
software-mansion/react-native-enriched-html#810 · 1 条评论 ·
维护者通常 3 天内回复
查看 software-mansion/react-native-enriched-html 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
ly05010419/MacNativeGames#1420 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
JustAResearcher/gpu-unlock-ada#124 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
swoole/swoole-cli#1092 ·
-
难度 2/5 1-3 小时 新手友好度 62/100
-
inflate: total_in uses plain += on c_ulong (32-bit on Windows), panics in debug for streams > 4 GiB未关闭
难度 1/5 1 小时以内 新手友好度 85/100
trifectatechfoundation/zlib-rs#570 · 1 条评论 ·