I am confirming this bug. Status set to NEW. I am also setting the version to "v3.5.7.2 release" as I can reproduce this issue under Crunchbang 11 running both v3.5.7.2 and v4.1.0.4.

It is worth noting that the bug relates to styles rather than paragraphs. It can be created by: 

1. Creating a new Writer document.
2. In the "Default Style" paragraph style type "AAA" and ENTER; "BBB" and ENTER; "CCC" and ENTER.
3. To "BBB" apply the "Text Body" paragraph style.
4. To "CCC" apply the "Quotations" paragraph style.
5. Select any multiple of lines and immediately watch the default tab marks on the ruler disappear. Choosing Format > Paragraph... also displays the Paragraph dialog without the Tabs tab.

Creating multiple paragraphs (e.g., by ENTER at the end of "BBB") of the same style and then selecting paragraphs of the same style does not exhibit this problem. I would be surprised if this bug is not a duplicate of some earlier report.

Created attachment 84948 [details]
ZIP of two ODTs containing several common styles.

My prior comment is not entirely accurate it would seem. I am attaching a couple of example files for others to test. One is created under v3.5.7.2 and the other under v4.1.0.4. They both include several common styles (Default, Text body, Quotations, Title, Subtitle, Heading 1, Heading 2, List 1, and Numbering 1) with a single line / paragraph for each style.

If I select multiple lines then the effect previously described occurs EXCEPT in these instances:

- Default + Text body
- Title + Subtitle
- List 1 + Numbering 1

For some reason these selections (perhaps because of type grouping?) do allow tab manipulation, either via the ruler or the Format > Paragraph... menu.

Re-tested under GNU/Linux x86_64 using:
v3.3.4.1 OOO330m19 Build: 401
v3.4.6.2 OOO340m1 Build: 602
v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
v3.6.7.2 Build ID: e183d5b
v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
v4.2.8.2 Build ID: 48d50dbfc06349262c9d50868e5c1f630a573ebd
v4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
v4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432

... by opening the v3.5.7.2 ODT in attachment 84948 [details]. In all versions comment 2 still applies. Version set to "Inherited from OOo".

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

Selecting multiple paragraphs that have different tab stop positions and/or different number of tab stops will not show the tab stops in Paragraph → Tabs so it is not possible to delete them.  If you enter a new value then it will replace what was there.
1. New Text Document.
2. Type “test” and Enter.
3. Type “test”.
4. Right click on first paragraph, Paragraph → Tabs and enter 1cm, New and OK.
5. Place cursor before first paragraph and Tab.
6. Select both paragraphs, Paragraph → Tabs.
Result:
No values in Position.
7. Still in the Tabs dialogue, Delete all and OK.
Result:
First paragraph still has 1cm tab.
8. Select both paragraphs, Paragraph → Tabs, enter 2cm, New and OK.
Result:
First paragraph has changed from 1cm to 2cm and 1cm tab has been deleted.  Second paragraph has the option to tab to 2cm.

Alternate:
4. Right click on first paragraph, Paragraph → Tabs and enter 1cm, New, enter 2cm, New, and OK.
5. Place cursor before first paragraph and Tab once.
8. Select both paragraphs, Paragraph → Tabs, enter 2cm, New and OK.
Result:
In Paragraph → Tabs, each paragraph has a 2cm tab stop.  The first paragraph has lost its 1cm tab stop.

On the Alternate step 5 if you tab twice and change step 8 to 1cm then the result is both paragraphs have a 1cm tab stop.  Because the first paragraph has lost its 2cm tab stop, it reverts to using an automatic tab stop.

There is probably no way to show differing tab stops without having a convoluted dialogue (a tree list).  The documentation should be updated to say something about changing tab stops for multiple paragraphs will result in losing multiple tab stops set per paragraph and all paragraphs will be set to the new value.  Also a dialogue warning message might be considered.  Or, you know, use styles.

Windows Vista 64
Version: 4.4.3.2
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16

Hi,

If the paragraphs contain different tabstopps, I mark them and click in the dialog on "delete all", but they are still there.

But if I mark them, set any tabstopp and click "delete all", they are gone.

So it seems that "delete all" works only if the marked paragraphs contain identical tabstopps.

It would be helpful to mark some paragraphs containing different tabstopps and to remove all by clicking on "delete all".

Many thanks,
Gottfried

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

Bug still present.

Version: 5.2.5.1
Build ID: 1:5.2.5-1~bpo8+1
CPU Threads: 2; OS Version: Linux 4.9; UI Render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group

I just marked bug 66874 as a duplicate and copied the Version, Hardware and OS info from there to here. There are some useful comments in that bug report as well, regarding how to reproduce the bug with paragraphs with different indents and whether this should be marked WONTFIX (I think it should not).

