Closed Bug 533149 Opened 15 years ago Closed 15 years ago

DOM incorrect if HTML gzipped & very small

Categories

(Core :: DOM: HTML Parser, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bugzilla, Unassigned)

References

Details

(Whiteboard: [fixed by the HTML5 parser])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Locally the page looks fine. It also looks fine if it's on a server. If gzip is enabled the created DOM is different and the layout is broken. If a little bit of padding content is added it's still broken. If more padding content is added it works again. Same behavior in 3.7a1pre. However, if html5.enable is set to true, it works fine. Reproducible: Always Steps to Reproduce: 1. Open these: A) http://kaioa.com/k/fftc/test1a.html | uncompressed B) http://kaioa.com/k/fftc/test1b.html | gzip (1006 bytes) C) http://kaioa.com/k/fftc/test2.html | gzip with too little padding (1021 bytes) D) http://kaioa.com/k/fftc/test3.html | gzip with enough padding (1662 bytes) Actual Results: A and D are fine. B and C aren't. Here are some screenshots (3.5.5 on WinXP32): A) http://kaioa.com/k/fftc/test1a.png B) http://kaioa.com/k/fftc/test1b.png C) http://kaioa.com/k/fftc/test2.png D) http://kaioa.com/k/fftc/test3.png If you compare the DOM of 1a and 1b, you'll see that they are different. Even if the source is identical. Expected Results: Enabling gzip compression should *never* break the layout. The same markup should *always* result in the same DOM. I'm not really sure if gzip is the culprit here. Maybe it's just the file size. Either way... my workaround for the time being is to disable gzip compression of HTML files. :/
Confirmed on Windows with STR. Can someone try on other OSes?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Same with: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Depends on: html5-parsing
Found another quirky detail. If you disable caching test1a is always broken. If caching is enabled pressing Ctrl+F5 results in a broken page. Press F5 and it's fine again. Ctrl+F5 broken again... etc. You can repeat this ad infinitum.
OS: Windows XP → All
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
You need to log in before you can comment on or make changes to this bug.