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,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:
https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
 
Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-NeedInfo-Ping