Closed Bug 136322 Opened 22 years ago Closed 22 years ago

Character coding menu doesn't work in Source window (it becomes blank!)

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.2beta

People

(Reporter: scoda, Assigned: smontagu)

References

Details

(Keywords: intl, Whiteboard: [adt3])

Attachments

(1 file)

Patch that works for me
723 bytes, patch
shanjian
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
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
Keywords: intl
QA Contact: ruixu → ylong
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
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbeta1
OS: Linux → All
Hardware: PC → All
Change milestone for keeping it under my radar.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
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-
Keywords: nsbeta1 → 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.
Keywords: nsbeta1- → nsbeta1
>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
Keywords: nsbeta1 → nsbeta1-
>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
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 153238 has been marked as a duplicate of this bug. ***
Blocks: 157673
simon, can you take a look at this one? yokoyama is too busy.
mark nsbeta1+ for m1.2final release and change  tm=m1.2beta.
Assignee: yokoyama → smontagu
Status: ASSIGNED → NEW
Keywords: nsbeta1- → nsbeta1+
Whiteboard: [adt3]
Target Milestone: mozilla1.0.1 → mozilla1.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!
Attachment #105820 - Flags: superreview+
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.
Attachment #105820 - Flags: review+
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!
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Depends on: 180372
No longer blocks: 157673
Verified fixed in 11-20 trunk build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: