Created attachment 97949 [details]
Screenshot Entries tab : tooltip ok, listbox to "None"

Reproduced with attachment 97948 [details], already with 3.3.0.

Win 7 Pro 64-bit, LibO Version: 4.4.1.2
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
Locale: fi_FI

Ubuntu 14.10 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

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

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

I would like to add that every time a document with a bibliography is saved, even without adding any new biblio entries or updating the index, the index-entry-bibliography text:style-name in content.xml has extra data added to it.

In the Entries tab of Edit Index/Table, every time the tab is switched back and forth or the Type is selected back and forth, or even just visiting the Entries tab and OKing, causes extra data to be added to the style-name for each element in the Type.  You can see it in the tooltips.

Version: 4.4.2.2
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6

Hello.

I reproduce this in Version: 5.0.4.1
Build ID: 2def61bcbb29a7a8611b833682fe1291910b11ad
Locale: es-MX (es_MX)

Version: 5.1.0.0.beta1+
Build ID: 9b6d78cc68e9dc644bf2d06b358049de3cd3ee8f
Threads 8; Ver: Windows 6.2; Render: default; 

TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-1, Time: 2015-12-03_20:08:55
Locale: es-MX (es_MX)

On Windows XP SP3 and Windows 10

Created attachment 121216 [details]
example of bibliography

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

Still reproducible in 5.1.4.1.

Hi there.

Reproducible with Version: 5.2.0.0.beta1
Build ID: 1e9933ef611c66bcded94b84052543c78cf1c223
CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; 
Locale: es-MX (es_MX)

Still affects 5.3.0.3.
As an added "bonus", now also last character of text fields gets eaten away (filed that as bug 106092).

Still an issue in 6.0.0 rc 1.

I tested old versions 3.6.7, 4.0.x, 4.1.x, and 4.2.0 beta 1:
* the last version where bibliography entries' character style is interpreted normally, is 4.1.6 rc 2,
* the first one where it breaks is 4.2.0 beta 1.
So this is a regression introduced in 4.2 branch.

(In reply to Buovjaga from comment #2)
> Reproduced with attachment 97948 [details], already with 3.3.0.
> 
> Win 7 Pro 64-bit, LibO Version: 4.4.1.2
> Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
> Locale: fi_FI
> 
> Ubuntu 14.10 64-bit
> LibreOffice 3.3.0 
> OOO330m19 (Build:6)
> tag libreoffice-3.3.0.4

That document was created with LibO 4.2.4 rc 1 - i.e. the document itself is already broken and can't be used for testing like this. You can try with a blank document in 3.3.0 if you want to confirm.

Setting version to 4.2 and also adding "regression" keyword.

Created attachment 138761 [details]
Bibliography test - known good file

Bibisected (properly this time), and identified a commit that indeed plausibly could have introduced this bug (unlike the commit pointed out by my first attempt where I used a sparse bibisect repository without realising it - sorry!)
 a89830a7c9075fb7180a502bf2cbd7c86490b387 is the first bad commit

    commit f4fd558ac9d61fe06aa0f56d829916ef9e5ee7b9
    Author:     Matteo Casalin <matteo.casalin@yahoo.com>
    AuthorDate: Fri Aug 9 22:11:53 2013 +0200
    Commit:     Tor Lillqvist <tml@iki.fi>
    CommitDate: Tue Aug 13 08:05:41 2013 +0000
    
        String to OUString and some reduction of scope
    
        Change-Id: Ia760c5f3f8c158bea30be3102841a66330e5180a
        Reviewed-on: https://gerrit.libreoffice.org/5339
        Reviewed-by: Tor Lillqvist <tml@iki.fi>
        Tested-by: Tor Lillqvist <tml@iki.fi>


Diff of changes by this commit:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=f4fd558ac9d61fe06aa0f56d829916ef9e5ee7b9

Matteo, this was your patch (admittedly long time ago), would you be able to take a look?

Hi Mihkel, thanks for bibisecting and reporting.
I will try to address it in the next few days.

Short update: I'm still working on it... I fixed two issues with that commit, but have not seen the "expected results" with the known good file, yet.

current master: with attachment from comment #14 :

* the tooltip text is correctly generated in SwTokenWindow::CreateQuickHelp
  but i can't get the tooltip to actually show up on screen
  which looks like an unrelated issue or maybe it's intentional
  and there is some obscure setting that would enable tooltips

* the list box does show the style "Emphasis" for the "Au" button
  of the "Book" entry template, which is the only one in the document
  that has a character style applied

the attachment from the description has corrupted style name references
on its entry templates so it's no surprise that nothing is displayed.

but, on 5.4.6.2 i'm not seeing the style in the listbox;
would be nice to bisect the fix and backport it.

don't have a 6.0 right now to test so adding backportRequest for both 5.4 and 6.0

Thanks, Michael. I feel weird adding a bibisectRequest to a bisected bug, but here goes :)

