Open Bug 3746 Opened 26 years ago Updated 2 years ago

Warnings for USENET etiquette errors required by GNKSA

Categories

(MailNews Core :: Composition, enhancement, P5)

enhancement

Tracking

(Not tracked)

People

(Reporter: phil, Unassigned)

References

(Depends on 2 open bugs, Blocks 1 open bug, )

Details

(Keywords: helpwanted, Whiteboard: 15b, 16e still needed)

This is one of the "failing" items in the Good Netkeeping Seal of Approval (see URL above). There are a couple of common user errors which we should warn about. IMO, these warnings should include a "don't warn me again" checkbox in the dialog. > 16a Does not warn when posting an empty article > 16c Does not warn when posting quoted text only > 16e Does not warn against inadvertent multiple postings
Also: > 15b Does not warn on, or refuse, excessive signatures
QA Contact: 4080 → 4098
Stacey - if you think Esther should be the QA contact, please change accordingly.
JF, is this more a compose bug, or more a news bug (for sspitzer?)
Status: NEW → ASSIGNED
Phil, I don't have any clue what that means! message compose isn't yet really ready to support newsgroups posting. The code should be here but hasn't ever been validated.
Target Milestone: M9
> I don't have any clue what that means! The bug means that we allow the user to do some things which are bad form on USENET. The suggestion is that we show the user a warning (probably with a "don't ask me again" checkbox) when the user does these things. M9
OS: Windows NT → All
Hardware: PC → All
correcting platform to All.
Target Milestone: M9 → M11
My guess is that this isn't getting done by M9. So I'll move to M11. You can retarget if you want.
I would not hold PR1 for this bug.
Blocks: gnksa
Target Milestone: M11 → M14
M14
As a point of reference, the old 4.x MSG_CompositionPane had a SanityCheck function which was invoked on a message at send-time. We used that opportunity to check for a bunch of errors, like no subject, or no body. You might make sure that logic is maintained in mozilla, and add these netiquette errors to that code.
We still have a SanityCheck function: mime_sanity_check_fields, just need to extend/update it...
QA Contact: scurtis → huang
Change QA Contact to me since it's my feature now.
Target Milestone: M14 → M15
Mass moving to M16 to get these off the M15 radar. Please let me know if this is really an M15 stopper.
Target Milestone: M15 → M16
Need help.
Assignee: ducarroz → nobody
Severity: normal → enhancement
Status: ASSIGNED → NEW
Keywords: helpwanted
Target Milestone: M16 → M30
If at all possible, methinks we should try to satisfy all of the NS failings at http://www.xs4all.nl/~js/gnksa/Evaluations/netscape-communicator-4.5.txt Have we inadvertently fixed some of them without specifically trying to?
self->cc, sorry for spam
This is a GNKSA MUST, adjusting SUMMARY.
Summary: Should have optional warnings for USENET etiquette errors → Must have optional warnings for USENET etiquette errors
reassigning to me to take a look
Assignee: nobody → BlakeR1234
Priority: P3 → P5
Target Milestone: M30 → Future
Assignee: blakeross → mozilla
I don't have time right now. to Ben for now, who could probably do this fairly easily. (I don't understand why this sanity check is in C++ and not JS/XUL, where it seems easily enough to implement)
> I don't understand why this sanity check is in C++ and not JS/XUL, where it > seems easily enough to implement C++ is not inherently harder than JS. I like to keep the backend in C++, because that way, you can write a new frontend (which doesn't know about JS) without rewriting half the app. Accepting and targetting Mozilla 1.0, but I don't know, if I will get to it, unless we define non-GNKSA-compliance as a Mozilla 1.0-blocker (which I propose). We have much worse problems right now :-( (e.g. LDAP).
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0
I still think stuff like this belongs in the JS. cc'ing brendan for thoughts
This is not a frontend bug. Warnings are logic. *Displaying* the warnings is frontend.
This is a discussion that belongs in the newsgroups, but... By your logic, we have lots of JS that needs to move to C++. JS is not and has never been purely for "frontend" (not sure what you mean by that..wouldn't that be xul, css, etc.?) C++ should be for the "glue" code, e.g. the base code that ties everything above it together, e.g. stuff that really is best done in a programming language like C++. I still think that simple sanity checks such as these are best handled in JavaScript, and am hoping that Brendan can shed more light here.
> This is a discussion that belongs in the newsgroups, but... Then do so and post a link here. > we have lots of JS that needs to move to C++ Which one? > not sure what you mean by that.. Frontend is the presentation, and nothing else. > wouldn't that be xul, css, etc.?) You cannot program in XUL. The frontend also needs code. > I still think that simple sanity checks It's not a matter os simplicity. It stops being simple, if you create e.g. a GNOME frontend for Mailnews, because then you have to reprogram all this "simple" logic stuff -> simplicity lost, redundancy introduced.
Why do you have to reprogram it if you create a GNOME frontend? C++ should be the bare minimum, especially for embedding purposes (although I guess that's not an issue in the case of mail?) What if different programs want their own sanity rules?
Ben, there is nothing inherent in "back-end" code that precludes using JS as an implementation language, and we have JS implementations in the back-end. Stop lumping JS together with front-end, and try learning JS so you don't have to write so much nsString code in C++ (and take your life in your hands with leaks and bad pointer crashes). Blake: JS can be "glue" too (Perl is duct tape). JS is just another programming language, with different trade-offs than C++, but with broad application (not only for UI). I detest religion that says "use this language *only* for some class of code". More in a bit. /be
> C++ should be the bare minimum, especially for embedding purposes Right, but JS isn't. This is my whole point. > What if different programs want their own sanity rules? The applicability of these rules doesn't depend on the frontend. The rules are the same, no matter, if the frontend is XUL, HTML (Webmail), Palm or GNOME. If you really want to alter them - you have the source. For embedders, changing C++ code is not harder than changing JS code. > there is nothing inherent in "back-end" code that precludes using JS as an > implementation language There is: you need a JS interpreter. Anyway, it seemed to me that blake didn't suggest to write IDL interfaces for these checks (however these interfaces might look like), but write the checks in the frontend code, in particular in mailnews/base/resources/content/something.js, which will indeed not exist at all for embedded Mailnews. > and we have JS implementations in the back-end. Which ones? > JS is just another programming language Sure.
> > there is nothing inherent in "back-end" code that precludes using JS as an > > implementation language ..for embedded apps. > There is: you need a JS interpreter. Otherwise, you're right - there isn't.
> Right, but JS isn't. This is my whole point Sanity checks should not be considered "bare minimum" because different clients could have different ideas about what's "sane" and what's not. Bare minimum should be the ability to send an email. Frills like checking whether the user is posting only quoted text to a newsgroup isn't.
> different clients could have different ideas about what's "sane" and what's not. This is arguable, I completely disagree. The point of GNKSA is that is applies to all clients. GNKSA complicance, once achieved, is a *core feature* of Mailnews. If you want to change it, you change the nature of Mailnews. However, the checks in this bug will propably depend on a pref anyway (because individual users might not like them), so embedders/distributors disagreeing with us could just change the pref anyway.
Changing personal priorities. Giving away most of my bugs :-( (reassigning to default owner). I will still track these bugs closely. If you need my input, feel free to ask me. New owner: Please do *not* close these bugs (as WONTFIX or whatever you may find) unless they are fixed. Rather, reassign to <nobody@mozilla.org>, if you don't want to work on them.
Assignee: mozilla → ducarroz
Status: ASSIGNED → NEW
QA Contact: huang → esther
Target Milestone: mozilla1.0 → ---
QA Contact: esther → huang
Blocks: 76449
> 16a Does not warn when posting an empty article This is already fixed. > 16a Does not warn when posting an empty article This won't ever happen because we always append some whitespace. > 16e Does not warn against inadvertent multiple postings Can someone defined "inadvertent multiple postings" > 15b Does not warn on, or refuse, excessive signatures Define "excessive signatures".
> > 16a Does not warn when posting an empty article > > This is already fixed. > > > 16a Does not warn when posting an empty article > > This won't ever happen because we always append some whitespace. huh? Is it fixed, or will it never happen? BTW: "We append some whitespace" is not an argument. Then ignore that whitespace. (Compare our message analysis for the HTML question dialog.) > Define "excessive signatures". Longer than 4 lines or any line longer than 80 chars.
The second 16a in my previous comment should have been: > 16c Does not warn when posting quoted text only
That's trivial to catch, and the code already exists in the HTML recognizer (for the HTML question dialog). You just need to copy the code and cut it down a lot. Or reorganize it, but that's not trivial anymore :-/.
Ben, can't you fix this bug? You know the mime fu better than me. :)
Not sure, I might. But you do the UI ;). In any case, I can help you with pointers to the right code.
I am not planning to work on this bug.
BTW, 15b is bug 45137. So all you have to do to fix this bug: > 16c Does not warn when posting quoted text only > 16e Does not warn against inadvertent multiple postings
Based on the original reporter's comments, this bug is related to compose/news problem. Change QA contact to Sheela & Ccing Stephen.
QA Contact: huang → sheelar
accepting
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla1.0.1
QA Contact: sheelar → stephend
add myself to cc
No longer blocks: gnksa
Depends on: 29497
No longer depends on: 29497
Depends on: 29497
Depends on: 192562
Changing the summary to reflect the scope. The way it was, it looks like a catch-all RFE for Usenetiquette errors in general.
Summary: Must have optional warnings for USENET etiquette errors → Optional warnings for USENET etiquette errors required by GNKSA
Summary: Optional warnings for USENET etiquette errors required by GNKSA → Warnings for USENET etiquette errors required by GNKSA
Target Milestone: mozilla1.0.1 → ---
Product: MailNews → Core
Bringing love and recognition to an open 4-digit bug.
Assignee: ducarroz → nobody
Status: ASSIGNED → NEW
QA Contact: stephend → composition
Whiteboard: 15b, 16e still needed
Product: Core → MailNews Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.