1019998 - Using the [[Image:]] tag in a forum reply or canned response adds extra line breaks

Status: RESOLVED FIXED

(support.mozilla.org :: Questions, task)

Description

[moses]

Attachment: "Bug" issue with [[Image:]] tag

When answering questions on the forum, I always use [[Image:firefox button]] or [[Image:new fx menu]] to show an image of Firefox 28/29 menu buttons. But on occasion, it sometimes shows a bunch of lines breaks. (See attachment)

Comment 1

[Anush [:anushbmx]]

Moses can you post a link to any question where you used this found issue.

Comment 2

[moses]

Anush, it just happened for me at https://support.mozilla.org/en-US/forums/contributors/709903#post-60031 
It also comes intermittently which is strange. Some days it does it, some days it doesn't.

Comment 3

[Anush [:anushbmx]]

I see that its caused by "white-space: pre-wrap;" applied to the paragraph tag.

Let me check whether removing it will create any issue else where or not.

Thank you Moses

Comment 4

[Michael Cooper [:mythmon]]

The "white-space: pre-wrap" was added to make it so when you press enter in a forum post, it displays as a newline in the view.

Comment 5

[Anush [:anushbmx]]

Thanks Mike, I didn't see that. So literally we have to conclude this as wontfix or we need to find some way to make the img out of the paragraph tags.

Comment 6

[Ricky Rosario [:rrosario, :r1cky]]

We have this template that is used for rendering images from the [[Image:...]] markup:

https://github.com/mozilla/kitsune/blob/master/kitsune/sumo/templates/wikiparser/hook_image.html

It is poluted with newlines. If we could somehow tell jinja2 to nuke those newlines, we'd be all good. maybe

Comment 7

[Alice Wyman]

Attachment: ImageBug1019998workaround.png

To work around this bug I've been using a colon or an asterisk in front of the image or in front of a line of text containing small images. Examples:

*Some text [[Image:New Fx Menu]] more text [[Image:Help-29]] more text.
  
A line of text
:[[Image:Safe Mode Fx 15 - Win]]
Another line

Comment 8

[Ton [:Tonnes]]

Attachment: sticking image when editing l10n article

Alice,

If the intention was to reduce whitespace by the last edit for the Forum Response - Starting Firefox in Safe Mode article (83824), it looks like the opposite has been achieved as the whitepsace now has increased, which is obviously caused by using the colon. This is true for both en-US and localized versions and happens when using a semicolon as well. Could you reconsider this?

Sidenote 1: it reminds me of my recently submitted bug 1105227 (not intended as a bump, though it could use some input), as using (semi)colons may cause some unintentional line spacing issues. I.e. I should take care when using workarounds by using (semi)colons - the KB is currently loaded with ugly line spacings caused by them IMO.

Sidenote 2: When editing a NON-en-US article, some unwanted behaviour occurs with images ‘sticking’ to the end of a previous line during preview (see attachment), which is a reason for me to intentionally include a <br> right after the previous line sometimes, just as it existed in the recent en-US forum response revision in order to make the preview show up allright, though it doesn’t result in a new line break for the article itself (whereas <br><br> does). For some reason this does not happen when editing en-US articles (try editing an en-US and a localized one to see this), so that’s obviously a bug. To prevent this, localizers could use a colon or semicolon as well, but then the line spacing increases to about 1.4 times a normal line distance just as it does for en-US. In short: to have a decent or even the smallest line spacing possible, I’d use <br> and no colon (or semicolon) for our localized version and perhaps no <br> for the en-US version, or just revert to the previous revision.

Regarding the original problem: I’d say there’s something else going on, possibly caused by the Firefox button image itself. Not sure - I’ve lost my grip on understanding inserted images and line spacing issues for a long while now.

Comment 9

[Alice Wyman]

I did a test by copying my markup to a support forum post, before I made that edit.  My revision to Forum Response - Starting Firefox in Safe Mode does reduce the padding around the image, compared to the previous one. You can see for yourself here (am I missing something?):

https://support.mozilla.org/en-US/questions/1009184#answer-661278

Comment 10

[Ton [:Tonnes]]

Apparently this is a workaround for Forum responses only, but not for regular articles. Maybe change the bug title?

Comment 11

[Seburo]

Closed as per https://blog.mozilla.org/sumo/2019/06/07/sumo-platform-roadmap/

Comment 12

[Alice Wyman]

Reopened: https://support.mozilla.org/en-US/kb/forum-response-restore-default-search-engine/discuss/9408#post-20710

Comment 13

[Kelimutu [:kiki]]

Attachment: Screenshot_2021-01-11 New forum response Forum Response - Restore default search engine Discussion Knowledge Base Mozilla S[...].png

@Alice the line break looks pretty normal to me. Was it different on your end?

Comment 14

[Alice Wyman]

Attachment: testpost-bug1019998.png

Your screenshot is of the wrong post, where I used a semicolon in front of the [[Image:]] markup to work around the issue. The post at https://support.mozilla.org/en-US/kb/forum-response-restore-default-search-engine/discuss/9408#post-20710 is the one before, which says this:
(quote)
Here is what this common response looks like in a test question, without a semi-colon before the image:
https://support.mozilla.org/en-US/questions/1311587#answer-1377108

If you go to that link you'll see the problem.
For example, I posted this today: https://support.mozilla.org/en-US/questions/1311587#answer-1383034

I added the markup I used in the image I'm attaching, underneath the screenshot of my support question post.

Comment 15

[Leo McArdle [:leo]]

Thanks for the details here, I've opened https://github.com/mozilla/sumo-project/issues/728 to track the technical side of fixing this.

Comment 16

[Kelimutu [:kiki]]

@Alice Got it. Thanks for clarifying.

Also @Leo thanks for creating the Github issue.

Comment 17

[Leo McArdle [:leo]]

This should've been fixed with today's release.