Closed
Bug 533149
Opened 15 years ago
Closed 15 years ago
DOM incorrect if HTML gzipped & very small
Categories
(Core :: DOM: HTML Parser, defect)
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
Updated•15 years ago
|
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.
Updated•15 years ago
|
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.
Description
•