99185 - Too many composition UI items/widgets/controls are not disabled when sending mail (but should be) [e.g. send button, options menu, attachments pane still wrongly enabled]

Status: NEW

(SeaMonkey :: MailNews: Composition, defect)

Description

[(not reading, please use [e-mail] instead)]

disable more ui items when sending mail

for example, I can:

1) change the "sending" identity
2) click on any toolbar button:  send, address, attach, spell, save
3) use the html format toolbar (elements on it are still enabled)
4) use the menu items.  for example, Options | Format  and Options | Priority.

Comment 1

[[e-mail]]

Out of interest, why not make the send progress dialog modal?

Comment 2

[jglick]

I agree with neil. This is how 4.x worked also. User would have to cancel the 
send operation first before being able to change anything.

Comment 3

[Matthew T (active 1999-2002)]

> why not make the send progress dialog modal?

Because progress windows should never be modal. (iTunes is the only app I've
seen break this rule, and it's a royal pain.) If the task itself is modal to the
window, you should be showing progress in the window rather than opening a
separate progress window for it.

Comment 4

[timeless]

Nero appears to do something similar, it creates a progress window and hides 
the main app window (that's pretty equivalent to modal).

If you disable nearly all elements of a window then the user has to scan 
through the large window to see what few things can be done.  Usually menubars 
aren't disabled, which means the user can hunt through 5 long menus to see 
what other things can be done.

If all you have is a progress indicator, a text description of the 
progress/status and one action (cancel/stop/abort) and if that's really all the 
user can do or look at then it seems reasonable to help the user by putting 
them together in an outlined section. (personally, i'd use a sheet, but 
unfortunately that feature of macosx hasn't taken over the world.)

Comment 5

[Olga]

I change severity from Minor to Enhancement for future decision.

Comment 6

[(not reading, please use [e-mail] instead)]

taking all of varada's bugs.

Comment 7

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 8

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 9

[Thomas D. (:thomas8)]

This bug still exists.

This bug is reported against MailNews Core.

Thunderbird Bug 271730  - Widgets in the compose window should be disabled while the message is being sent

Not sure if duplicating against the core bug would be good idea, just makes them harder to find than bugs in Thunderbird Product and will thus lead to more dupes.

Comment 10

[Thomas D. (:thomas8)]

This is a bug (not enhancement), as results of changing the msg while sending are not predictable.

Comment 11

[:aceman]

Re comment 9: At the time stis was filed there was no TB.
Which app uses this Composition in MailNews Core? Is it Seamonkey?

If there is none, then this could be duped against that TB and it could still solve your concern.

Comment 12

[[e-mail]]

This bug is so old that it must have originally been filed against the Mozilla Application Suite, but it seems to be in the wrong component, it should be in

Comment 13

[Thomas D. (:thomas8)]

Amid the products/components confusion, let's keep the reference to the corresponding TB bug in "See also" at least...