All users were logged out of Bugzilla on October 13th, 2018
Edit Page does not load the page with meta charset (CJK) in Composer. Steps of reproduce 1. Go to above URLs 2. Select menu File|Edit page Does not load the page in Composer. I tested the following sites. http://home.netscape.com/ja/ http://home.netscape.com/ko/ http://home.netscape.com/zh/cn/ http://www.zdnet.co.jp/eweek/ These page has Meta charset info. Linux build only works fine loading page http://home.netscape.com/ja/ , but it failed other sites. Also, Win32 and Mac build failed all. I tested the western page, http://home.netscape.com/ and http://home.netscape.com/de/ they works fine. The page without meta charset info will be loading fine in all platform, such as http://www.yahoo.co.jp/ Tested 2000-07-12-09 Win32, Mac, and 2000-07-12-11 Linux build.
It may be for any non iso-8859-1 page. Ive attached a simple HTML file labeled iso-8859-2 w/only ASCII text. <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2"> </head> <body> test page in iso-8859-2 </body> </html>
Nominating this for nsbeta2. This means you cannot edit any non iso-8859-1 page that is correctly labeled.
Reassign to editor group.
Assignee: nhotta → beppe
Teruko, was this working before and broken recently?
Putting on [nsbeta2+] radar for beta2 fix.
assigning to jfrancis
Assignee: beppe → jfrancis
Severity: normal → major
Priority: P3 → P1
Target Milestone: --- → M17
Status: NEW → ASSIGNED
I spend some time here. If you set a break point at 1. nsHTMLDocument::StartDocumentLoad and 2. nsObserverBase::NotifyWebShell in browser, if you hit a page with meta charset which have different charset value than the default (your http://home.netscape.com/ja is in Shift_JIS and if your normal default charset should be "ISO-8859-1"), then the following is what you should see 1. stop at nsHTMLDocument::StartDocumentLoad, it find the default charset is "ISO-8859-1" and it will ask the parser to load as "ISO-8859-1" 2. stop at nsObserverBase::NotifyWebShell, it find the meta charset is "Shift_JIS" it will ask the WebShell to reload with "Shift_JIS" 3. stop at nsHTMLDocument::StartDocumentLoad, it find the webshell said "Shift_JIS" is the one it should reload, it tell the parser to load "Shift_JIS" This behave correctly in the browser However, for composer, I see the following 1. stop at nsHTMLDocument::StartDocumentLoad, it tell parser to load "ISO-8859-1" 2. stop at nsHTMLDocument::StartDocumentLoad, it tell parser to load "ISO-8859-1" 3. stp[ at nsObserverBase::NotifyWebShell, it tell the webshell to reload with Shift_JIS, then nothing happen, the composer seems keep looping there. I don't know why there are two stop in 1. and 2. I am not sure that is the same document or not.
I try to just call "Task:Composer", it stop at the nsHTMLDocument::StartDocumentLoad twice even it is a blank. So I think the problem is the missing of the reload itself.
i've seen the same as Frank. It works in the m16 build. 7/8 build wont launch for me. Bug reported against 7/12 build. I think changes to nsWebShell.cpp are the culprit. investigating...
This could happen eailer than 7/12. Don't get fooled by that date. 2000070208 window build is ok
2000070508 window build show the problem
2000070320 window build is ok
2000070408 window build is ok
2000070420 window build have problem. therefore, we can conclude the problem introduced between July 4 8:00AM PST and July 4 8:00PM
I back out radha's change and rebuild it, the problem go away. mozilla/webshell/src/nsWebShell.cpp r=1.473 (comment out #define SH_INFRAMES 1) mozilla/xpfe/browser/src/nsBrowserInstance.h r=1.30 (comment out #define SH_IN_FRAMES ) mozilla/docshell/base/nsDocShell.h r=1.63 (comment out #define SH_IN_FRAMES 1 ) Here is the bonsai to the changes of that period http://bonsai.mozilla.org/showcheckins.cgi?&treeid=SeaMonkey&batchid=281 here is the easiest reproduce procedure- 1. visit http://home.netscape.com/ja 2. you should see page loading 3. Select "File:Edit Page" expect result- new composer window open, the page show the same as in the browser with extra composer decoration actual result- the composer window keep loading the page
thanks Frank. Sounds like we duplicated a little work, but you beat em to it. Radha's changes were what I suspected as well.
I have a fix for the reload() not happening in international pages. I will attach it soon. Frank can you check if that fixes the composer too. Thanks
I have problem to apply your patch (patch failed.) Can you give me a updated version ?
radah, I have problem with my build environment now. can you verify by yourself ? IT should be easy, just visit http://home.netscape.com/ja (if you do not have Japanese font, you will see some ? mark display there). do a "File:Edit Page", if your fix is good, you should see exactly the same thing in the composer, otherwise, the page won't finish loading in composer. (If you need me to verify, I probabaly can do it tomorrow). Should we assign this bug to you ? reassign to radha
Let me know if you need me to try out the changes...
I have checked in fix for this. I could bring up the page in the composer. jfrancis, it will be good if you can pull the changes to nsDocShell.cpp and make sure I haven't missed anything.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
I tried out the test case and it works fine now, although it takes several seconds to load for some reason.
I verified this in 2000-07-18-10 Win32, Mac, and Linux build.
Status: RESOLVED → VERIFIED
OS: Windows 3.1 → All
You need to log in before you can comment on or make changes to this bug.