Bugzilla

Comment 10

•

23 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

•

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

For reference, this bug is my single biggest peeve with the 6.x mailer.

Status: VERIFIED → REOPENED

Resolution: INVALID → ---

scottputterman

Comment 12

•

23 years ago

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

Michael Witbrock

Comment 13

•

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

Comment 14

•

23 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

•

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

Comment 16

•

23 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

•

23 years ago

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

Comment 18

•

23 years ago

Attached patch a patch (obsolete) — Details — Splinter Review

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.

Comment 19

•

23 years ago

Attached patch An improved patch (obsolete) — Details — Splinter Review

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

Attachment #71159 - Attachment is obsolete: true

Comment 20

•

23 years ago

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

Attachment #71236 - Flags: needs-work+

Comment 21

•

23 years ago

Attached patch Yet another patch (obsolete) — Details — Splinter Review

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

•

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

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?

Comment 23

•

23 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

•

23 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

•

23 years ago

Attached patch Yayap — Details — Splinter 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.

Updated

•

23 years ago

Attachment #71304 - Attachment is obsolete: true

Updated

•

23 years ago

Keywords: patch

Comment 26

•

23 years ago

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.

Comment 27

•

23 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

•

23 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

•

23 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

•

22 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

•

22 years ago

Attached image Screenshot - really nice — Details

Comment 32

•

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

Comment 33

•

22 years ago

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