I tried and it works for me now, many thanks!

Version: 6.1.2.1
Build-ID: 1:6.1.2~rc1-0ubuntu0.16.04.1
CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: gtk2; 
Gebietsschema: de-AT (de_AT.UTF-8); Calc: group threaded

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

First, I think two issues got mixed up here:

1. This bug 63356 is about Format -> Paragraph... in some cases missing the Tabs-tab completely.

2. Bug 90910 was about a slightly different issue: In Format -> Paragraph... the Tabs-tab exists, but in it, the button "Delete all" does not work as expected.

I think the marking of bug 90910 as a DUPLICATE of this bug 63356 was incorrect, so I just removed that DUPLICATE status.

I think comments 5, 6, 7, 12 can be ignored for this bug 63356, because they relate to bug 90910, and I hereby revert the change of comment 12 from NEW to RESOLVED/WORKSFORME, so setting the status back to NEW.


Then, answering the question if this bug 63356 is still present: Yes, I can still reproduce it using the sample documents in attachment 84948 [details] and attachment 116501 [details]. It seems to me that the disappearance of the Tabs-tab is most certainly reproduced when Indent-settings between the paragraphs differ. The bug does not always occur with paragraphs of different Styles, Bullets or Numbering if the Indent-settings are the same, especially if those Indent-settings were set to the same value for all those paragraphs at the same time. Also, a difference in the actual tab positions between the selected paragraphs does not necessarily reproduce the disappearance of the Tabs-tab. In short, to reproduce this bug select paragraphs with different Indent-settings.

Version: 6.1.5.2
Build ID: 1:6.1.5-3~bpo9+1
CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group threaded

Version: 6.3.0.0.beta2
Build ID: 1:6.3.0~beta2-2
CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Bug still present. I can still reproduce it using the sample documents in attachment 84948 [details] and attachment 116501 [details].

Version: 7.2.0.0.beta1 / LibreOffice Community
Build ID: 20(Build:0)
CPU threads: 2; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Debian package version: 1:7.2.0~beta1-3
Calc: threaded

Bug still present. I can still reproduce it using the sample documents in attachment 84948 [details] and attachment 116501 [details].

Version: 7.4.5.1 / LibreOffice Community
Build ID: 40(Build:1)
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: x11
Locale: en-US (en_US.UTF-8); UI: en-US
Debian package version: 4:7.4.5-3
Calc: threaded

Since LO 7.5, the Tabs-tab is shown when paragraphs of differing indent
are selected.

    Version: 7.5.5.2 (X86_64) / LibreOffice Community
    Build ID: 50(Build:2)
    CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: x11
    Locale: en-IE (en_US.UTF-8); UI: en-US
    Debian package version: 4:7.5.5-4~bpo12+1
    Calc: threaded

I tested the sample documents in attachment 84948 [details] and attachment 116501 [details]
again. Observations:

- The Tabs-tab is always shown now.
- Adding a new Tab works. However, with differing First line indent,
  the Tabs may end up in different positions relative to the page
  margin. For example, when you select two paragraphs with 0cm and 1cm
  First line indent, then in Paragraph > Tabs create a New Tab at 2cm,
  the Tabs will respectively be at 2cm and 3cm from the left margin.
  This is different than when the paragraphs of 0cm and 1cm First line
  indent are selected individually and New Tab at 2cm are added
  individually, in which case they will both be at 2cm from the left
  margin.
- Deleting a Tab on multiple paragraph works in some cases. E.g. when
  selecting the same paragraphs that were also selected together when
  the Tab was added, the 2cm tab shows up again and Delete works.
- The ruler is still disabled when multiple paragraphs with different
  indent are selected.  When the ruler is double-clicked, Paragraph >
  Borders will pop up and the user can now see the Tabs-tab there.

The change probably came from this commit of 2022-08-03 by
Pranam Lashkari:

    sw: always show "tabs" tab in the paragraph dialog for multiple paragraphs
https://git.libreoffice.org/core/+/9f7b3e2c47ff56c9529b3359e2459130ee922808%5E%21

It was merged in LibreOffice 7.5 Alpha 1, which matches that I was
still able to reproduce the bug in 7.4.5.1, but not in 7.5.5.2 anymore.

From the commit message:
> This change makes no effort to show the common tab stops of all
> selected paragraphs on the UI, which would probably make sense, but
> can be done in a follow-up change.

Similarly, I think that any follow-up regarding unexpected behavior in
actual use of the Tabs-tab better be discussed in new bug report(s).
The main issue of this bug 63356 (the complete inability of editing
tabs) has been solved, so I am setting this to RESOLVED/FIXED.

Thanks to Pranam Lashkari for solving this!