106728 - New Composer doesn't work from Composer window

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[sujay]

using 10/25 trunk build

1) launch netscape
2) launch composer
3) click on New

doesn't bring up new window. also File | New COmposer page doesn't work
either.

Comment 1

[Akkana Peck]

Kathy and I were also seeing that yesterday, though we thought it might just be
part of the focus problems we were seeing (toolbar not enabled until you type
something).  As far as we know it's new on the 10/24 build.

Comment 2

[sujay]

can we please get this fixed....bad regression...

Comment 3

[Charles Manske]

Strange, but the New command seems to be working in my debug build today.
Maybe related to bug 106733?

Comment 4

[Charles Manske]

Attachment: Remove unused nsNewEditorCommand from Composer code

Comment 5

[Charles Manske]

The patch may be unrelated to the reported problem, but the code for cmd_newEditor
is in utilityOverlay.xul and utilityOverlay.js, so the code we had in editor
was not used and is misleading.

Comment 6

[kinmoz]

Comment on attachment 55368 [details] [diff] [review]
Remove unused nsNewEditorCommand from Composer code

sr=[e-mail]

Comment 7

[kinmoz]

Uh that should've been an sr=[e-mail] as long as mail compose isn't
relying on that command.

Comment 8

[Charles Manske]

All modules tested, and the File | New | Blank window to edit command works 
everywhere after removing Composer's nsNewEditorCommand command

Comment 9

[Charles Manske]

The original bug seems to have disappeared on its own or was fixed by some 
other problem. But the unused command was removed as a generally "good thing
to do."

Comment 10

[sujay]

verified.

Comment 11

[sujay]

REOPEN...still not working in 10/31 trunk build on windows.

Comment 12

[Charles Manske]

Frustrating. Definitely not an editor problem! Does not occur in build from 
10/29.

Comment 13

[Charles Manske]

Clarifying the summary

Comment 14

[Charles Manske]

I can't reproduce this in my debug build; tree pulled at 2pm 10/31/01

Comment 15

[michael wendell]

I am still seeing this problem on Win 2k using yesterday's trunk build (2001103103).

Comment 16

[sujay]

I also still see this problem in today's 11/1 trunk build.
its definitely a problem.

Comment 17

[Charles Manske]

Upon further consideration, I'd like it if you didn't remove these lines:
-  <separator class="groove"/>

in EdHLineProps.xul, EdInsertChars.xul, and EdPageProps.xul.
They are all near the bottom of the dialog, just above:
-  <!-- from global dialogOverlay -->
-  <hbox id="okCancelButtonsRight"/>

Comment 18

[Charles Manske]

Please ignore last comment -- wrong bug!

Comment 19

[sujay]

cc: Tucson QA on this bug...

Comment 20

[sujay]

John/Sara, any idea why this is broken in composer?

Comment 21

[John Morrison]

I don't specifically know. However, if you look at the dom tree with the DOM 
Inspector, somehow the original declaration (from editorOverlay.xul) has been
stripped down to the equivalent of this: 
   "<menuitem acceltext="Ctrl+Shift+N"/>"

So, with no command to process, you get no action from clicking that menuitem.
But, don't know why the model has been broken in that way. I'd review the 
checkins for the window of time in which this got broken.

Comment 22

[Charles Manske]

Comment on attachment 55368 [details] [diff] [review]
Remove unused nsNewEditorCommand from Composer code

This change was checked in

Comment 23

[Charles Manske]

Attachment: Fix

Comment 24

[Charles Manske]

This turned out to be easy!

Comment 25

[Ryan Cassin]

r=[e-mail]

Comment 26

[kinmoz]

Comment on attachment 56499 [details] [diff] [review]
Fix

sr=[e-mail]

Comment 27

[sujay]

is this bug fixed yet?

Comment 28

[michael wendell]

This appears to be fixed, and is working for me using the 2001110603 build on
Win 2k.

Comment 29

[sujay]

this also worksforme now in the 11/6 builds on windows.

Comment 30

[Charles Manske]

checked in

Comment 31

[sujay]

verified in 11/6 build.