Created attachment 163258 [details]
Example file

Created attachment 163259 [details]
Screencast

I confirm it with

Version: 6.4.4.2 (x64)
Build-ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff
CPU-Threads: 4; BS: Windows 10.0 Build 19041; UI-Render: GL; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

Telesto,

Could this be the same problem as bug 40258, which applies the extra
bullet at the start of a printed (rather than a pasted) selection?

(In reply to Terrence Enger from comment #4)
> Telesto,
> 
> Could this be the same problem as bug 40258, which applies the extra
> bullet at the start of a printed (rather than a pasted) selection?

Don't think so; that one was already in 3.3.0; this started between 3.3.0 and 3.5.7.2

Adding bibisect request. to check oldest

Created attachment 163491 [details]
bibisect-linux-64-5.2, tail of terminal output

Working in bibisect-linux-64-5.2 repository on debian-buster, I see
that the bug started:

    Author: Caolán McNamara <caolanm@redhat.com>
    Date:   Tue Jul 12 20:31:52 2016 +0100

        Resolves: tdf#101457 gtk3 clipboards have to live to end once created
    
        was Related: rhbz#1351369 gtk3 clipboards have to live to end once created
    
        like the other platforms do
    
        (cherry picked from commit 962e0bb4b31265b046fe4fb57d3087e20f5fe4ef)
    
        Change-Id: I31340254573d13dc808d1e3038e3a36ae97f6c22
        Reviewed-on: https://gerrit.libreoffice.org/30010
        Tested-by: Jenkins <ci@libreoffice.org>
        Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>


I am removing keyword bibisectRequest and adding bibisected, bisected.

In local-built master, the extra bullet on the pasted heading
"Halifeliğin ..." changed with the heading level of the line copied.

1. Not Normal, rather trivial, whoever confirms should pay attention, especially for Telesto that has enormous number of ill-categorized bugs. 
2. Bibsect is suspicious and I'd assume wrong because for GTK and in LO 5.2 when this behavior is said to be already in 3.5.
3. Finally, I'd say NotABug because "Halifeliğin kaldırıldığı .." is already bulleted, seen in ODT, so makes sense to copy that to the new file.
I wrote a few times that to reproduce steps is equal to confirm the bug, especially in those formatting issues

I wrote a few times that to reproduce steps is *not* equal to confirm the bug, especially in those formatting issues that.should tried to be understood first,

Created attachment 163746 [details]
screenshot, start of text to be copied

(In reply to Timur from comment #9)
> 3. Finally, I'd say NotABug because "Halifeliğin kaldırıldığı .." is already
> bulleted, seen in ODT, so makes sense to copy that to the new file.

I do not see a bullet.  Are you looking somewhere else?

Created attachment 163747 [details]
bibisect in 43all, tail of terminal output

(In reply to Timur from comment #9)
> 2. Bibsect is suspicious and I'd assume wrong because for GTK and in LO 5.2
> when this behavior is said to be already in 3.5.

Indeed, the commit I stated to be last good in comment 7 is bad: it
does paste the extra bullet with SAL_USE_VCLPLUGIN=gen.


Turning my attention to bibisect-43all, I see that the pasted text
changed from no bullets at all to extra bullet on the first line with

        source-hash-a705aec5117fe9123236ebdeb0d6f271b83f8af4
    
        commit a705aec5117fe9123236ebdeb0d6f271b83f8af4
        Author:     Andras Timar <atimar@suse.com>
        AuthorDate: Fri Sep 16 16:20:09 2011 +0200
        Commit:     Andras Timar <atimar@suse.com>
        CommitDate: Sat Sep 17 10:18:18 2011 +0200
    
            add KeyID option to Language dropdown box

This version pastes the extra bullet with both gtk3 and gen.


There remains the question of when gtk3 for a time stopped pasting the
extra bullet.  I am not sure how much this informantion would be
worth.


I am leaving keywords unchanged w.r.t. bibisect, even though the
amount of backtracking I did to get here leaves me with reduced
confidence in the result.

(In reply to Timur from comment #9)
> 1. Not Normal, rather trivial, whoever confirms should pay attention,
> especially for Telesto that has enormous number of ill-categorized bugs. 
> 2. Bibsect is suspicious and I'd assume wrong because for GTK and in LO 5.2
> when this behavior is said to be already in 3.5.
> 3. Finally, I'd say NotABug because "Halifeliğin kaldırıldığı .." is already
> bulleted, seen in ODT, so makes sense to copy that to the new file.
> I wrote a few times that to reproduce steps is equal to confirm the bug,
> especially in those formatting issues

1_) Yes. Formatting & styles maybe not my best area. So it can surely happen me being wrong. And yes, Dieter pointed me already to some quirky styles (Default Paragraph Style has outline and number set). I still assume it shouldn't happen, but it's not a straight forward answer I initially assumed 

'enormous number' of bugs (yes). Ill-categorized. Not sure what 'Ill- categorized' stand for.. Being attached to meta-bugs? Or should I add see also source documents? For bugs being totally unrelated, except sharing the same bug doc (or an except of that?)  

B) True, can happen

C) Comment 11

(In reply to Terrence Enger from comment #11)
> Created attachment 163746 [details]
> screenshot, start of text to be copied
> 
> (In reply to Timur from comment #9)
> > 3. Finally, I'd say NotABug because "Halifeliğin kaldırıldığı .." is already
> > bulleted, seen in ODT, so makes sense to copy that to the new file.
> 
> I do not see a bullet.  Are you looking somewhere else?

In XML:
<text:list-item>
<text:h text:style-name="P7" text:outline-level="3">Halifeliğin kaldırıldığı gün yapılan önemli gelişmeler:</text:h>
</text:list-item>

Seen in Writer if style changed back from Heading, ex. to Default.

NotABug also per bug 49076.

(In reply to Telesto from comment #13)
Ill-categorized. Not sure what 'Ill-categorized' stand for.. 


Like here and in many your reports, you leave Normal when it's Minor or Trivial. I saw that you put Critical when it should be Normal, problem with a single document.
You don't add See Also to your own and other similar bugs. 
You add original attachment, like here 15 pages and 11 MB, instead of minimal sample, like here a few lines, that should make you and reviewers understand issue better.

(In reply to Timur from comment #14)
> 
> In XML:
> <text:list-item>
> <text:h text:style-name="P7" text:outline-level="3">Halifeliğin kaldırıldığı
> gün yapılan önemli gelişmeler:</text:h>
> </text:list-item>
> 
> Seen in Writer if style changed back from Heading, ex. to Default.

That looks like the pasted text.  I saved the attached file as .fodt,
and in it I see "the" line outside text:list-item and text:list markup
(lines rewrapped):

         <text:p text:style-name="P7">
             8 Nisan 1924’te Şeriat Mahkemeleri kapatıldı.
         </text:p>
        </text:list-item>
       </text:list>
       <text:h text:style-name="P6"
               text:outline-level="3">
           Halifeliğin kaldırıldığı gün yapılan önemli gelişmeler:
       </text:h>
       <text:list xml:id="list202403961115686"
                  text:continue-numbering="true"
                  text:style-name="List_20_4">

> 
> NotABug also per bug 49076.

The XML you quoted in comment 14 is indeed consistent with the extra
bullet in the pasted text.  Is your extra "text:list-item" markup not
a bug in itself, wherever it came from?

Bug 49076 is marked as RESOLVED FIXED, but
https://bugs.documentfoundation.org/show_bug.cgi?id=49076#c19
complains that the bug is still present.

(In reply to Terrence Enger from comment #16)
> The XML you quoted in comment 14 is indeed consistent with the extra
> bullet in the pasted text.
We just open ODT as ZIP and read Contents in text viewer. 


>  Is your extra "text:list-item" markup not
> a bug in itself, wherever it came from?
No, it would be a pointless bug and further clogging of Bugzilla  unless we know steps how to reproduce and it's not as expected. 


> Bug 49076 is marked as RESOLVED FIXED, but
> https://bugs.documentfoundation.org/show_bug.cgi?id=49076#c19
> complains that the bug is still present.
Yes, but not convincing and without details to test, big remained closed. 
I tested myself and it seems as expected, copy of full paragraph copies numb/bullet while copy of part doesn't.

@Telesto

I am sadly confused by the numerous bug reports about bullets and
lists:

  - BZ query of open Writer bugs with comment containing string
    "bullet" has 217 hits

  - since 2020-07-12, a query of Writer bugs with comment containing
    string "bullet" includes 18 bugs which you have submitted.

Would you be willing to do a summary of bug reports, saying what is
different or similar among them?  Such a summary could helpfully
include at least all your recent "bullet" reports and any bugs they
reference.  Broader coverage would require more work, but it still
might be worthwhile.


Please give this your consideration,
Terry.

(In reply to Terrence Enger from comment #18)
Looking through my own list. 

Bullets + Track changes is about Track changes not handling bullets properly. (M. Stahl)
Bullets and slow is probably Idle/Timer; (Tobias Madl/Meeks)
Heading gets bullet means a Heading without bullet gets a bullet. (Inherited)
Bulleted list disappearing after paste undo redo is about throwing the bullet list away. So about UNDO-redo code. (M. Stahl)
RTF code -> Miklos
DOCX -> Miklos/ Justin


Bullets and file formats is tricky area. RTF bullet are not per definition a or DOCX bullet. And RTF Special Paste isn't equivalent for Save as RTF. Even a bullet pasted from a DOCX pasted with Special Paste RTF can behave differently. Even worse an DOCX saved to ODT. They ODT inherits all the flaws of the DOCX or DOC. So there a clean ODT files and those based on conversion.

Bullet and table is bullet and table..

So seeing not many similarity's. Ideally I prefer bug which can be bibisected.. You know for sure if it's shared.

Bug 135301 and bug 135292 are more or less the same different consternation of the same issue. On in general the other specific to track changes. It might be that the track changes variant isn't solved with the 'general' fix.. I might be the case.

Another beloved area of me is the anchoring area. There are at minimum two types (maybe even 3) of 'to character' 'to paragraph'. Shape anchor to paragraph is subtle different from image to paragraph.. Which produces quite some fun. Even they DOCX anchor behavior is can be different if imported in LibreOffice.

Most page loops (DOCX/DOC/ODT) are image anchoring issues. Long short freezes too. Text layout engine is running over time to position the anchor an fails. Ideally it bails out.. Image on top of text (without wrap). But quite number of cases where this doesn't happen. Anyhow they area there is currently not much to add. Except being flawed. They anchor to paragraph (for images/not shapes) is/was pretty stable.. To character can be problematic, IMHO. But will how it goes.. it's the default since 6.4. Anyhow in that area I may overdo it a little. Except of adding examples to test if someone someday wants to fix they anchoring [they person who touches it will be hunted for years based on my estimation and lots and lots of frustration.]  

 Text page layout so much fun: Timers, footnotes, tables, anchors, text shaping (Harfbuzz) comes together. 
Footnotes pushing text to different area, triggering shape measurement (Harfbuzz (expensive) and text break (ICU). Different text break trigger anchor movement (so different position of shape). Text must be layouted again around the shape (wrap). Which triggers a footnote movement. Which triggers to table move. Which triggers lay-outing of embedded table. And footnotes starting to move again.. 

Currently they tables are optimized.. no crashing.. So instead of crashing we opt for looping :-) they table code being stable. So take a short cut.. stop rendering. you end up with tables which shift on clicking :-). Which could also be a timer stopping to soon/late. 

But, yes, I do not really I'm guilty of not always using search in advance.

Telesto, you are flooding Bugzilla in a negative way and I wish Xisco noticed that and warned you. 
Many bugs are meaningless, I already explained why but you just continue. 

Look Bug 134773 and bug 134749, and all bugs on that file are of no use, file itself is wrong and crashes and only crash was worth reporting, instead you are reporting bullets when default style has bullets!?

Anchoring and layout and text flow are another pointless group of bugs that you report for yourself, I doubt anyone will look at that ans solve one by one.
How can you not comprehend how to single out what is reparable and what is bad design and not easily.

@Telesto,

You are filing bug reports much faster than I can work through them.
I think that I can be more useful to LibreOffice by moving my
attention elsewhere.

(In reply to Terrence Enger from comment #21)
> @Telesto,
> 
> You are filing bug reports much faster than I can work through them.
> I think that I can be more useful to LibreOffice by moving my
> attention elsewhere.

I totally agree. Telesto, I will explain it in a PM.

(In reply to Timur from comment #20)
> Telesto, you are flooding Bugzilla in a negative way and I wish Xisco
> noticed that and warned you. 
> Many bugs are meaningless, I already explained why but you just continue. 

-> Many bugs.. (list them all) meaningless (assessment; with an explanation/argumentation) Except discontent, finding it unimportant. 

I already explained why; so it's easy to repeat then or give pointers. Got some summary feedback 

> 
> Look Bug 134773 and bug 134749, and all bugs on that file are of no use,
> file itself is wrong and crashes and only crash was worth reporting, instead
> you are reporting bullets when default style has bullets!?

Bug 134749 (wrong bug). Bug 134773 is my fault; not noticing the style. However still think there was a truth to it. 

File itself is wrong -> technical assessment. How do you conclude the file is wrong? That the file crashes doesn't say something about the file itself. 

> Anchoring and layout and text flow are another pointless group of bugs that
> you report for yourself, I doubt anyone will look at that ans solve one by
> one.

-> Can't even solved one by one. Isn't desired approach anyhow. However we have total different mindset. You see bugs as isolated problems which can solved by themselves. I see bugs as expressions/ symptoms of a problem. Sometimes a bug fixes solved 20 bugs which seems unrelated. In this case those bugs (related to anchors) are more intended as documentation for testing proposes. Lots of the bugs in the anchor / wrap meta bug report have a shared root cause. Even the empty pages in documents are related to anchoring. Even then when they can be bisected to a different commits. It might be that a commit only accelerated the presence of something underlying being flawed. Even apparently total unrelated bug as FILEOPEN DOCX looping. So really need in depth understanding. And I'm surely not claiming to be 'an expert' be I do some patterns


I sometimes get 4 different backtraces for the same crash bug. The pattern sometimes arises over time.  

> How can you not comprehend how to single out what is reparable and what is
> bad design and not easily.

A) Bug tracker should contain everything. Not limited to what's reparable or not. Nor if its really important or less important. It's only a bug database containing problems/symptoms/issues and enhancement request. Ideally nicely categorized into Meta bugs.  

I'm surely know capable to asses 'reparable'. They DOCX/DOC compatibility is sometimes quite hard. So not likely to happen in short of medium term. Hover I can't access what's doable or not. Which looks 'easy' superficially can be pretty complex if you ask a DEV. And I really don't know that DOC specifications. So are there features inside LibreOffice which can't be exported? And how are they converted? I can't asses really. 

And what does reparable mean without an actual developer being around since years. What to make of Base bugs? Or MacOS bugs. 
And they image handling was pretty bad design, IMHO. However it did change and solved quite a number of issues. I can't tell what the future brings

"How can you not comprehend" not rally a nice tone. I'm still undecided how I should read it. As arrogance/ frustration / or you're style of of communicating in general. I do notice you're "complaining" a lot. Even at people who report something a bug tracker the first time. Something about 'use search'. As if they should know how it works. Or should people who make account get a manual to read and a making an digital exam to be allowed on the bug tracker?   

And you don't even do yourself what you ask from others. You're bug reports don't contain any information of tested versions.. You're report come structurally with detailed description how created? You 're comments are always precise, exact, complete, so everybody can follow without asking again. 
Having exact knowledge of the topic, not sometimes erratically marking things as duplicate. So stacking stuff together which doesn't belong. So we have 1 bug with 33 people in CC reporting similar things but not the SAME thing. And you operate as ghost. You come and go. Not attached to any bug doc in CC. 

You're free to ignore my bugs, if you dislike them. Dieter opted for that. I surely created a little flood of bugs; but not assuming it this is structurally. 

----
As about the UNCONFIRMED BUGS issue, I have a part in it, but only *a* cause. Majority of open bugs aren't from me. The problem is that hard to asses cases keep open as UNCONFIRMED as everybody ignores them (so stacking up). And some not being set to NEEDINFO. So i'm not the cause of that problem, I might accelerate it so the 1000 open bugs is reached early. You could introduce some HARDCASE status or something like that to get them out of UNCONFIRMED (if UNCONFIRMED is some kind of KPI). I surely looked at a number of those, but surely no clue what to make of save error using network. Or can't print with my Brother printer. Holding the middle between UNCONFIRMED and NEEDINFO (but with tendency to NEEDINFO)

And another part of the story is of course QA being understaffed IMHO. Based on my subjective perception are Xisco, Buovjaga, Aron, V Stuart Foote are less active at QA. As stating this as fact, not judgmental. So a backlog will build up pretty quick. 

@Terrence, can't asses you're motivation for QA work. I assume the point is not feeling to make any progress? Or is it more they depressing 1000 bug UNCONFIRMED count?