Closed Bug 17452 Opened 25 years ago Closed 23 years ago

Allow Bugzilla comments to be in HTML format

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P5)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Type:
enhancement

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: BenB, Assigned: myk)

References

Details

(Whiteboard: [Use the bug_format_comment code hook to implement HTML comments])

Attachments

(1 file)

Decorate specially tagged text v1
2.48 KB, patch
Details | Diff | Splinter Review 
Allow HTML comments in what, exactly? In bug reports???
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
It's been two months now, so I'm resolving this as invalid. Ben, reopen this if
you want to make it clear exactly what you want.
Status: RESOLVED → REOPENED
REOPENing.
Matthew,
I thought, it was clear to terry, what I meant. Comments in Bugzilla are what I
am just typing.
Resolution: INVALID → ---
CLEAR.
Status: REOPENED → ASSIGNED
Priority: P3 → P5
It's clear, but I don't think I'll ever actually do this.  But I'll leave the
bug open for now for purposes of discussion.

Either the text field is plaintext, or it is HTML.  Combining the two just leads
into confusion and problems, IMHO.  Plaintext seems to have been working pretty
well...
Yeah, I forgot, that HTML is not as comfortable to enter as plaintext.

A possibility to solve this might be the way slashdot solves it: Let the user
choose the interpretation mode.

But, terry, feel free to mark WONTFIX.
*** Bug 20221 has been marked as a duplicate of this bug. ***
If this is done, the comment submission script would need to:
* strip out malicious HTML tags (such as SCRIPT, APPLET, BLINK, H*) -- or only
  offer a limited subset of tags
* detect invalid HTML tags
* detect invalid character entities
* detect perl handlers which tried to insert any of the above.

Resummarizing so that others don't get confused, like I was earlier. :-)
Summary: Allow HTML comments → Allow Bugzilla comments to be in HTML format
I vote for a limited subset similar to slashdot's.  Don't forget automatically 
inserting closing tags that are left off.
Some alternative solutions are bug 31323 (tell the user HTML formatting won't 
work) and bug 31324 (underline the correct parts of attempted html links).
tara@tequilarista.org is the new owner of Bugzilla and Bonsai.  (For details,
see my posting in netscape.public.mozilla.webtools,
news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)
Assignee: terry → tara
Status: ASSIGNED → NEW
i lean more towards plaintext and highlighting of url's in comments than 
allowing html. not only do we have to strip out the tags, but i don't want to 
make it easier for people to spam into the comments.
An (IMO preferred) alternative to this bug would be bug 31706.
Adding default QA contact to all open Webtools/Bugzilla bugs lacking one.
Sorry for the spam.
QA Contact: matty
Target Milestone: --- → Future
Whiteboard: [content:comments]
Moving to new Bugzilla product ...
Assignee: tara → myk
Component: Bugzilla → Creating/Changing Bugs
Product: Webtools → Bugzilla
Version: other → unspecified
It's been a year since comments have been been made here. Do we really want to
do this? I'm very much opposed to it and would like to WONTFIX for good.

There is some gain, I understand, in letting HTML happen here, but the truth is
it's more complexity than we want. We'd need to filter out malicious code,
prepare the text to be emailed somehow in a pseudo-clean format, and worry a lot
about the breakage.

One of Bugzilla's main strength is email integration and the smart-text-based
communication; hopefully we keep it that way.
I agree that allowing HTML comments is a whole lot of complexity for minimal
gains... perhaps we should put some text above the textarea that alerts users to
the fact that HTML in comments doesn't work (I've seen a few comments where
users thought they had to link to bugs themselves and didn't realize that
Bugzilla linkified certain things automagically... but that was bug 31323 which
Terry WONTFIXed a while ago).
Status: NEW → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → WONTFIX
Verified WONTFIX.  I don't want this.  If people have a valid reason to put HTML
in a comment, they can upload it as an attachment and ask people to look at it.
Status: RESOLVED → VERIFIED
clearing milestone for invalid/wontfix/worksforme/duplicate so they'll show up
as untriaged if they get reopened.
Target Milestone: Future → ---
I think only a few tags should be aloud these are <a>(with working title=""
atributes)  <b> <i> <u> <span> and of couses Mozilla's forvorite <blink>

ok maybe not <blink>
This patch adds functionality for text decoration.
I attach it here because I didn't know where to put it otherwise.

Three work modes are supported (see Parameters):
 off - no decoration at all
 ascii - matches *bold*, _underline_ and /italic/
 html - for <b>bold</b>, <u>underline</u> and <i>italic</i>

Note: rules will only match complete sets. A <b> without closing tag will not
get matched (this also applies to all the other html and ascii tags).
Let me know if I missed any special cases (or if my regexes are messy anyway).
*** Bug 362338 has been marked as a duplicate of this bug. ***
I have been looking for the file names that correspond with ones attached to this bug, but I cannot find any files with such names (i.e. defparams.pl) in my installation.

To include this functionality, where do I find the files in my installation?
I would like to be able to add a limited rich text editor into bug commenting for our company's intranet bugzilla. Is there an addon that can enable this? If Dave doesn't want it in the default build, thats fine with me. Just let the rest of us configure it that way, or have an option to turn it on.

The functionality listed at http://www.mozilla.org/editor/midasdemo/ is absolutely sufficient.
It just seems strange, looking at the bug history: 1999-11-08 - 2008-04-02. First, I wouldn't treat it as "enhancement". It is very annoying.
A quick note for those who want HTML comments: use the bug_format_comment code hook!
Whiteboard: [content:comments] → [Use the bug_format_comment code hook to implement HTML comments]
QA Contact: matty_is_a_geek → default-qa
Amazing. It's been almost 14 years and you still can't format code properly in comments. This is this only bug tracker I've seen in the last 5 years that's missing this obvious feature.

Redmine for the win.
I agree - I don't understand why a simple Rich Text Editor cannot be added to comment entry.  Both my internal developers and my customers are asking for this.
I'd like to reopen this bug in order to suggest a markup language. Asciidoc could be a good candidate as it also make it readable in plain text.
I don't think HTML is a good choice for the various reasons listed about.
Can we reopen and update this entry? Or is the another one open for rich text using markup/wiki language? Or should I open a new one?
(In reply to mistria from comment #32)
> I'd like to reopen this bug in order to suggest a markup language.

bug 330707.
Any updates as of March 2014? I see a "Preview" tab at https://bugzilla.mozilla.org/show_bug.cgi?id=330707, but it's unclear what the point of the Preview is, if there's no formatting?

Is there a formatting help page that should be linked to?
Dan: See bug 40896 to discuss "Preview". There is formatting other than HTML, e.g. automatic linking.
Backout by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/a1f253f8a9f9
Backed out changeset f5041651b877 as requested by glob. r=backout
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: