can't dismiss spellchecker and avoid having the mail compose message sent.



MailNews: Message Display
17 years ago
13 years ago


(Reporter: chris hofmann, Assigned: (not reading, please use instead))


Firefox Tracking Flags

(Not tracked)



(2 attachments, 3 obsolete attachments)



17 years ago
in 4.x I can:
 hit send and have the spell checker come up.
 start spell checking,
 go through the document and decide that its not ready to be sent.
 dismiss the spell checker.
 and the message is not sent giving me a chance to do some more editting.

I can't to this with the current daily builds...

should this bug go against mozilla, or netscape bugscape?

Comment 1

17 years ago
sorry, not the editor team, this one goes off to mail
Assignee: beppe → sspitzer
Component: Editor → Mail Window Front End
Product: Browser → MailNews
QA Contact: sujay → esther

Comment 2

17 years ago
This is a bugscape bug since there are no (official) spellcheckers for Mozilla,
whereas one is included by default in the NS6.x build.

Suggest move to bugscape.

Comment 3

17 years ago
Whether or not this bug goes to bugscape has to do with where the bug is, right?

Chris--is the UI different in the spellchecker dialog (from 4.x to 6)?  Could you 
be more specific about how you decided in 4.x not to send the message?

If the problem is in the spellchecker's xul, that's in mozilla.  If the problem 
is in messenger and how it handles invocation and dismissal of the spellchecker 
dialog, then it's in mozilla.  If the problem is in the spellchecker logic, the 
bug should be in bugscape.  My intuitive guess says this bug is appropriately in 
this is a dup anyways, I'll try to find it.
QA Contact: esther → stephend
This bug is invalid in bugzilla, but lives happily in bugscape as
Last Resolved: 17 years ago
Resolution: --- → INVALID
For anyone else to verify this bug, who can't get through the firewall, the bug
is, "Can't stop a SEND, if Spell Check is enabled"

Comment 7

17 years ago
This bug shouldn't have been invalidated since I believe all of the mail code 
that deals with the spellchecker in checked into the Mozilla tree.

Note the only spellchecker related item not checked into Mozilla is the 
implementation of the nsISpellChecker interface. Everything else including the 
spellchecker UI in Composer and MailCompose is checked into Mozilla tree.
So, what should be done about the bug in Bugscape? Invalidate that, and re-open
this?  I'm a little confused as to where to draw the line here, especially since
the only working spellchecker is in commercial.  Feel free to re-open at will.
QA Contact: stephend → esther

Comment 9

17 years ago
Mark it as verified/invalid.


16 years ago
Blocks: 119232

Comment 10

16 years ago
This is a dup of Bugzilla bug 109127 and bug 52679 (the bug 52679 was moved to
Bugscape and became 3581 there). It is no longer invalid since a spellchecker is
now being developed for Mozilla - see bug 56301

Comment 11

16 years ago
In addition to the previous comment, this is a UI bug, not a functional bug: the
4.x dialog had a button called something like "Stop" that dissmissed the
spellcheck dialog, cancelled the send, and put you back into the editor. The 6.x
dialog box does not have a corresponding button, and one needs to be added. The
code for the dialog is in the Mozilla tree, so I think this is appropriately a
Mozilla bug.

This bug is not a dup of 109127 (which is solved by the Recheck button), nor
indeed is it a dup of 100388 (problems with clicking the Cancel button on the
sending message progress bar that appears after the spelcheck dialog is closed).
However, this bug is a dup of 52679 = Bugscape 3581, and of 115338. I'm not sure
what the rule is for which duplicate should be open, but one of these needs to
be open in one of the trees, and then someone needs to add anotehr butoon to the

For reference, this bug is my single biggest peeve with the 6.x mailer.
Resolution: INVALID → ---

Comment 12

16 years ago
*** Bug 115338 has been marked as a duplicate of this bug. ***

Comment 13

16 years ago
I'd suggest making the button say [Edit Message]  (and possibly change [Close]
to [Send] have the close-dialogue behaviour be [Edit]). Stop and Close are too

