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 toolbar. 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

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.

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 state.

[dogfood-] [nsbeta2+]

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 general.

when did this fix go in?? I just grabbed the 5/30 build and its still not fixed...should I reopen? Shrirang?

yes..I still see this on windows(2000053008). Works fine on mac and linux (2000053008). changing OS: Windows

If this is Windows-only, then it can't be my bug. Over to the focus guys.

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.

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.

*** 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 updated.

fixed

verified in 6/23 build.