(In reply to Michael Stahl from comment #21)
> current master: with attachment from comment #14 :
> 
> * the tooltip text is correctly generated in SwTokenWindow::CreateQuickHelp
>   but i can't get the tooltip to actually show up on screen
>   which looks like an unrelated issue or maybe it's intentional
>   and there is some obscure setting that would enable tooltips

I see the tooltip perfectly fine on current master - ?!

> ...
> would be nice to bisect the fix and backport it.

Bibisected; and while I couldn't get Git to show me a proper commit message for some reason, it did consistently identify this commit as the first "fixed" one:

    61d60487533bc93c1207747719d6382eaaa2c4f7 is the first fixed commit
    commit 61d60487533bc93c1207747719d6382eaaa2c4f7
    Author: Jenkins Build User <tdf@pollux.tdf>
    Date:   Sun Feb 11 16:09:25 2018 +0100

        source 34b98af8e5a4e568d8316700bea1ce604d825ce8

Diff of changes by this commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=34b98af8e5a4e568d8316700bea1ce604d825ce8

Matteo, you said back in January that you "fixed two issues with [old commit f4fd558ac9d61fe06aa0f56d829916ef9e5ee7b9], but have not seen the "expected results" with the known good file, yet" - does this new commit mean you figured it out? Or is there something still to be done?

thanks for bisecting that!

backported to libreoffice-6-0 as commit c6e8460a5b47fa6fa971dde2a89e80662b6e97ae
backported to libreoffice-5-4 as commit df041d902eafb1e273eb360103252994bbd2cde2

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=829674fa46c8c07584022b84bbc8c3d877b895c2

Related: tdf#77919 GetPosPixel() is relative to parent, not grandparent

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7d95ef515c604bf67e68fd4824aa0073d8a76d07&h=libreoffice-6-0

Related: tdf#77919 GetPosPixel() is relative to parent, not grandparent

It will be available in 6.0.4.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

(In reply to Mihkel Tõnnov from comment #24)
> Matteo, you said back in January that you "fixed two issues with [old commit
> f4fd558ac9d61fe06aa0f56d829916ef9e5ee7b9], but have not seen the "expected
> results" with the known good file, yet" - does this new commit mean you
> figured it out? Or is there something still to be done?

Hi Mihkel, all,
   commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=34b98af8e5a4e568d8316700bea1ce604d825ce8 and (previous) commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=e3e9870aacdd8df1f449b802cd9dc3fbd083182f are the two I was mentioning back at the beginning of January, which did not provide the expected results (with the "known good file"). I decided to push them anyway, not referring to this bug issue since in my tests they didn't solve it, and I was now slowly trying to see if they introduced the issue and some later commit added further deviations.
I didn't find any other regression in my commit from 2013 (these 2 are definitively enough) so since the issue is fixed I see nothing else still to be done.

this bug was difficult to find, add some more detailed description of ODF impact