Download it now!
Bug 137643 - Can't select font, no font dropdown list, if open MSO .doc in GTK3 only (gen and Skia OK)
Summary: Can't select font, no font dropdown list, if open MSO .doc in GTK3 only (gen ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.5.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.1.0 target:7.0.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-10-21 07:26 UTC by flotsky
Modified: 2020-10-30 12:41 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description flotsky 2020-10-21 07:26:40 UTC
Description:
Didnt get any errors, just cant select fonts.
Problem is not reproducible for other file types(docx, odt)

Steps to Reproduce:
1. Create .doc(Word 97-2003) document
2. Close libreoffice
3. Open file again in file manager or like this 'libreoffice /path/to/file.doc'
4. Try to change font

Actual Results:
Font list is empty

Expected Results:
List of fonts like always


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Photo example https://ibb.co/rcN3G2D

The problem repeats on Appimage.
Also repeats on my system with versions
LibreOffice 7.0.1.2 00(Build:2) and LibreOffice 7.0.0.3 00(Build:3)
Comment 1 Timur 2020-10-21 08:33:33 UTC Comment hidden (obsolete)
Comment 2 Timur 2020-10-21 09:04:17 UTC Comment hidden (obsolete)
Comment 3 Xisco Faulí 2020-10-22 13:45:24 UTC
the bisection in comment 2 is incorrect.

Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=98d71c4e0847797a4ba9229a8e6d832a8a3d5e0f

author	Mike Kaganski <mike.kaganski@collabora.com>	2019-01-11 00:06:49 +0300
committer	Mike Kaganski <mike.kaganski@collabora.com>	2019-01-11 05:38:52 +0100
commit	98d71c4e0847797a4ba9229a8e6d832a8a3d5e0f (patch)
tree	97012c315567a679abc827873746afa5fa90bdd0
parent	284a7f60fff72c4d8c011ff60ea2e40163cd25c3 (diff)
tdf#69060: lock refreshing font data when loading a document

Bisected with: bibisect-linux64-6.3

Adding Cc: to Mike Kaganski
Comment 4 Timur 2020-10-22 14:31:19 UTC
OK, I always check bibisect result for ^1, but it may slip somehow after many.
Comment 5 Mike Kaganski 2020-10-22 19:18:42 UTC
Can't repro with Version: 7.0.2.2
Build ID: 00(Build:2)
CPU threads: 1; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

on OpenSUSE Thumbleweed.
Comment 6 Timur 2020-10-23 06:44:00 UTC
I reproduce with 7.1+ in Linux: open DOC and see that font list is empty.

Version: 7.1.0.0.alpha0+
Build ID: f1d798151048dde3f48b124ef406416668d1e9c5
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 - Ubuntu 18.04, Mint.

Not with all DOC, I guess not with LO-saved, but with MSO DOC like attachment 166616 [details].
Comment 7 Mike Kaganski 2020-10-23 07:07:28 UTC
Yes I also repro with attachment 166616 [details]:

> soffice '/home/mike/Downloads/astutussopimus_20.doc' 

(soffice:30704): Gtk-CRITICAL **: 08:03:14.062: gtk_tree_view_scroll_to_cell: assertion 'tree_view->priv->tree != NULL' failed

But I don't repro using gen:

> SAL_USE_VCLPLUGIN=gen soffice '/home/mike/Downloads/astutussopimus_20.doc'

Caolan: do you have an idea?
Comment 8 Caolán McNamara 2020-10-23 08:17:51 UTC
I see this with
soffice ~/Downloads/astutussopimus_20.doc
but not with
soffice.bin ~/Downloads/astutussopimus_20.doc
which is a little odd
oosplash /home/caolan/Downloads/astutussopimus_20.doc
also fails
Comment 9 Caolán McNamara 2020-10-23 09:19:35 UTC
What I see is the font list is created, later LockFontUpdates(true) is called, but during the load a "FontChanged" is received (which is typical when a gtk window get focus) and PhysicalFontCollection::Clear is called so there are no fonts when the font combobobox is created, and then later LockFontUpdates(false) is called.

for the gen case there is no "FontChanged" so the initial pre-LockFontUpdates(true) call fonts are available for the font combobox to populate from
Comment 10 Caolán McNamara 2020-10-23 09:56:40 UTC
https://gerrit.libreoffice.org/c/core/+/104716 would seem to work to make this functional again
Comment 11 Caolán McNamara 2020-10-23 10:18:29 UTC
Probably worth pasting in here where the FontCollection is cleared. Its in handling the SalEvent::FontChanged event during Application::Reschedule to process some pending events, while setting the progress bar value, to get some redraws of the UI done to show the progress while loading

#0  PhysicalFontCollection::Clear() (this=0x4e88030) at vcl/source/font/PhysicalFontCollection.cxx:95
#1  0x00007fffef465708 in OutputDevice::ImplClearFontData(bool) (this=0x4e2b090, bNewFontLists=true) at vcl/source/outdev/font.cxx:528
#2  0x00007fffef465bad in OutputDevice::ImplUpdateFontDataForAllFrames(void (OutputDevice::*)(bool), bool)
    (pHdl=&virtual table offset 280, bNewFontLists=true) at vcl/source/outdev/font.cxx:617
