Closed Bug 38673 Opened 20 years ago Closed 20 years ago

Insertion of certain items as first element disables buttons on Toolbar


(SeaMonkey :: General, defect, P3)

Windows NT


(Not tracked)



(Reporter: shrir, Assigned: saari)



(Whiteboard: [dogfood-] [nsbeta2+] fix found)

I see this on all builds for today (2000050908)

Install and launch the browser.
Select Tasks->Composer
Now without typing anything in the blank space, press the "Table" button on the 
Observe a 'Create Table' dialog open up.
Do not enter anything, just press OK to close the dialog.
After the dialog closes, observe that all buttons on the Toolbar appear faded 
with horizontal lines across them except for the "New" button. However, all 
buttons are functional.
assigning to Charley for debugging and setting to M17
Assignee: beppe → cmanske
Target Milestone: --- → M17
Changed "fades" to "disables" 
Simon: Something is funky with the enabling/disabling mechanism. Not only 
are toolbars disabled, but just about all commands (look at menus).
I've seen this happen after other operations. It seems saving the page to
a file reenables the commands.
Assignee: cmanske → sfraser
Summary: Pressing OK on Insert Table dialog fades buttons on Toolbar → Pressing OK on Insert Table dialog disables buttons on Toolbar
This could be a focus problem; if focus isn't set to the content when the dialog 
is dismissed, our controller might not get called to update commands.
this sounds a lot like a bug I filed a while back about inserting an image as the 
first thing in a new document.  I think Joe has that bug.
*** Bug 39066 has been marked as a duplicate of this bug. ***
I see this same behavior when I add an image as the first element or if I add a 
named anchor as the first element.

I'm recommending that we fix this for beta2 since it's not uncommon for people to 
have images, tables, or other items as the first item they insert into a document 
and there is NO way (that I've figured out) to get back to a normal working 
Keywords: dogfood, nsbeta2
Summary: Pressing OK on Insert Table dialog disables buttons on Toolbar → Insertion of certain items as first element disables buttons on Toolbar
[dogfood-] [nsbeta2+]
Whiteboard: [dogfood-] [nsbeta2+]
Target Milestone: M17 → M16
OK, I understand now.

We get into this bad state when the content of the editor window is not focussed 
when the document is modified for the first time. What happening is this:

1. The doc is unmodified.
2. You bring up the table dialog (so the editor window loses focus).
3. On confirming the table dialog, code causes the editor doc to become modified
   (the call to   editorShell.CloneAttributes(tableElement, globalElement);
   in EdInsertTable.js: onOK() causes this)
4. A doc state callback is called, which calls NotifyDocumentStateChanged() in
   the editor JS. This calls window.updateCommands("create"), but at this point
   the focus is still bad. No controller is found for most of the commands, so
   the commands are disabled.

5. No later callback reenables the commands.
I'm fixing by putting in a hacky focus() call. Ideally, we should delay firing 
the doc modified notifications until the dialog is gone, and we have re-focussed 
the editor window content. It seems that we need to optimize the UI updating in 
Closed: 20 years ago
Resolution: --- → FIXED
when did this fix go in?? I just grabbed the 5/30 build and its still not
fixed...should I reopen?

yes..I still see this on windows(2000053008). Works fine on mac and linux 
(2000053008). changing OS: Windows
OS: All → Windows NT
Hardware: All → PC
Resolution: FIXED → ---
If this is Windows-only, then it can't be my bug. Over to the focus guys.
Assignee: sfraser → saari
I can click in the doc and then bring up the table dialog and still see this.
Which implies it has something to do with the document changing state more than
focus, but I'll try and track it down.
Component: Editor → Browser-General
Does composer create the editor document immediately, or do you have to modify
it first like all the other editor instances?
cc sfraser; I'm not 100% convinced it's a focus issue.  It does work on Mac 
though (I can't reproduce this problem anymore on Macintosh).
I see the same series of focus events if I type in the doc first and then bring
up the table dialog or if I just bring up the table dialog. It looks like focus
is behaving the same in both cases.
Whiteboard: [dogfood-] [nsbeta2+] → [dogfood-] [nsbeta2+] fix found
*** Bug 42206 has been marked as a duplicate of this bug. ***
M16 has been out for a while now, these bugs target milestones need to be 
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
verified in 6/23 build.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.