Connected with Base to Thunderbird-addressbook. Works well with LO 4.4.1.2, fails with LO 4.4.2.2. This message appears: "The file $filename$ could not be loaded". (Don't know it's the right text - translated it from German)
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.
Following comment1 from Doug I set this bug to NEW.
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
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: offapi/com/sun/star/mozilla/MozillaProductType.idl and there: offapi/type_reference/offapi.idl For the moment it doesn't work :-(
Lionel: put you in cc because except revert the patch for tdf#39279, I'm a bit stuck. Any thought?
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. :)
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) (gdb) 125 OUString defaultProfile = m_pProfileAccess->getDefaultProfile(::com::sun::star::mozilla::MozillaProductType_Thunderbird); (gdb) 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" (gdb)
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"}}}}}
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 ProfileAccess::LoadProductsInfo
(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.
Fixed on master, I'll cherry-pick the patch on 4.4 branch.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6b275af6e00fd5b1ff96eb271ad09f7bf75e9865&h=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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Should be fixed now.