Closed Bug 1518304 Opened 5 years ago Closed 5 years ago

Make markdown mode optional, default to off

Categories

(bugzilla.mozilla.org :: General, enhancement)

Product:
bugzilla.mozilla.org
Component:
General
Version:
Production
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: kats, Unassigned)

References

Details

While this is a really nice feature, I think turning it on by default is premature. People have existing workflows that involve bugzilla and silently reinterpreting the comments as markdown is likely to break things. Bug 1518303 is one example of this. I think the markdown mode should be toggleable on a per-comment basis, with a default to off. Users who are making a comment with markdown styling intentionally can turn it on.

Eventually once it has baked for a little longer I'd be happy to see it get turned on by default. I think it's just a bit premature to do it already.

Optional features have a high cost. Aside from the alignment of icons, font choice, and spacing of comments any issues that have come up so far are ameliorated by the also-fresh ability to edit comments, and as such we won't be making this feature optional.

Additionally, Splinter is a deprecated feature (in favor of reviewing being done in Phabricator)

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX

It seems like our markdown mode is rather primitive though.
I'd like to see an editing toolbar as on github.com with a Preview button.

(In reply to Dylan Hardison [:dylan] (he/him) from comment #1)

Optional features have a high cost.

Not-fully-baked features being released into a production environment have a high cost too. In one case the cost is borne by the BMO dev team. In the other it's borne by everybody using BMO, which is a lot of people.

At least consider options and progressive rollout for future changes/features.

(In reply to Mats Palmgren (:mats) from comment #2)

It seems like our markdown mode is rather primitive though.
I'd like to see an editing toolbar as on github.com with a Preview button.

We do in fact have a preview button although not a toolbar

(In reply to Kartikaya Gupta (away Jan 12-26; email:kats@mozilla.com) from comment #3)

(In reply to Dylan Hardison [:dylan] (he/him) from comment #1)

Optional features have a high cost.

Not-fully-baked features being released into a production environment have a
high cost too. In one case the cost is borne by the BMO dev team. In the
other it's borne by everybody using BMO, which is a lot of people.
At least consider options and progressive rollout for future
changes/features.

We did consider the idea of individual rollout, but that would mean different people experience different behavior which has historically been a rather bad experience.

At least consider options and progressive rollout for future changes/features.

Otherwise users are forced to things like bug 1500441 comment 6.

The announcement feature is approximately 16 years old -- it was re-styled to look like a notification, and it was made dismiss-able shortly after but that code hasn't gone out because there was a holiday-time freeze on pushes.

Is there a bug open on adding a markdown toolbar to easily markup
snippets of a comment as code etc, like on github?

Flags: needinfo?(dylan)

I am particularly worried about bug comments from less experienced
contributors / users who very often include HTML markup snippets
in comments given the nature of our work...

<html>
<body>
<div>Test</div>
</body>
</html>

comment 10 was:
<html><body><div>Test</div></body></html>

Here again:
<html><body><div>Test</div></body></html>

No, this is unacceptable, I fear.

No newbie would know the backslash trick (and please don't edit my comment to alter its meaning).

Sorry about that, I was checking if that was the case. The behavior is identical to github in the case of disallowed tags, differing only in the case of \<p> and \<b> and a few other tags that github does allow.

How big is the problem?

We see around 150 new bugs a day in Firefox. How many of those have un-escaped HTML in the description?

Flags: needinfo?(dylan)

This isn't something that is going to be in non-bmo Bugzilla, right?

I run three Bugzilla instances and I sure would hate to try and have to rip this out of 6.0 just to keep our workflows sane.

If we updated the string Markdown styling now supported to read Markdown styling is applied, un-escaped HTML will be stripped, does that address the problem?

(In reply to A. Wilcox [:awilfox] from comment #15)

This isn't something that is going to be in non-bmo Bugzilla, right?

This is just in BMO for now, but the Harmony project is working to merge the BMO and mainline branches of Bugzilla.

Please don't show announcements until it's possible to hide them, as you can't scroll them out of the viewport anymore.
(And devtool's screenshot feature doesn't work on BMO since the new - beautiful - header was deployed.)

HTML shouldn't be stripped and still be shown as plain text.

I would like to edit my account preferences to read all comments in the same monospaced font and size as yesterday and would like to post only such comments. I really just like to have it in such a terminal-like appearance.

Would it be possible to have markdown Opt-In per comment?

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #14)

How big is the problem?
We see around 150 new bugs a day in Firefox. How many of those have
un-escaped HTML in the description?

It seems to vary; but in any case html is only be removed as a temporary measure while the security of exactly following what GitHub does is assessed. In this case \<b>foo\</b> would be passed though, and \<application> would be rendered as an escaped tag.

(In reply to A. Wilcox [:awilfox] from comment #15)

This isn't something that is going to be in non-bmo Bugzilla, right?
I run three Bugzilla instances and I sure would hate to try and have to rip
this out of 6.0 just to keep our workflows sane.

I admit to not understand the use-case, but as implemented this is an admin paramter use_markdown that can be on or off.
In addition an extension could override the markdown engine used.

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #14)

How big is the problem?

We see around 150 new bugs a day in Firefox. How many of those have un-escaped HTML in the description?

I think it's fairly common. data: URIs with HTML in the bug description are also common, like bug 1509650 for example.

Is the original HTML kept somehow in the comment? Can we see it somehow without telling the OP to edit his comment and backtick everything if we don't have admin permissions?

Otherwise that may be the difference between an actionable bug report and a non-actionable one.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #20)

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich]
(UTC-8) needinfo? me from comment #14)

How big is the problem?
We see around 150 new bugs a day in Firefox. How many of those have
un-escaped HTML in the description?

I think it's fairly common. data: URIs with HTML in the bug description are
also common, like bug 1509650 for example.
Is the original HTML kept somehow in the comment? Can we see it somehow
without telling the OP to edit his comment and backtick everything if we
don't have admin permissions?
Otherwise that may be the difference between an actionable bug report and a
non-actionable one.

yes, the original source is always kept. The comment author can edit it, and all members of the insider group may also edit it.
Additionally, the old (deprecated) bug view shows the raw markdown. This is findable from the 'Format' button at the bottom of each bug page.

In ~14 hours html will pass through escaped, but that isn't this bug.

Flags: needinfo?(dylan)

(In reply to Dylan Hardison [:dylan] (he/him) from comment #21)

In ~14 hours html will pass through escaped, but that isn't this bug.

Unfortunately, handling this properly will require additional thought. It's not a simple problem because of fenced code blocks, which is probably why GitHub doesn't do this.

You need to log in before you can comment on or make changes to this bug.