Please report any other irregularities here.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20060910 SeaMonkey/1.0.5 Build Identifier: 2006-09-20-04-trunk and later builds View Source shows strange formed thing for js-generated documents. Reproducible: Always Steps to Reproduce: 1. open the testcase. 2. click one of the links selecting charset. small new window will come up and little text will be shown. 3. try Page Source from View menu or ctrl+u. Actual Results: Strange formed plain thing comes. Expected Results: Syntax highlighted easy readable source should be shown. View Selection Source (DOM Source) still works fine. I'm seeing this on WinXP/Linux/MacOSX. testcase and screenshot are following. Range of builds to reproduce: 2006-09-19-04-trunk and earlier builds work fine. 2006-09-20-04-trunk and later builds including 2006-10-29-04-trunk do not work.
setting Version Trunk. adding regression keyword.
Version: unspecified → Trunk
Created attachment 244022 [details] testcaset reattaching testcase. previous one was not good to attach.
Attachment #244019 - Attachment is obsolete: true
Sounds related to bug 286365.
Tae: You're right. The testcase I've attached is not minimum. It came from other past bug, had included i18n thing. When you click "no charset" link, generated doc will be more minimal, even while DOCTYPE line would not be needed. Now, I've tried local build with 2006-10-29-04 cvs, backed out attachment 238893 [details] [diff] [review] for bug 286365. The problem has gone. Also, View Source on Feed View issue, mentioned in bug 286365 c#12, worked.
Happens with the testcase 244022 on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061030 Minefield/3.0a1
Here's what I got so far. It looks like the dynamically created document is internally handled as UTF-16 but the Character Encoding setting defaults to UTF-8. That setting is a lie, which you can test by doing the following: 1. Open the window 2. Go to View->Character Encoding 3. It should be set to UTF-8, so just click the same setting. 4. The page changes into gibberish even though you haven't changed anything. 5. Now, click UTF-16, the page returns to normal. Also notice that the specified content-type is totally ignored. View-source is simply believing the lie that it really is UTF-8. Set the charset to UTF-16 first and then view the source. Everything should work fine. We need to either change the default charset to UTF-16 or handle the content as UTF-8 or make it respect the content-type. The best is to probably make it respect the content-type and then default to UTF-8 if none is specified.
Confirmed against testcase. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20061219 Minefield/3.0a2pre Latest 2.x release doesn't display this behavior, so we need to narrow down the regression window.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Forward-duping to bug 382074, which has a clearer summary and comments from bz. Sorry for not finding this one earlier.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 382074
You need to log in before you can comment on or make changes to this bug.