Netscape Build : 12/04/2000 Platform : Solaris2.8(sparc) To reproduce, (1) Launch the browser (2) Launch the composer. (3) Insert a table by clicking on Table->Insert->Table. (4) A table insert window pops up.Click on 'ok' button. (5) Position the cursor on table just created. Right click on the mouse button. This will display side menu. (6)Look into 'Table Select','Table insert','Table Delete' options. Expected result: You should see all the sub-options enabled for above options. Actual result: The sub-options are disabled.
Happens on Linux, too. Are the options enabled on windows/mac?
Options are disabled on Win32 too.
Changing Platform and OS from Sun/Solaris to All/All since it seems to be xp.
Passing off to email@example.com.
I can't reproduce this on Windows NT with either the RTM NS6 build or my current debug build.
Hmmm, it's working in my 12/15/00 Win32 trunk debug build too. Akkana, can you do me a favor and see if it's fixed on Linux too?
In today's linux build, clicking on the ok button in the table dialog does not insert a table (and the dialog doesn't go away). I can't test this bug until that problem is fixed. Will file a bug on that problem.
I think someone has done some general damage to the dialog system! Other problems are cropping up, like for the Color Picker (bug 62947)
Unless I get some confirmation about this bug, it will be marked "WORKSFORME".
The table insert dialog is working again, so I can test this now, and on linux, I do see the problem as described here: under Table Insert, all options except Table are greyed out; under Table Delete, all options are greyed out.
Akkana: So you see this only on Linux? Any other menu items grayed out that you think shouldn't be? It's really strange if this is only on Linux.
I haven't tried it on anything but Linux. I don't notice anything in the main menubar that's greyed out that shouldn't be (though I've seen chronic problems in the past with copy/paste being greyed out when they shouldn't, but I didn't see that when I checked just now) but I'll be glad to check particular menus if you have any you want checked.
Akkana: Are other submenu items enabled appropriately, like those in the Format menu? The code to enable most of the table submenu items is this: return (window.editorShell && window.editorShell.documentEditable && null != window.editorShell.GetElementOrParentByTagName("table", null)); GetElementOrParentByTagName is used in many places; you couldn't bring up Table Properties if that doesn't work. So there's nothing in editor code that suggests why this problem occurs. Changing OS to just Linux.
Another Linux-only problem. Maybe a dup of 63378?
moving to moz0.9.1
*** Bug 71412 has been marked as a duplicate of this bug. ***
1) The OS of this bug should be set to ALL as said by firstname.lastname@example.org 2000-12- 08 09:54 2) Description of Bug 71412 is better: "Table Select and Table Delete context menu subitems don't update until Table mainmenu is used" From bug 71412: Seen on Windows 2000, Build 2001030804 installer Way to reproduce: a) Open new Composer window b) Insert a table c) right-click on the table, and choose 'Table Select' -> Expected: subitems Enabled (Table, Row, Column ..) Result: subitems are disabled. d) goto the mainmenu 'Table' and look in the Select submenu All subitems are enabled e) Close mainmenu, go back to the table and rightclick again. f) Go back to the 'Table Select' submenu. This time all items are enabled. ------- Additional Comments From Dean Tessman 2001-03-09 08:59 ------- ...It appears that the context menu doesn't have any enabling/disabling code. It all seems to be in the Table menu. If I pop down the Table menu and then go back to the table context menu, the commands are properly enabled...
Moving platform/os back to all/all, since I'm seeing this on Win2K. Based on my observations, I'd also like to re-summarize to "Table Select and Table Delete context menu subitems don't update until Table mainmenu is used", but I'll leave that for someone else to do.
This sounds like something in cmanske's ballpark. Reassigning back to cmanske.
I think I finally see what the problem is!
Kin or Akkana: can one of you please test this simple fix on Linux? (I'm working at home today.)
Very easy - would like to fix for 8.1
Created attachment 27479 [details] [diff] [review] Update patch: removed command updates that are done by "goUpdateTableMenuItems"
Fix checked in and should be in 3/13 build. Please help test this on all platforms.
Can't test on today's build, the toolbar items (including table) are all greyed out.
Moving to 0.9 to get off the 0.8.1 radar. Still needs testing to confirm fix on all platforms.
Following email@example.com's repro instructions of 2001-03-09 09:24, I do not see this in the 3/13 build after pulling joki's fix for bug 71224. (I have to type something in the composer window before I can insert a table, though, to make the toolbars enable.)
I can't reproduce the problem after applying the patch. Windows 2000.
Akkana: So do you see a caret in content area when you first start Composer? I don't see that problem in WinNT. Everything is just fine again. So maybe we still have initial focus problems just in Linux?
Yes, I do see a blinking caret when I start up, even when the toolbar buttons are not enabled.
I haven't received any reports that this bug still exists. Marking fixed.
Just finally downloaded a new build. Works well. Verifying using 2001031604 on Win2000.