Client cuts numbers at the beginning of a sentence

[Z-Brox]

Description

When you write a number (3-9 digits) followed by a dot (".") the client drops all digits but the final two.

Steps to reproduce

Write into chat: 123456789.
gives: 89

Or: 500.
shows: 00.

Version information

• Platform: web (in-browser) or desktop? Desktop

• OS: Debian Buster, confirmed by chat partner with client under iOS and MacOS X.

• Version: 1.7.1

[Z-Brox]

Correction: numbers are not dropped, but shifted to the left.

[t3chguy]

Screenshot for dev:

This is because the left-padding is fixed to 2em so doesn't allow list integers higher than that
(+ the fact that CommonMark interprets 500. as a list)

[Z-Brox]

Thank's for the confirmation, t3chguy.
Devs: is it possible to change the behaviour to start two lines with numbers instead of one before a list is supposed? Like:

1. Text.
2. Now we're sure that's a list.

[t3chguy]

That would be a query for https://commonmark.org/ as that is the markdown parser used

[Yoric]

So, this could be fixed by a CSS change, right?

[t3chguy]

Yes. The current faulty style comes from http://ungoldman.github.io/gfm.css/ but can be overridden in our CSS.

[chagai95]

Anyone planning on fixing this? Would be nice to know where this is on the roadmap 🙈

[dkasak]

Devs: is it possible to change the behaviour to start two lines with numbers instead of one before a list is supposed?

That would be a query for https://commonmark.org/ as that is the markdown parser used

This isn't strictly related to CommonMark, as this is primarily a question of whether we consider a particular message to be Markdown at all. We already treat certain messages as plain text instead of Markdown, such as when they only contain text nodes or disallowed HTML tags.

I think the suggested rule of only considering something to be a list when it has two items is a good one and would increase usability. At the very least, we should consider lists with a single empty item to be a plain text (i.e. non-Markdown) message. I'd volunteer to implement this as it has been irking me for some time. This would be a separate change to the proposed CSS fix above.

[SimonBrandner]

I'd volunteer to implement this as it has been irking me for some time

Sure, go ahead!

[neer17]

@SimonBrandner Since there is no activity on this for a month, so can I work on this?

[SimonBrandner]

@SimonBrandner Since there is no activity on this for a month, so can I work on this?

I am a bit unsure atm, isn't this solved by matrix-org/matrix-react-sdk#6833?

Also, no need to ping me specifically

[dkasak]

Just to clarify, no, matrix-org/matrix-react-sdk#6833 doesn't fix this, except as a side-effect in a particular sub-case. That PR makes Element Web stop treating messages such as this one as Markdown:

2021.

This has the side-effect of sidestepping the current faulty formatting. However, messages such as the following one are still treated as a Markdown list:

2021. foo

Since the CSS for Markdown lists is still incorrect, the number would still be cut off in this case. So @neer17 if you'd like to take a stab at fixing this, go for it.

[sakshi-0206]

Hey @dbkr @SimonBrandner
I am an Outreachy applicant and would like to work on this issue. Can you assign this to me?

[SimonBrandner]

Hey @dbkr @SimonBrandner I am an Outreachy applicant and would like to work on this issue. Can you assign this to me?

I've assigned you to the issue. If you need any help/have any questions be sure to visit #element-dev:matrix.org!

[ttheshreeyasingh]

@sakshi-0206 If you're not currently working on this issue? Can I be assigned this issue as well?

[t3chguy]

Clearing assignment as per https://github.com/vector-im/element-meta/wiki/Guidance-on-assigning-issues - anyone is welcome to work on this, once you have a draft feel free to mention it here and we can set assignment then!

[BalanaguYashwanth]

Hello @Me4Linux,

I see some PR's had raised for this issue. Can you check if it is solved this issue ?

[Z-Brox]

Hi, @BalanaguYashwanth

I'm using V1.11.23 now. Still got the problem here that numbers up to 9 digits are truncated. 10 or more work. For example I write: 123456789.
Element-Desktop shows: 89. (and I see some pixels of the digit "7")
But when I write: 1234567890.
Element shows: 1234567890.

[BalanaguYashwanth]

ok

[ara4n]

the workaround to this is to override the 2em in the CSS from gfm.css

.markdown-body ol, .markdown-body ul {
    padding: 0 0 0 2em;
}

...and I guess do some dirty heuristic to do that automatically the string length of the number is too wide.

[aditjya]

is this still open?

[t3chguy]

Yes.

[aditjya]

Hi @t3chguy i'm new here can you tell me what is the problem to solve? please..

[t3chguy]

The OP describes it pretty well #14621 (comment) - they write a number, only the last 2 digits or so are rendered, the rest is cut off.

[aditjya]

so i need to make it render all the input digits
right?

[t3chguy]

Yes, that would be the solution

[aditjya]

This might be my first contribution. I'll try my best!

[shadow-identity]

Happens on iOS client:

• peer types: 46) and sends the message using Element for iOS
• peer doesn't see the sent message
• I see the message, but what I see is 46.
• In the "View Source" dialog I see:

{
  "content": {
    "body": "46)",
    "format": "org.matrix.custom.html",
    "formatted_body": "<ol start=\"46\">\n<li></li>\n</ol>",
    "msgtype": "m.text"
  },
  "room_id": "xxx",
  "type": "m.room.message"
}

Want to point additional attention (since original bug description has a bit different reproduction) that the peer does not see its message at all.
If it sends 46) hi peer sees like hi, the message content on my side is

{
  "content": {
    "body": "46) hi",
    "format": "org.matrix.custom.html",
    "formatted_body": "<ol start=\"46\">\n<li>hi</li>\n</ol>",
    "msgtype": "m.text"
  },
  "room_id": "!HnLctILERbiRchRZkp:pavli.cc",
  "type": "m.room.message"
}

[t3chguy]

Happens on iOS client:

@shadow-identity https://github.com/element-hq/element-ios is the repo for iOS issues.

[sarans-h]

Is the issue fixed??

[dkasak]

It's not.