I would assume it was some convenience change, trying to detect that some character DF spans the whole paragraph, and treat it as it's paragraph DF ... but yes, bibisect could answer.

Created attachment 177423 [details]
Bibisect log

Losing Character DF when applying Paragraph Style, bisected to:

    commit 3c0805e1f4f4d14e92c7e655d59c87de5c207e48
    Author:     Miklos Vajna <vmiklos@collabora.co.uk>
    AuthorDate: Thu May 14 11:34:33 2015 +0200
    Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Thu May 14 11:39:16 2015 +0200
    
        tdf#86639 SwEditShell: when setting para style, reset char attrs if needed
    
        The old internal RTF filter used to call SwTxtNode::SetAttr() without
        setting SetAttrMode::NOFORMATATTR, so character attributes which cover
        the whole node got converted to paragraph attributes.  The new UNO
        filter goes through SwXText::insertTextPortion(), which sets
        SetAttrMode::NOFORMATATTR, so this doesn't happen. The result of this is
        that when the UI sets a new paragraph style on the text node, then such
        character attributes are no longer removed.
    
        Given that in RTF you can't really have character properties on a
        paragraph, going back to the document model produced by the old internal
        filter doesn't sound like the good direction -- not to mention that
        changing SwXText::insertTextPortion() this way would be an implicit API
        change.
    
        Fix the problem by tweaking SwEditShell::SetTxtFmtColl() instead, so
        that it removes these full-text-node character attributes, too. The
        logic in SwTxtNode::RstTxtAttr() can be extended later if necessary to
        delete more attributes, but to be on the safe side, just handle the bare
        minimum necessary to fix the problem for now.
    
        Change-Id: I5faa3226fc0f9c18e005da185fe0830d8c393256

https://cgit.freedesktop.org/libreoffice/core/commit/?id=3c0805e1f4f4d14e92c7e655d59c87de5c207e4

> regression

Sigh. A regression is something that works *worse* than before. Not every change is a regression.

So what we have here? There is a UI convention established since early suite days, that setting character attributes to a whole paragraph sets them to paragraph. We have an artificially constructed case, that employs the external format (or filter) deficiency, that *paragraph properties* are exported/imported as character properties. So the truth is: the property that you inspect is *originally* paragraph property, and only end up as whole-paragraph text portion because of some deficiency. And we have a code explicitly created to handle such special case as paragraph properties, which is consistent with the mentioned UI convention, consistent with the observed deficiency, and thus IMO completely OK. So what is the actual *problem* (i.e., something that prevents you from making your job done) here, that was possible before the "regression"?

I thank you for the bibisect, but I really can't see how it is reasonable to mark things this "automated" way.

> Sigh. A regression is something that works *worse* than before. 
In my perception it's 'worse', in the sense of Character DF getting removed by applying Paragraph Style. But obviously it depends on what counts as a regression. Developer point of view surely different from user point of view..

> Not every change is a regression.
True


> So what we have here? There is a UI convention established since early suite
> days, that setting character attributes to a whole paragraph sets them to
> paragraph. 

> We have an artificially constructed case, that employs the
> external format (or filter) deficiency, that *paragraph properties* are
> exported/imported as character properties. So the truth is: the property
> that you inspect is *originally* paragraph property, and only end up as
> whole-paragraph text portion because of some deficiency. And we have a code
> explicitly created to handle such special case as paragraph properties,
> which is consistent with the mentioned UI convention, consistent with the
> observed deficiency, and thus IMO completely OK. So what is the actual
> *problem* (i.e., something that prevents you from making your job done)
> here, that was possible before the "regression"?

It's working unexpected; from user perspective. With code knowledge you're surely capable of explaining why it happens. 

> I thank you for the bibisect, but I really can't see how it is reasonable to
> mark things this "automated" way.

The "regression" part is based on the observation prior post. It did function (why/how/what) required in depth knowledge. And well 'regression' tag can be removed if that's the annoyance...

---
FWIW: bug 146660 comment 10 steps 1-3 have the same problem source. So DOCX is only different way for exposing the problem. The behaviour is a contrary to what a user expects (how it's formatted accordantly to the Style Inspector)

A bug report obviously focus on cases where it doesn't work out as expected. No clue about the extend - how common - the problem actually is.

For me there is no bug there: 
- paragraph direct formatting (lines 2 and 3) -> reset if new paragraph style applied
- character direct formatting (word ipsum in first line) -> kept if new paragraph style applied.

Best regards. JBF

(In reply to Jean-Baptiste Faure from comment #5)
> For me there is no bug there: 
> - paragraph direct formatting (lines 2 and 3) -> reset if new paragraph
> style applied
> - character direct formatting (word ipsum in first line) -> kept if new
> paragraph style applied.
> 
> Best regards. JBF

Forgot to add that the observed behavior has nothing to do with docx, it is observed when applying paragraph style on the odt.

Version: 7.3.4.0.0+ / LibreOffice Community
Build ID: f668663d63d5b0f37d4727b54585c3b67ab92162
CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Ubuntu_20.04_x86-64
Calc: threaded

Best regards. JBF

Dear Telesto,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp