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?

sorry, not the editor team, this one goes off to mail

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.

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

this is a dup anyways, I'll try to find it.

This bug is invalid in bugzilla, but lives happily in bugscape as http://bugscape.netscape.com/show_bug.cgi?id=3581

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"

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.

Mark it as verified/invalid.

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

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 dialog. For reference, this bug is my single biggest peeve with the 6.x mailer.

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

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 unclear. 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).

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

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@netscape.com (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.

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.

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

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

The same as before, but remembering to reset the flag.

Comment on attachment 71236 [details] [diff] [review] An improved patch - You accidentally included the change to extensions/makefile.win 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 ;-)

Ok, this removes the preference -- a moments reflection shows that it is unnecessary. It also fixes the tab/space problem.

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) Dictionary: [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?

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.

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

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.

Havs everyone been following the discussion on the matching bugscape bug 3581 http://bugscape.netscape.com/show_bug.cgi?id=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.

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.

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.

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.

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 ;-)

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 mine.) let us wait for their fix.

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

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.

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

cc:

I own the Spell Checker dialog. I have this problem solved. *** This bug has been marked as a duplicate of 132697 ***

verified dup (although I'm still not sure why we didn't leave the patches in the older bugs, but that's a nit).