Closed Bug 339459 Opened 19 years ago Closed 18 years ago

Enabling Universal Charset detector cancels image load on some page (possibly network related bug?)

Categories

(Core :: Networking: Cache, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 335909

People

(Reporter: mcsmurf, Unassigned)

References

Details

(Keywords: regression)

First i'm not sure if this Bug here is filed in the correct component, it's a somewhat strange bug IMHO where i10n and netwerk/ play a role. To reproduce: 1. Enable the Universal Charset detector (a safe way for this is setting the pref intl.charset.detector to "universal_charset_detector") 2. Clear the (HTTP) Cache 3. Go to http://www.dwd.de/de/WundK/Warnungen/index.htm?Land=MB00&Art=O 4. Now click on the link "Warnungen" on the left side (the link has a yellow color) 5. Observe that the loading of the map (image) from the URL http://www.dwd.de/scripts/getimg.php?src=/wundk/Warnungen/DL00_O.png has been cancelled, SeaMonkey thinks the pageload has been finished. Only some part of the image is displayed, a packet sniffer shows that SeaMonkey seems to cancel the HTTP load of the image (right after the tcp stack ACKs a data packet from the image, it sends a packet with RST flag set and so the image load ends). The bug is visible 95% of the time when trying here. If you turn off the univeral charset detector (reseting pref to default), the bug cannot be observed.
I can't reproduce this, but I assume it's somehow related to bug 61363
Depends on: latemeta
Ok, in older builds it also "cancels" the image load, but it immediately reloads the image so that it appears complete. This regressed between 2006-03-30-09 and 2006-03-31-09. Possible candidates which could have caused this regression are Bug 330397 and Bug 287646. Both are netwerk/ bugs, so moving.
Assignee: smontagu → nobody
Component: Internationalization → Networking
Keywords: regression
QA Contact: amyy → networking
Some cache info: On first load when the image load is cancelled, SeaMonkey states when looking at the properties of the image (note the image changes every few minutes to hours, so you might get different numbers) that the image is 7025 bytes in size. about:cache?device=memory says to this: Key: http://www.dwd.de/scripts/getimg.php?src=/wundk/Warnungen/DL00_O.png Data size: 0 bytes Fetch count: 1 Last modified: 2006-05-28 12:03:24 Expires: 1970-01-01 01:00:00 And about:cache?device=disk: Key: http://www.dwd.de/scripts/getimg.php?src=/wundk/Warnungen/DL00_O.png Data size: 7025 bytes Fetch count: 2 Last modified: 2006-05-28 12:03:24 Expires: 1970-01-01 01:00:00 After doing a reload, the full image is loaded. When looking at the properties of the image, it says the image is now 11875 Bytes in size (which is correct). about:cache?device=memory now says: Key: http://www.dwd.de/scripts/getimg.php?src=/wundk/Warnungen/DL00_O.png Data size: 377600 bytes (why? the image is not that big) Fetch count: 1 Last modified: 2006-05-28 12:03:58 Expires: 1970-01-01 01:00:00 And about:cache?device=disk: Key: http://www.dwd.de/scripts/getimg.php?src=/wundk/Warnungen/DL00_O.png Data size: 7025 bytes Fetch count: 2 Last modified: 2006-05-28 12:03:24 Expires: 1970-01-01 01:00:00
Is bug 333275 a manifestation of this?
Locally backing out Bug 330397 fixed this bug here.
Blocks: 330397
No longer depends on: latemeta
Component: Networking → Networking: Cache
QA Contact: networking → networking.cache
Another testcase for this bug here is probably https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&chfieldfrom=2006-07-24&chfieldto=2006-07-25&chfield=%5BBug+creation%5D (it regressed in the same range). The page load of the bug list aborts after the Bug with the UTF-8(?) summary, Bug 345806.
definitely a dupe *** This bug has been marked as a duplicate of 335909 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.