Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

<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)

Đang mở
  • Có gì không ổn?
#797 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@hejsztynx đang làm issue này rồi.

Từ ngày 24/9/2026.

  • #807 của @hejsztynx — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
android, react-native
Lĩnh vực
mobile

Hướng nghiên cứu

Bắt đầu với MeasurementStore.measure() và đường dẫn hình ảnh Android liên quan đến AsyncDrawable và ImageDecoder.setTargetSize. Chạy bản tái hiện tối thiểu được liên kết với ba trường hợp hình ảnh quá lớn, sau đó so sánh hành vi đo trên một dòng và nhiều dòng, cùng với nhật ký đo không hợp lệ. Được xem là hoàn tất khi hình ảnh quá lớn không còn âm thầm thất bại hoặc biến mất trong quá trình kết xuất.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug

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:

  1. The <img> is the only content in the EnrichedText — the failure is completely silent. No exception, no broken-image placeholder, nothing logged anywhere.
  2. 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]
    Max is the real available column width; Actual is 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

  1. npm install && npm run android (native dev build, Fabric).
  2. 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).
  3. 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-html 1.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.

Ngôn ngữ chính
C
Star
1.4k
Fork
68
Merge trung bình
3 ngày 16 giờ
Pull request đã merge (30 ngày)
6

Chuẩn bị môi trường

  • Không có Dockerfile hay tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của software-mansion/react-native-enriched-html

Tất cả issue của software-mansion/react-native-enriched-html

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.