Created attachment 142032 [details]
Testing indentations in ToC entries

thank you dieter and alex, maybe this is only a very minor bug.
first i looked after the tabs. i think they are innocent. seems it has to do with negative indentations that i used in the toc stylesheets.
the phenomenon appears only if the headline text is shorter than the neg. indentation. (in so far it has to do a little with tabs, maybe)

Hmm,

Enclosing screenshot from LO master, where the problem doesn't appear to be the same, only the entries "rd" and "r" don't display the dots leading to corresponding page number.

I don't know enough about ToC to say whether this is working as designed or not (minimum number of characters taken into account ?)

Created attachment 142086 [details]
Screenshot of test file in LO master daily build

Created attachment 142150 [details]
ToC with dots (pos indent but no neg indent).png

Created attachment 142151 [details]
dots missing (pos+neg indent)

Created attachment 142152 [details]
dotted tabs in standard paragraphs

Created attachment 142153 [details]
example odt, different paragrahps

Hello Dieter,

I tried it again using your example odt.
Generally it has to do with "first line indentation in paragraphs"
So this is not really a ToC problem, maybe it‘s the same in lists? I didn‘t try that. I guess this affects all paragraphs.

when I open the example document, I can see the dots. as in attachment "ToC with dots (pos indent but no neg indent).png"

next step: increasing left indentation in contents2 to 1 cm
while decreasing indentation for the first line to -0.5 cm
-> dots disappear if text is short. see "dots missing (pos+neg indent)"

Because I wanted to see if this behaviour affects every paragraph (yes) I added indentations to normal text as in "dotted tabs in standard paragraphs.png"
examples:
first: no ind
2nd step: increasing left indentation to 0.5 cm
3rd: changing "first line" to -0.5 cm left indentation

it depends on the length of the text left of the tab. if it fits in the value of the "first line" indentation the tab will not be recognized...

(In reply to zerebrom from comment #9)
> Created attachment 142150 [details]
> ToC with dots (pos indent but no neg indent).png

(In reply to zerebrom from comment #10)
> Created attachment 142151 [details]
> dots missing (pos+neg indent)

The names of these files are accidentally mixed up.

To recap
1. Open attachment 142153 [details]
2. Edit paragraph style Contents 2
3. change Before text indent to 1,00 cm and First line to -0,40 cm
4. Apply and observe the disappearing dots.

Arch Linux 64-bit
Version: 6.2.0.0.alpha0+
Build ID: 8447d31e529985ef7fc71933f0e55685530f9fc9
CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on June 14th 2018

Arch Linux 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Conclusion: 
If text in paragraph is short enough to fit to Before Text indent minus negative First Line, first tab will jump only to Before Text position. 
In that case, right align tab will not work in ToC, it'll stay in Before Text position instead of jumping to the right. 

I don't see significant value or probability in fixing this. But explanation would be nice.

Bug ist still present

Version: 6.3.1.2
Build-ID: b79626edf0065ac373bd1df5c28bd630b4424273
CPU-Threads: 4; BS: Mac OS X 10.12.6; UI-Render: Standard; VCL: osx; 
Gebietsschema: de-AT (de_AT.UTF-8); UI-Sprache: de-DE
Calc: threaded

Timur, I agree with your conclusion.

*** Bug 143589 has been marked as a duplicate of this bug. ***

(In reply to QA Administrators from comment #19)
> Dear zerebro,
> 
> To make sure we're focusing on the bugs that affect our users today,
> LibreOffice QA is asking bug reporters and confirmers to retest open,
> confirmed bugs which have not been touched for over a year.
> 
> There have been thousands of bug fixes and commits since anyone checked on
> this bug report. During that time, it's possible that the bug has been
> fixed, or the details of the problem have changed. We'd really appreciate
> your help in getting confirmation that the bug is still present.
> 
> If you have time, please do the following:
> 
> Test to see if the bug is still present with the latest version of
> LibreOffice from https://www.libreoffice.org/download/
> 
> If the bug is present, please leave a comment that includes the information
> from Help - About LibreOffice.
>  
> If the bug is NOT present, please set the bug's Status field to
> RESOLVED-WORKSFORME and leave a comment that includes the information from
> Help - About LibreOffice.
> 
> Please DO NOT
> 
> Update the version field
> Reply via email (please reply directly on the bug tracker)
> Set the bug's Status field to RESOLVED - FIXED (this status has a particular
> meaning that is not 
> appropriate in this case)
> 
> 
> If you want to do more to help you can test to see if your issue is a
> REGRESSION. To do so:
> ...
> 
> Thank you for helping us make LibreOffice even better for everyone!
> 
> Warm Regards,
> QA Team
> 
> MassPing-UntouchedBug

Since I had reported the duplicate bug report https://bugs.documentfoundation.org/show_bug.cgi?id=143589 I also got an email for this bug. I checked this bug again with my own example from #143589 and also with the first one supplied with this bug report. I did my test with

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 218a7650a5cf03f895bed19c68d6f02daec536e9
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded

currently the newest one I could get. I found out that the bug is still present in this version: notably "rd 1" and "r 1" are still there without a tab with dots as filling characters after newly generating the TOC in the first example supplied with this bug report.

(I did not alter the status field preset to NEW, although I think, it should be CONFIRMED).