I also just noticed that one needs to handle the case where the spell checker is
explicitly invoked differently (or maybe not - depending on whether you think
it's natural to be able to send in that case).

Comment 14

16 years ago
I like the idea of [Edit Message] and [Send]. However, there is already a button
on the dialog called [Edit...] (for editing the User Dictionary): having an
[Edit...] button and an [Edit Message] button would be confusing. How about
[Back] and [Send]?

As to the issue of what the dialog should look like if spellcheck was explicitly
invoked, I agree on the face of it it seems more logical to not have a [Send]
button in that case (in which case the [Back] (or whatever) button could simply
be labeled [Close] or [Done]). On the other hand, since spellchecking is
typically about the final thing you do when composing a message, it does make a
certain amount of sense for the user to be able to send the message from within
the spellcheck dialog even in the case where it isn't an automatic pre-send
spellcheck. Sounds like a question for a UI designer.

However, even if the dialog does have two buttons with the same labels either
way, it should have a different default action button hilighted at the end of
the spellcheck, and similarly a different behavior on clicking the dialog close
box: for an automatic pre-send spellcheck the default should be [Send], while
for an explicitly invoked spellcheck the default action should be [Back] (or
whatever we call it). 

Comment 15

16 years ago
As previously mentioned, this bug is the same as Bugscape 3581. Leaving aside
the question of which database this bug really belongs in, 3581 is ASSIGNED to (Varada Parthasarathi) with priority P2 and target milestone
mozilla0.9.9. There is thus a case for assigning this one priority P2 and target
milestone mozilla0.9.9 as well, and probably also for ensuring that both bugs
are assigned to the same engineer, or at very least that Seth and Varada
co-ordinate their efforts.

Comment 16

16 years ago
Ok, I played with this a bit, and know enough to make a sort of workable
solution.  Maybe. Perhaps.  Unfortunately my knowledge of xul comes mainly from
watching Ghostbusters, and my javascript is not much better. A few questions.

If I place a 'return to editor' button on the spell check dialog and hide it if
we are not being called during send will this work in all cases?  Is there some
better way of this. Xul overlays seemed to be doing something like this, but
seem overly complicated.

Is there some preferred way of getting info out of the dialog. I used the
window.spellCheckCompleted variable, and that seemed to work, but will it work
in general.  In other words is the window seen from the dialog as window.opener
the same one seen in GenericSendMessage as window?  Probably, but there is a
fair amount of stuff in goDoCommand that I do not understand.

Comment 17

16 years ago
*** Bug 87354 has been marked as a duplicate of this bug. ***

Comment 18

16 years ago
Created attachment 71159 [details] [diff] [review]
a patch

OK, this is sort of the mirror image of the patch for bug 86296, and they
should probably be combined, and a few check boxes added to the preference
There is one thing that I do not understand.  It seems that returning true, or
calling onClose in this case, only closes the dialog when called from a button
if that button is of dlgtype accept of cancel, and there can be only one of
each that works in any dialog.	Furthermore buttons of dlgtype="accept" seem to
ignore the hidden attribute from XUL.  You can set it from javascript, though.
As usual, the patch works on my machine, whatever that means.

Comment 19

16 years ago
Created attachment 71236 [details] [diff] [review]
An improved patch

The same as before, but remembering to reset the flag.
Attachment #71159 - Attachment is obsolete: true

Comment 20

16 years ago
Comment on attachment 71236 [details] [diff] [review]
An improved patch

- You accidentally included the change to extensions/ in this patch

- Do we really need a preference for this? If people do not need it, they would
not use the "Cancel Send" button, but it never hurts having it there, is it?
After all you might not know you want it and by the time you need it it's too
late to update your preferences...

- Isn't it true that Mozilla style calls for spaces in .js, not tabs?

- the last comment in the patch shows that you are a vi user ;-)
Attachment #71236 - Flags: needs-work+

Comment 21

16 years ago
Created attachment 71304 [details] [diff] [review]
Yet another patch

Ok, this removes the preference -- a moments reflection shows that it is
unnecessary.  It also fixes the tab/space problem.
Attachment #71236 - Attachment is obsolete: true

Comment 22

16 years ago
So, what should be the best place to put the new button? IMHO, it should be next
to what's currently called "Close" and that one should be renamed since "close"
is no longer a unique way to actually close it...

I would suggest something like:

... (top of the window as it used to be)

[Language Drop-Down  ]  (Recheck)

Finish checking:        (Edit Message) (Send Message)

This way:
1) Both "close" buttons are near each other and are clearly marked as to what
they do
2) We can use the exact same design, not matter whether the window was called by
the "Send" button or by "spellcheck" button.

Does this look reasonable?

Comment 23

16 years ago
I agree that the button is in the wrong place, and that when the spellchecker is
called from send the close button should reflect that it will send the message.
but ...

I would much prefer to have the send button not be visible when it does the same
thing as the close button.  Having two buttons that do exactly the same thing is
confusing, even to experienced users.  

Also the button text should reflect what it actually does, and any text
mentioning messages is going to be baffling when called from composer.  Let me
play with the xul for a moment and see if I can find a workable solution.

Comment 24

16 years ago
> I would much prefer to have the send button not be visible when it does the same
> thing as the close button.  Having two buttons that do exactly the same thing is
> confusing, even to experienced users.

Ah, but that's what I am suggesting - to do *both* buttons each doing it's thing
*no matter* how the window was called - what's wrong with having a "send
message" button it the window even if the spellchecker was invoked directly
(rather than by the "spellcheck on send mechanism")?

> Also the button text should reflect what it actually does, and any text
> mentioning messages is going to be baffling when called from composer.

Ah, right, I do not use the composer (I prefer vi ;-) ), so I forgot that
spellchecker window is not only there for message composition...

Comment 25

16 years ago
Created attachment 71820 [details] [diff] [review]

Ok, this cleans up the interface, I think.  I sort of wish that we had another
feature so that the recheck button could be off the bottom row.

Aleksey, I dont think the the send button should occur unless the dialog is
called from send.  It will confuse too many people.


16 years ago
Attachment #71304 - Attachment is obsolete: true


16 years ago
Keywords: patch

Comment 26

16 years ago
Havs everyone been following the discussion on the matching bugscape bug 3581

They seem to have a patch, and to be converging on a UI something like:

Pre-send spellckeck:
          [   Stop   ] [[   Send  ]]  |

Non-pre-send spellckeck:
                       [[  Close  ]]  |

with the [ Recheck ] button moved up near the top of the dialog box.

Comment 27

16 years ago
We cannot see bugscape.  I will admit to being more than slightly annoyed at the
spellchecker bugs being moved out to bugscape for no particular (at least no
announced) good reason.  We, the hoi polloi, have no way of telling whether or
not a bug is being worked on or not.  I decided to work on this becaused it
bugged me, and it bugged alot of other people too judging from the number of
dup's.  Some of these bugs, bug 17753 particularly, I would like to be able to
see what the proposed solution is and have some input into its design. (It is
far and away the most requested of me bug to fix.)  I would also like to have
some input in the pushing of nsISpellchecker in the direction of bug 123087.  I
could probably actually help.

Can we take it that bugs being moved to bugscape are being actively worked on?
Is there a reason that these bugs needed to be moved?

I will probably wish that textboxes were spellchecked, and that something like
the solution to this bug had been implemented in that checking. Oh well.

Comment 28

16 years ago
I believe the bug got moved to Bugscape at a point where Mozilla had no spell
checker and Netscape 6 did have one, on the (not entirely unreasonable) grounds
that filing a Bugzilla bug against UI related to a component that was Netscape
only was silly. Then Mozilla started adding a spellchecker too, but by then
people had actually started working on the Bugscape bug, and it kind of acquired
a momentum of its own. I have already suggested on Bugscape that they transfer
the bug back to Bugzilla, but it never happened. However, this is unhelpful for
those people who do not have Bugscape access.

Comment 29

16 years ago
I apologize for ranting.  It is less this bug, for which the fix is fairly
trivial, and I learned a fair amount of xul in the process of fixing it, than it
is the the fact that a bug in the mozilla codebase was moved to bugscape.  Even
if noone moved to fix it, it was going to be reported again. I am less concerned
with this bug in particular, though I am glad that it will be fixed real soon
(It will, wont it?).  I will admit to knowing that I was taking a risk, but I
figured that any P2 bug that was targetted for 0.99 and was not in the codebase
yet, wasn't likely to have much work done.  

I would like to request that bug 17753 (bugscape 8868) be moved back to
bugzilla, even though I doubt that much work will be done on this until
nsISpellchecker gets reengineered.

Comment 30

16 years ago
This is awesome - it is such a big increase in usability. Is there any chance
this might make 1.0?

I have one minor nitpick though - if I dismiss the spellchecker window from
window manager, the message gets sent. IMHO it make a little more sense to
cancel send it that case - if user goes around killing windows it makes sense to
be a little more concervative ;-)
Keywords: mozilla1.0

Comment 31

16 years ago
Created attachment 72407 [details]
Screenshot - really nice

Comment 32

16 years ago
Yes, you are right about closing, and if I continued to work on this, would
probably implement that, as well as making don't send the default until the
spellcheck has completed.  However, as it appears that the netscape people have
a patch (and I agree that their placement of the recheck button is better than
let us wait for their fix.

Comment 33

16 years ago
*** Bug 109127 has been marked as a duplicate of this bug. ***

Comment 34

16 years ago
Can Netscape's patch be attached here (or the whole bug just moved back to
Bugzilla). Please!

I am currently running Mozilla with the patch attached to this bug, but I'd
rather be using (and testing!) the patch that has a chance of making it into
Mozilla tree, especially if it's known to work better.

P.S. 4xp per original report.
Keywords: 4xp
OS: other → All
Hardware: PC → All

Comment 35

16 years ago
*** Bug 129777 has been marked as a duplicate of this bug. ***

Comment 36

16 years ago

Comment 37

16 years ago
I own the Spell Checker dialog. I have this problem solved.

*** This bug has been marked as a duplicate of 132697 ***
Last Resolved: 17 years ago16 years ago
Resolution: --- → DUPLICATE
verified dup (although I'm still not sure why we didn't leave the patches in the
older bugs, but that's a nit).
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.