#3  0x00007fffef46585f in OutputDevice::ImplClearAllFontData(bool) (bNewFontLists=true) at vcl/source/outdev/font.cxx:553
#4  0x00007fffef465cbd in OutputDevice::ImplUpdateAllFontData(bool) (bNewFontLists=true) at vcl/source/outdev/font.cxx:589
#5  0x00007fffef240e9a in ImplHandleSalSettings(SalEvent) (nEvent=SalEvent::FontChanged) at vcl/source/window/winproc.cxx:2181
#6  0x00007fffef23db10 in ImplWindowFrameProc(vcl::Window*, SalEvent, void const*) (_pWindow=0x1ba2070, nEvent=SalEvent::FontChanged, pEvent=0x0)
    at vcl/source/window/winproc.cxx:2539
#7  0x00007fffefcfd095 in SalFrame::CallCallback(SalEvent, void const*) const (this=0x1b25a00, nEvent=SalEvent::FontChanged, pEvent=0x0)
    at vcl/inc/salframe.hxx:302
#8  0x00007fffefd2af6f in SalGenericDisplay::ProcessEvent(SalUserEventList::SalUserEvent) (this=0x1539400, aEvent=...) at vcl/unx/generic/app/gendisp.cxx:66
#9  0x00007fffef9a36f9 in SalUserEventList::DispatchUserEvents(bool) (this=0x1539400, bHandleAllCurrentEvents=false)
    at vcl/source/app/salusereventlist.cxx:117
#10 0x00007fffefd2aeb9 in SalGenericDisplay::DispatchInternalEvent(bool) (this=0x1539400, bHandleAllCurrentEvent=false) at vcl/unx/generic/app/gendisp.cxx:51
#11 0x00007fffd9e1ad01 in call_userEventFn(void*) (data=0x5086f0) at vcl/unx/gtk3/gtk3gtkdata.cxx:725
#12 0x00007fffe92e045b in g_idle_dispatch () at /lib64/libglib-2.0.so.0
#13 0x00007fffe92e478f in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
#14 0x00007fffe92e4b18 in g_main_context_iterate.constprop () at /lib64/libglib-2.0.so.0
#15 0x00007fffe92e4be3 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#16 0x00007fffd9e198ac in GtkSalData::Yield(bool, bool) (this=0x5086f0, bWait=false, bHandleAllCurrentEvents=true) at vcl/unx/gtk3/gtk3gtkdata.cxx:382
#17 0x00007fffd9e1ee62 in GtkInstance::DoYield(bool, bool) (this=0x512460, bWait=false, bHandleAllCurrentEvents=true) at vcl/unx/gtk3/gtk3gtkinst.cxx:387
#18 0x00007fffefa84d30 in ImplYield(bool, bool) (i_bWait=false, i_bAllEvents=true) at vcl/source/app/svapp.cxx:446
#19 0x00007fffefa849d2 in Application::Reschedule(bool) (i_bAllEvents=true) at vcl/source/app/svapp.cxx:459
#20 0x00007ffff563dc17 in framework::StatusIndicatorFactory::impl_reschedule(bool) (this=0x224fb90, bForce=true)
    at framework/source/helper/statusindicatorfactory.cxx:521
#21 0x00007ffff563cf18 in framework::StatusIndicatorFactory::start(com::sun::star::uno::Reference<com::sun::star::task::XStatusIndicator> const&, rtl::OUString const&, int) (this=0x224fb90, xChild=uno::Reference to (framework::StatusIndicator *) 0x221c798, sText="Importing document...", nRange=100)
    at framework/source/helper/statusindicatorfactory.cxx:139
#22 0x00007ffff563a7af in framework::StatusIndicator::start(rtl::OUString const&, int) (this=0x221c770, sText="Importing document...", nRange=100)
    at framework/source/helper/statusindicator.cxx:51
#23 0x00007ffff44a5728 in SfxProgress::SetState(unsigned int, unsigned int) (this=0x51a2400, nNewVal=0, nNewRange=0) at sfx2/source/bastyp/progress.cxx:230
#24 0x00007fffb57bb4a9 in SetProgressState(long, SwDocShell const*) (nPosition=0, pDocShell=0x4dbdf10) at sw/source/uibase/app/mainwn.cxx:88
#25 0x00007fffb1f4d3a2 in ImportProgress::Update(unsigned short) (this=0x51a23e0, nProgress=0) at sw/source/filter/inc/fltshell.hxx:324
#26 0x00007fffb1f3accf in SwWW8ImplReader::CoreLoad(WW8Glossary const*) (this=0x5192880, pGloss=0x0) at sw/source/filter/ww8/ww8par.cxx:5116
#27 0x00007fffb1f3fcb2 in SwWW8ImplReader::LoadThroughDecryption(WW8Glossary*) (this=0x5192880, pGloss=0x0) at sw/source/filter/ww8/ww8par.cxx:5939
#28 0x00007fffb1f41a32 in SwWW8ImplReader::LoadDoc(WW8Glossary*) (this=0x5192880, pGloss=0x0) at sw/source/filter/ww8/ww8par.cxx:6243
#29 0x00007fffb1f43e48 in WW8Reader::Read(SwDoc&, rtl::OUString const&, SwPaM&, rtl::OUString const&)
    (this=0x517e9c0, rDoc=..., rBaseURL="file:///home/caolan/Downloads/astutussopimus_20.doc", rPaM=SwPaM = {...}) at sw/source/filter/ww8/ww8par.cxx:6489
