Select View -> Page Source for any page Select View -> Character Coding -> Unicode The window becomes blank. Javascript error: popup has no properties, chrome://messenger/content/mailNavigatorOverlay.xul Line: 110

Forgot to say: seen the first time in night build of 02 April 2002 Now using night build 2002040706

I see some changes on April 2nd by blakeross "108099, 75338 - overhaul of main menu and context menus. r=ben sr=hewitt a=asa/brendan" cc blakeross and others

Confirm it reproduce on WinXP-SimpChinese and Mac 10.1.3 too, change OS to ALL. It's not only existing when change charset to Unicode but also any charset other than current document. -> nsbeta1

Change milestone for keeping it under my radar.

I saw the following on the JavaScript console "Error: showMessage" is not defined", not sure where it came from. search lxr.mozilla.org to find it.

nsbeta1-

Personally, we should remove the Char coding menu all together from the Source window if we aren't going to fix this bug. Moreover, if I recall correctly, the Char coding menu in the Source window never worked before.

> if I recall correctly, the Char coding menu in the Source window never worked before. No, it worked before (auto-detect, manually force...), at least last month. It is a recently regression, and it's better to fix it. Renominate it as nsbeta1, cause we have a not functional menu item.

>No, it worked before (auto-detect, manually force...), Did it really worked? You could see the text, but it really doesn't do anything after changing the encoding. I checked with NS6.1 and NS6.2. Neither worked.

Yes, on N6.2.1 time, change encoding didn't do anything is because we had a bug 93330 for not working with user forced charset, but auto-detect should works on N6.2.1. And we fixed the user manually force charset bug in trunk build after N6.2.1 released.

understood. thanks ylong.

nsbeta1- not many users uses this feature (charset menu in view source), the user can go to browser and to change charset and then view source again

>nsbeta1- not many users uses this feature (charset menu in view source), the >user can go to browser and to change charset and then view source again Shouldn't we remove it all together then? There is no use for it. One argument I can think of for keeping this menu is: 1) user want to check the encoding for the page while viewing the source Well, I don't think the user _uses_ the Source Window to check the encoding. He/she does it in the browser.

cc shanjian

This could be related to the changes done on Apr 1 (bug #40867) cc rpotts

My patch in bug 122524 doesn't seem to have this bug (I have switched to an overlay sharable between the view-source modes).

moving the TM

*** Bug 153238 has been marked as a duplicate of this bug. ***

simon, can you take a look at this one? yokoyama is too busy. mark nsbeta1+ for m1.2final release and change tm=m1.2beta.

No errors appear in the JS console in up-to-date builds, but the window still goes blank when changing encoding. On the other hand, changing encoding works well in View Selection Source, where it isn't useful because the view source window is in UTF-8, not the original page encoding.

This problem not only happens when change the charset but also when change the auto-detector option ( on 10-08 trunk build).

*** Bug 173792 has been marked as a duplicate of this bug. ***

*** Bug 176700 has been marked as a duplicate of this bug. ***

Does the fix for bug 102437 have any implications for this?

Nope. That code was simply never executed. If it affected this bug in any way, please let me know immediately because that would mean something is deathly wrong somewhere.

The BrowserSetForcedCharacterSet function in browser.js appears to be incompatible with view-source because it calls BrowserReloadWithFlags instead of PageLoader.LoadPage; redefining the function works for me; comments, anyone?

Comment on attachment 105820 [details] [diff] [review] Patch that works for me r/sr=bzbarsky. Nice catch!

Comment on attachment 105820 [details] [diff] [review] Patch that works for me r=shanjian, I remember the change in browser reload to use a flag is to address some concern (speed? form content?). It should not affect source view or it shouldn't matter much.

Thank you for fixing this, Neil. Do you have CVS checkin rights? If not, I will check this in.

The flag in browser is to make sure we get from cache, not from network. View source should be doing this already no matter what.

It might be worth adding a code-level comment to the effect that the function is overriding an existing function in browser.js to avoid this bug. This way, people can learn from there and quickly track any similar troublesome issue in the future.

So, could whoever checks in this patch for me also add that comment? Thanks.

I guess comment 32 implies a "Yes" to the question in comment 29 :-) I will take care of this.

Checked in. Thanks again, Neil!

Verified fixed in 11-20 trunk build.