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)
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.
Reporter | ||
Comment 1•23 years ago
|
||
I checked in 5-14-12 Linux build. I could reproduce it. This problem has been
there for a while.
Keywords: intl
Comment 2•23 years ago
|
||
Is there a workaround? The menu is disabled even after you open a new compose
window, or the problem is local to that window?
Reporter | ||
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
Shanjian, where is the code to disable the charset menu after the user types?
Comment 5•23 years ago
|
||
It not reproducible on 03-16 trunk build. So it might cause by some changes
between 03-16 and 04-20.
Comment 6•23 years ago
|
||
Adding Xianglan, she migtht have builds between 03-16 and 04-20.
Reassign to yokoyama.
Assignee: nhotta → yokoyama
Reporter | ||
Comment 8•23 years ago
|
||
This is not reproduciable in 2001-03-36-05 Linux Trunk build.
Reporter | ||
Comment 9•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
Linux specific. I can't reproduce this on Windows.
Assigning to shanjian.
Shanjian : please take a look. Thanks
Assignee: yokoyama → shanjian
Comment 11•23 years ago
|
||
Setting TM = M0.9.2 | P2, because this is a regression.
Priority: -- → P2
Target Milestone: --- → mozilla0.9.2
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
Is only encoding menu cause this problem? How about after you SAVE? I know save
will disable some menu.
Reporter | ||
Comment 15•23 years ago
|
||
I cannot reproduce this other than character set menu so far.
Comment 16•23 years ago
|
||
If really linux-only, this may be a linux-specific focus issue. Ccing blizzard.
Comment 17•23 years ago
|
||
pdt+ base on 6/11 pdt meeting.
Updated•23 years ago
|
Whiteboard: [PDT+]
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
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
Comment 22•23 years ago
|
||
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?
Comment 23•23 years ago
|
||
Comment 24•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
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
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
I think this is a Linux only bug, right Teruko?
Comment 30•23 years ago
|
||
help. kin, simon, beth: this bug either needs a new milestone or a new owner.
I'm probably not the right owner anyway...
Comment 31•23 years ago
|
||
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
Assignee | ||
Comment 33•23 years ago
|
||
Appears to be fixed by all the recent focus fixing
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 34•23 years ago
|
||
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong
You need to log in
before you can comment on or make changes to this bug.
Description
•