Closed Bug 82257 Opened 23 years ago Closed 23 years ago

After changing character coding menu for a new document, menu items under File become disable in Composer

Categories

(Core :: Internationalization, defect, P2)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: teruko, Assigned: saari)

Details

(Keywords: intl, regression, Whiteboard: [PDT+])

Attachments

(1 file)

In composer, after you change the character coding menu to something other than western (ISO-8859-1), the menu items under File (except "New Composer page", "New", and "Print Plus" become disable. Steps of reproduce 1. Open Composer 2. Select menu View|Character coding->More->East Asian ->Japanese (Shift_JIS) 3. Type something in composer 4. Select menu File The menu items under menu File (except "New Composer page", "New", and "Print Plus" become disable. You cannot save the document. You do not need to type anything in the step #3. After you change the character coding menu, the menu items under File are disabled. This happens in Linux only. Tested 2001-05-22-13 Linux build.
I checked in 5-14-12 Linux build. I could reproduce it. This problem has been there for a while.
Keywords: intl
Keywords: nsbeta1
QA Contact: andreasb → teruko
Is there a workaround? The menu is disabled even after you open a new compose window, or the problem is local to that window?
The menu is not disabled after you open the composer. The problem happens after you change the Character coding menu. After you change the character coding to something other than default encoding, you cannot save it. I checked this on 6.0 rtm linux build. This does not happpen. I checked this on 4-20 linux build. This happens.
Keywords: regression
Shanjian, where is the code to disable the charset menu after the user types?
It not reproducible on 03-16 trunk build. So it might cause by some changes between 03-16 and 04-20.
Adding Xianglan, she migtht have builds between 03-16 and 04-20. Reassign to yokoyama.
Assignee: nhotta → yokoyama
Sorry, I don't have the builds in that period.
This is not reproduciable in 2001-03-36-05 Linux Trunk build.
I cannot reproduce this in 2001-04-01-05 Linux Mtrunk, nor 2001-04-10-16 Mozilla build. I cannot find the builds between 4-10 to 4-20 in sweetlou.
Linux specific. I can't reproduce this on Windows. Assigning to shanjian. Shanjian : please take a look. Thanks
Assignee: yokoyama → shanjian
Setting TM = M0.9.2 | P2, because this is a regression.
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2
This problem can also be seen on HPUX. I spent some time on this, and there is a interesting behavior need mentioning. If composer is started without browser (ie. mozilla -edit), problem will not be seen.
Status: NEW → ASSIGNED
This is really a strange problem, and it might be very hard to trace. Here is a summary of what I found so far. 1, If the composer is started as standalone application (without browser), everything works fine. 2, If composer is brought up through browser, selecting any of character set related menu will cause an assertion in nsXULCommandDispatcher.cpp:146, in "NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && window, rv);" This does not happen in case 1. 3,If composer is brough up through browser, we will have this problem.Many menu items will be disabled. 4, When a charset is selected in composer, the calling relation is: ComposerMultiplexHandler(event) in charsetOverlay.js calls EditorSetDocumentCharacterSet in editor.js calls nsEditorShell::SetDocumentCharacterSet in nsEditorShell.cpp calls nsEditor::SetDocumentCharacterSet in nsEditor.cpp A more intersting behavior is, if I comment out following 2 statement in nsEditorShell::SetDocumentCharacterSet " if (editor) res = editor->SetDocumentCharacterSet(nsAutoString(characterSet));" The problem does not happen, But if I keep this 2 statements, even if I return immediately from nsEditor::SetDocumentCharacterSet, the problem still can be seen. This is really hard for me to understand. 5, The last point, this problem only happens on Unix platform (Linux, HPUX). If we could find out who disabled those menus, that might give us some hint to fix it.
Is only encoding menu cause this problem? How about after you SAVE? I know save will disable some menu.
I cannot reproduce this other than character set menu so far.
If really linux-only, this may be a linux-specific focus issue. Ccing blizzard.
pdt+ base on 6/11 pdt meeting.
Whiteboard: [PDT+]
reassign to ftang
Assignee: shanjian → ftang
Status: ASSIGNED → NEW
nhotta, please help to look at it.
Assignee: ftang → nhotta
In nsPlaintextEditor::SetDocumentCharacterSet, there are lines which get a list of META tags and find a current META charset. It seems like that code is causing the problem although I don't know how. But those lines are not necessary when the document is empty. Because this problem only happens when the document is empty, I am going to disable the code when the document is empty.
I tested 6.1 PR1, when I edit an existing file and change charset menu then the problem does not happen. So this bug is only applied to a new document.
Status: NEW → ASSIGNED
Summary: After changing character coding menu, menu items under File become disable in Composer → After changing character coding menu for a new document, menu items under File become disable in Composer
This is a separate issue but set charset to existing document does not seem to be working. For example, using NS6.1 PR1, I tried "edit page" for home.netscape.com/ja and changed charset to ISO-2022-JP (or EUC-JP). After using the menu, the characters in the page turned to question marks and META charset was unchanged as Shift_JIS after I save the document. IQA, is there a bug about that?
As far as I know, we don't have a bug exactly same as Naoki's 2001-06-15 13:34 comments, although we have a similar bug 79735. We might want to file another bug for that if we really don't have.
I found that the code to set a new META charset also sometimes causes the menu disabling problem on Linux. So I need additional changes.
It looks like CreateNode causes the problem. The menu is not disabled if that is not called. http://lxr.mozilla.org/seamonkey/source/editor/base/nsPlaintextEditor.cpp#310 In case of the document is empty, some kind of pre-setting might be required before calling the CreateNode but I don't know the detail about this (node, head list etc.). I reassign this to editor group.
Assignee: nhotta → beppe
Status: ASSIGNED → NEW
assigning to jfrancis
Assignee: beppe → jfrancis
If this bug is a linux-only problem, then my guess is that it's a focus issue. Composer is likely marking the document dirty when it creates the <meta> node, which will cause a bunch of command updating to happen. If focus is set incorrectly at that time, controllers for some commands won't be found, and the commands will get disabled. Since this works OK on Windows and Mac, I think this bug should really go to blizzard.
I think this is a Linux only bug, right Teruko?
help. kin, simon, beth: this bug either needs a new milestone or a new owner. I'm probably not the right owner anyway...
just talked with joe, he stated that simon has been poking around on this, Simon please continue the debug and get this to the correct owner
Assignee: jfrancis → sfraser
Focus, -> saari.
Assignee: sfraser → saari
Appears to be fixed by all the recent focus fixing
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong
Fixed verified on 06-25 0.9.2 branch 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: