Bugzilla

Thanks for the bug report.  For what it's worth, I can't reproduce on Ubuntu 24.04 (on a display with 100% pixel scaling, i.e. no HiDPI).  I can trigger a version of this bug if I zoom in all the way though with full-page-zoom (500% scale factor).

The last few lines of the log are supposed to look like this:
```
Wrote: /builddir/build/RPMS/firefox-debuginfo-138.0.1-1.fc42.x86_64.rpm
RPM build warnings:
    Duplicate build-ids /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib64/firefox/firefox and /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib64/firefox/firefox-bin
    absolute symlink: /usr/lib64/firefox/dictionaries -> /usr/share/hunspell
    Duplicate build-ids /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib/debug/usr/lib64/firefox/firefox-138.0.1-1.fc42.x86_64.debug and /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib/debug/usr/lib64/firefox/firefox-bin-138.0.1-1.fc42.x86_64.debug
Child return code was: 0
```
But in the screenshot and in my local testing with 500% scale factor, there's other text at the end of the log instead.

A few observations:
- The text file here (linked in comment 0) is 145MB in size.
- When I view the file at the default 100% zoom level, `window.document.documentElement.scrollHeight` is `12749200` (which is nearly of `nscoord_MAX` in CSS pixels, which is the upper limit of lengths that we reliably track for layout). (That's 2^30-1 nscoord units, which are 1/60th of a pixel -- so it's 17895697px).
- That means full-page-zoom and/or HiDPI could easily push us over that nscoord_MAX limit at which point stuff is liable to get garbled.

So this is sort of a version of bug 265084.  Gecko's layout representation isn't robust for documents of this size.

Thanks for the bug report.  For what it's worth, I can't reproduce on Ubuntu 24.04 (on a display with 100% pixel scaling, i.e. no HiDPI).  I can trigger a version of this bug if I zoom in all the way though with full-page-zoom (500% scale factor).

The last few lines of the log are supposed to look like this:
```
Wrote: /builddir/build/RPMS/firefox-debuginfo-138.0.1-1.fc42.x86_64.rpm
RPM build warnings:
    Duplicate build-ids /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib64/firefox/firefox and /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib64/firefox/firefox-bin
    absolute symlink: /usr/lib64/firefox/dictionaries -> /usr/share/hunspell
    Duplicate build-ids /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib/debug/usr/lib64/firefox/firefox-138.0.1-1.fc42.x86_64.debug and /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib/debug/usr/lib64/firefox/firefox-bin-138.0.1-1.fc42.x86_64.debug
Child return code was: 0
```
But in the screenshot and in my local testing with 500% scale factor, there's other text at the end of the log instead (and various other character-positioning glitches).

A few observations:
- The text file here (linked in comment 0) is 145MB in size.
- When I view the file at the default 100% zoom level, `window.document.documentElement.scrollHeight` is `12749200` (which is nearly of `nscoord_MAX` in CSS pixels, which is the upper limit of lengths that we reliably track for layout). (That's 2^30-1 nscoord units, which are 1/60th of a pixel -- so it's 17895697px).
- That means full-page-zoom and/or HiDPI could easily push us over that nscoord_MAX limit at which point stuff is liable to get garbled.

So this is sort of a version of bug 265084.  Gecko's layout representation isn't robust for documents of this size.

Thanks for the bug report.  For what it's worth, I can't reproduce on Ubuntu 24.04 (on a display with 100% pixel scaling, i.e. no HiDPI).  I can trigger a version of this bug if I zoom in all the way though with full-page-zoom (500% scale factor).

The last few lines of the log are supposed to look like this:
```
Wrote: /builddir/build/RPMS/firefox-debuginfo-138.0.1-1.fc42.x86_64.rpm
RPM build warnings:
    Duplicate build-ids /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib64/firefox/firefox and /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib64/firefox/firefox-bin
    absolute symlink: /usr/lib64/firefox/dictionaries -> /usr/share/hunspell
    Duplicate build-ids /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib/debug/usr/lib64/firefox/firefox-138.0.1-1.fc42.x86_64.debug and /builddir/build/BUILD/firefox-138.0.1-build/BUILDROOT/usr/lib/debug/usr/lib64/firefox/firefox-bin-138.0.1-1.fc42.x86_64.debug
Child return code was: 0
```
But in the screenshot and in my local testing with 500% scale factor, there's other text at the end of the log instead (and various other character-positioning glitches).

A few observations:
- The text file here (linked in comment 0) is 145MB in size.
- When I view the file at the default 100% zoom level, `window.document.documentElement.scrollHeight` is `12749200` (which nearly reaches `nscoord_MAX` in CSS pixels, which is the upper limit of lengths that we reliably track for layout). (That's 2^30-1 nscoord units, which are 1/60th of a pixel, at 100% zoom/pixel-scaling level -- so that threshold is `17895697` css pixels).
- That means full-page-zoom and/or HiDPI could easily push us over that nscoord_MAX limit at which point stuff is liable to get garbled.

So this is sort of a version of bug 265084.  Gecko's layout representation isn't robust for documents of this size.