Page 1 of 1

At last, the nastiest bug (caching) fixed in NetFront 3.2!

PostPosted: Apr 28, 2005 @ 4:42pm
by Menneisyys
As I've posted to several PPC boards, I've found a nasty bug in NetFront 3.1 (from now on: NF) with flaky caching/reloading, which makes using NF 3.1 far more bandwith-consuming than an in this respect bugless PPC browser (for example, Pocket Internet Explorer (PIE) or NetFront 3.2).

If you navigate to a previously visited page which still exists in NF's cache, the changes to the page will NOT be visible at all - the server always answers with a 304 Not Modified message. I've tested this several times with modified HTML pages. The changes have never been displayed without explicit reloading. If you force a reload of the page (click the Reload icon), on the other hand, all files will be downloaded again, regardless of their being modified or original, resulting in excess (and, again, unnecessary) bandwidth hit. In this respect, both PIE and NF 3.2 is much better.

Fortunately, in the latest (still Japanese only) version of NF, 3.2, this bug has been corrected.

PostPosted: May 1, 2005 @ 3:22pm
by Menneisyys
I've countinued exploring Netfront Version 3.2.

Version 3.2, unlike its predecessor, it allows for relocating the cache - just found it out by examining its registry keys. That is, the cache may be in the (fast to write to) RAM, while the app itself may be in ROM.

See HKEY_CURRENT_USER\Software\access.co.jp\NetFront3\BrowserPref

Incidentally, Version 3.2 has a lot of other, new settings. Much as the above entry only contained "NF3RendererType", "NF3BuildNo", "NF3CoreType" and "LicenseID" in 3.1, version 3.2 is far more configurable. Even without knowing Japanese, based on the Registry, it does seem that the new version is indeed a great leap forward.

Before you ask: I've tried to hack version 3.1 by importing the 3.2-specific L2Cache* values into the 3.1 registry to enable cache relocation; without success. 3.1 doesn't make use of them.

PostPosted: May 3, 2005 @ 3:42am
by The Blur