#30 0x00007fffb54fe258 in SwReader::Read(Reader const&) (this=0x4dc1260, rOptions=...) at sw/source/filter/basflt/shellio.cxx:191
#31 0x00007fffb5761875 in SwDocShell::ConvertFrom(SfxMedium&) (this=0x4dbdf10, rMedium=...) at sw/source/uibase/app/docsh.cxx:231
#32 0x00007ffff4878f02 in SfxObjectShell::DoLoad(SfxMedium*) (this=0x4dbdf10, pMed=0x13fc2b0) at sfx2/source/doc/objstor.cxx:753
Comment 12 Mike Kaganski 2020-10-23 10:26:35 UTC
(In reply to Caolán McNamara from comment #11)
> ...
> #3  0x00007fffef46585f in OutputDevice::ImplClearAllFontData(bool)
> (bNewFontLists=true) at vcl/source/outdev/font.cxx:553
> #4  0x00007fffef465cbd in OutputDevice::ImplUpdateAllFontData(bool)
> (bNewFontLists=true) at vcl/source/outdev/font.cxx:589
> ...

As this is called between LockFontUpdates(true) and LockFontUpdates(false), this must mean that the next call in the OutputDevice::ImplUpdateAllFontData - which is OutputDevice::ImplRefreshAllFontData - will just set svdata->mbFontUpdatesPending and svdata->mbFontUpdatesNewLists to true, and later, in the LockFontUpdates(false), it must call ImplRefreshAllFontData(true)...

at least that was the hope.
Comment 13 Caolán McNamara 2020-10-23 11:23:47 UTC
The fontcombobox gets its list of fonts with lcl_GetDocFontList which gets SID_ATTR_CHAR_FONTLIST and I'll also put in where that SID_ATTR_CHAR_FONTLIST is set on load. This also happen while the guard is held.

#0  SwDocShell::UpdateFontList() (this=0x6aace40) at sw/source/uibase/app/docshini.cxx:414
#1  0x00007fffb513232d in SwDocShell::SubInitNew() (this=0x6aace40) at sw/source/uibase/app/docshini.cxx:621
#2  0x00007fffb51309af in SwDocShell::InitNew(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&)
    (this=0x6aace40, xStor=empty uno::Reference) at sw/source/uibase/app/docshini.cxx:125
#3  0x00007ffff4878770 in SfxObjectShell::DoLoad(SfxMedium*) (this=0x6aace40, pMed=0x7014bf0) at sfx2/source/doc/objstor.cxx:696
#4  0x00007ffff48e116e in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&)
Comment 14 Caolán McNamara 2020-10-23 11:32:03 UTC
https://lists.freedesktop.org/archives/libreoffice/2012-September/038163.html might be somewhat relevant here

I see that as an alternative fix, sw/source/uibase/uiview/view.cxx SwView::SwView if the rDocSh.UpdateFontList is make unconditional then that also makes this work without the other modification
Comment 15 Commit Notification 2020-10-28 19:41:36 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f34c304638258eb1d30a7fab942313199c65cc3f

tdf#137643 Revert "lock refreshing font data when loading a document"

It will be available in 7.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 16 Caolán McNamara 2020-10-28 19:45:31 UTC
fixed in master, backport to 7-0 in gerrit. Follow up patches to keep the optimization but in a different way also in gerrit.
Comment 17 Commit Notification 2020-10-29 09:15:17 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/388735924392027eb6a8e722083e6496b92a40fa

tdf#137643 alternative solution to activate embedded fonts in one batch

It will be available in 7.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 18 Commit Notification 2020-10-29 10:52:09 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/1bf0997d459909d0d72b168b342939237ed92a99

tdf#137643 Revert "lock refreshing font data when loading a document"

It will be available in 7.0.4.

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

Affected users are encouraged to test the fix and report feedback.
Comment 19 Xisco Faulí 2020-10-30 10:48:15 UTC
Verified in

Version: 7.1.0.0.alpha1+
Build ID: ec1f4d3253963ac16d638734ac70dde033e82154
CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

@Caolán, thanks for fixing this issue!!
Comment 20 Commit Notification 2020-10-30 12:41:16 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/1e9f63fd0d6e8c4e5c92c1379a3792bc09ade97a

tdf#137643 alternative solution to activate embedded fonts in one batch

It will be available in 7.0.4.

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

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