User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050831 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050831 Firefox/1.0+ When I visit the site http://www.rose-des-caps.dyndns.org/~gcog/photos/index.php?album=./2005/Pyr%E9n%E9es/Vignemale%20-%202ieme using Deer Park (either the Alpha 2 or one of the daily builds) the left frame remains empty. If I use FireFox 1.06/IE/Opera, the frame is correctly displayed. Reproducible: Always Steps to Reproduce: Visit the url mentioned above using a Deer Park alpha2 or a daily build (at least the builds of August 23/30/31 exhibit the problem) A preliminary analysis of the problem: The url above refers to a frameset that contains <FRAME SRC="index.php?page=left&album=./2005/Pyrénées/Vignemale - 2ieme&expand=" NAME="left"> <FRAME SRC="index.php?page=right&album=./2005/Pyrénées/Vignemale - 2ieme&expand=" NAME="right"> Note the e-acutes in the URL. When I visit the page with Deer Park and look at the properties of the left frame (this frame->view frame info), it tells me that its url is http://www.rose-des-caps.dyndns.org/~gcog/photos/index.php?page=left&album=./2005/Pyr%C3%A9n%C3%A9es/Vignemale%20-%202ieme&expand= but the e-acutes (%A9) are now prefixed with %C3 for some reason, rendering the URL invalid. The same frame info form tells me that the Encoding is ISO-8859-1, and that the referring url is http://www.rose-des-caps.dyndns.org/~gcog/photos/index.php?album=./2005/Pyr%E9n%E9es/Vignemale%20-%202ieme i.e. without those %C3's. The logs of my internet proxy confirmed that the URL deer park tries to load for the left frame indeed contains those %C3s. So why does Deer Park insert those %C3s that break the frame's url? Note that there are some bugs (e.g. #169575) that seem to describe similar issues but 1) they are old (from 2002/2003) and 2) this particular page works fine with FireFox 1.06 (and other browsers) so it is a regression.
This could be fallout from the fix for bug 261929.
Reporter: using about:config, can you please try changing the value of the "network.standard-url.encode-utf8" preference from true to false? If that fixes the problem, then Jesse would be correct in identifying the cause of this behavior. Thanks!
Yep, setting network.standard-url.encode-utf8 to false makes things work, the frame is now correctly loaded. No more %C3's to be seen...
*** This bug has been marked as a duplicate of 284474 ***
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.