Bug 90446 - No connection to Thunderbird-Addressbook
Summary: No connection to Thunderbird-Addressbook
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Julien Nabet
Whiteboard: target:5.0.0 target:4.4.3
Keywords: regression
Depends on:
Reported: 2015-04-04 10:00 UTC by Robert Großkopf
Modified: 2015-04-09 08:23 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

error message as robert describes (12.79 KB, image/png)
2015-04-04 18:15 UTC, Doug

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2015-04-04 10:00:12 UTC
Connected with Base to Thunderbird-addressbook. Works well with LO, fails with LO
This message appears:
"The file $filename$ could not be loaded".

(Don't know it's the right text - translated it from German)
Comment 1 Doug 2015-04-04 18:15:55 UTC
Created attachment 114623 [details]
error message as robert describes

I encountered the same problem on Linux 32-bit OpenSuse13.3.  Additionally, once the database is created if one goes to `Edit`--> `Database Connection`, it will show the `default` TBird profile and then the same error.  Dialog boxes do not give any options for manually establishing a connection/finding a file.
Comment 2 Robert Großkopf 2015-04-04 18:32:54 UTC
Following comment1 from Doug I set this bug to NEW.
Comment 3 Julien Nabet 2015-04-04 21:14:40 UTC
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
Comment 4 Julien Nabet 2015-04-04 22:01:06 UTC
It's my fault, the regression is due to http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b92d8afbabe564de703f8bc083723d97e765011
I'm trying to change order there:
and there:
For the moment it doesn't work :-(
Comment 5 Julien Nabet 2015-04-04 22:13:34 UTC
Lionel: put you in cc because except revert the patch for tdf#39279, I'm a bit stuck. Any thought?
Comment 6 Lionel Elie Mamane 2015-04-04 22:49:41 UTC
I don't get an idea from reading the code. I would have to run under gdb, which I cannot do for the moment because I'm away from my development machine: in vacation.

Julien, if you "see" how your commit leads to this regression, I'm interested in the explanation. :)
Comment 7 Julien Nabet 2015-04-05 07:00:51 UTC
Here's console log:
warn:connectivity.mork:20874:1:connectivity/source/drivers/mork/MConnection.cxx:145: Can not parse abook mork file: /home/julien/.mozilla/firefox/pp8pi6dk.default/abook.mab
which shows that LO doesn't search Thunderbird/Icedove path.

Here's also some gdb session:
Breakpoint 1, connectivity::mork::OConnection::construct (this=0x2c2a750, url="sdbc:address:thunderbird:", info=uno::Sequence of length 1 = {...})
    at /home/julien/compile-libreoffice/libreoffice/connectivity/source/drivers/mork/MConnection.cxx:120
120	    sal_Int32 unittestIndex = url.indexOf(UNITTEST_URL);
(gdb) n
123	    if (unittestIndex == -1)
125	        OUString defaultProfile = m_pProfileAccess->getDefaultProfile(::com::sun::star::mozilla::MozillaProductType_Thunderbird);
126	        OUString path = m_pProfileAccess->getProfilePath(::com::sun::star::mozilla::MozillaProductType_Thunderbird, defaultProfile);
(gdb) n
127	        SAL_INFO("connectivity.mork", "DefaultProfile: " << defaultProfile);
(gdb) p defaultProfile
$1 = "default"
(gdb) p path
$2 = "/home/julien/.mozilla/firefox/pp8pi6dk.default"
Comment 8 Julien Nabet 2015-04-05 07:04:42 UTC
Also this:
(gdb) p *m_pProfileAccess
$5 = {_vptr.ProfileAccess = 0x2aaad3c5d5d0 <vtable for connectivity::mork::ProfileAccess+16>, m_ProductProfileList = {{mCurrentProfileName = "", 
      mProfileList = std::__debug::map with 0 elements}, {mCurrentProfileName = "", mProfileList = std::__debug::map with 1 elements = {["default"] = {
          product = com::sun::star::mozilla::MozillaProductType_Mozilla, profileName = "default", profilePath = "/home/julien/.icedove/j9lu4huc.default"}}}, {
      mCurrentProfileName = "", mProfileList = std::__debug::map with 0 elements}, {mCurrentProfileName = "", mProfileList = std::__debug::map with 1 elements = {
        ["default"] = {product = com::sun::star::mozilla::MozillaProductType_Thunderbird, profileName = "default", 
          profilePath = "/home/julien/.mozilla/firefox/pp8pi6dk.default"}}}}}
Comment 9 Lionel Elie Mamane 2015-04-05 08:23:56 UTC
Ah, I understood. Yes, please revert http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b92d8afbabe564de703f8bc083723d97e765011

The order in the arrays that you changed are *not* the order in which they are looked, but they *must* correspond (with an offset of 1) to the constants in offapi/com/sun/star/mozilla/MozillaProductType.idl.

It seems to me that the order in which addressbooks are looked is decided by ProfileAccess::LoadProductsInfo in connectivity/source/drivers/mozab/bootstrap/MNSProfileDiscover.cxx

So to fix this bug and bug 39279:

 * revert 9b92d8afbabe564de703f8bc083723d97e765011

 * change the order of calls to LoadXPToolkitProfiles in
Comment 10 Lionel Elie Mamane 2015-04-05 08:24:46 UTC
(In reply to Lionel Elie Mamane from comment #9)
> Ah, I understood. Yes, please revert
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=9b92d8afbabe564de703f8bc083723d97e765011

> The order in the arrays that you changed are *not* the order in which they
> are looked, but they *must* correspond (with an offset of 1) to the
> constants in offapi/com/sun/star/mozilla/MozillaProductType.idl.

Please also add a comment to connectivity/source/drivers/mork/MNSFolders.cxx that explains that.
Comment 11 Julien Nabet 2015-04-05 13:29:05 UTC
Fixed on master, I'll cherry-pick the patch on 4.4 branch.
Comment 12 Commit Notification 2015-04-07 12:38:28 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":


tdf#90446 Revert "tdf#39279: Prioritise Thunderbird address books..."

It will be available in 4.4.3.

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:
Affected users are encouraged to test the fix and report feedback.
Comment 13 Julien Nabet 2015-04-09 08:23:26 UTC
Should be fixed now.