Bug 1931423

Summary:	Updating gtk3 breaks formula editing in LibreOffice
Product:	[Fedora] Fedora	Reporter:	Lubomir Bulej <pallas>
Component:	libreoffice	Assignee:	Caolan McNamara <caolanm>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	33	CC:	caolanm, cosimo.cecchi, dtardon, erack, gnome-sig, mclasen, sbergman
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	libreoffice-7.0.6.2-1.fc33	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-05-25 14:46:15 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Lubomir Bulej 2021-02-22 11:52:43 UTC

Description of problem:


When editing formulas with placeholders (<?>) in LibreOffice (Writer, Impress), the formula is not updated after replacing the placeholder with a value, not even after leaving the formula editor. It requires activating and just leaving the formula editor again (double-clicking on the formula object and pressing ESC without editing) to trigger repaint.

The problem appears after updating gtk3 to version 3.24.25-2.fc33 and disappears when gtk3 is downgraded to version 3.24.23-1.fc33.


Version-Release number of selected component (if applicable):

3.24.25-2.fc33


How reproducible:

Always

Steps to Reproduce:
1. Launch LibreOffice Writer to create a new empty document
2. Insert->Object->Formula
3. enter <?> in the text-based formula editor
4. press ESC to leave the formula editor (should render a formula with a single box)
5. double-click on the formula object to activate formula editor
6. click on the box in the formula (pre-selects the <?> characters)
7. enter 1 replacing the (pre-selected) <?> characters (formula is not retained)
8. press ESC to leave the formula editor (formula is not repainted)
9. double-click on the formula object to activate formula editor again
10. press ESC to leave the formula editor (the formula is repainted now)


Actual results:

The formula is not repainted either after replacing <?> with 1, or (at the latest) after leaving the formula editor.

Expected results:

The formula is repainted after replacing <?> with 1.

Additional info:

The expected results were the actual results prior to upgrading gtk3 to version 3.24.25-2.fc33. The current situation complicates use of LibreOffice during distance teaching math, which relied on presentations with pre-defined formulas containing placeholders.

Comment 1 Matthias Clasen 2021-02-24 12:54:01 UTC

Anything special in the way libreoffice interact with input methods?

Comment 2 Caolan McNamara 2021-02-24 14:13:43 UTC

looks to me starmath has a reparse+repaint timer which is started on keypress events, but doesn't trigger for input engine ones

Comment 3 Matthias Clasen 2021-02-24 14:23:42 UTC

For context, I've done some changes in GtkIMContextSimple. My initial suspicion here was that I maybe inadvertently changed the event stream you see by filtering out different press or release events, but so far, I haven't seen anything obvious.

Comment 4 Matthias Clasen 2021-02-24 14:25:11 UTC

Do you see anything that has changed in those events to cause this to break from gtk 3.24.23 to 3.24.24 ?

Comment 5 Caolan McNamara 2021-02-24 15:12:49 UTC

Looks like we deliver single key strokes received through IM as keyevents for some legacy reason, but we don't do this if we got a preedit-end signal. In gtk 3.24.23 we don't get one of those so we deliver the IM single letter as a keyevent (and math starts its timer) in 3.24.5 we get a preedit-end and deliver as a IM command instead and math doesn't start its timer in that case. Its hard to argue that math shouldn't reparse its input if it was modified via IM so https://gerrit.libreoffice.org/c/core/+/111488 to do that and that would make this work.

The change that seems to make a different I guess is 85d34932f3888caecd4b50dcfce530c8b82a7a5b in gtk where gtk_im_context_simple_commit_char in the past emitted preedit-end only conditionally and now calls gtk_im_context_simple_commit_string which always emits preedit-end

Comment 6 Matthias Clasen 2021-02-24 15:31:49 UTC

aha. thanks for the detective work! et me see if I can make sure that we only emit preedit-end if there actually was preedit

Comment 7 Matthias Clasen 2021-02-24 19:20:53 UTC

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/323 should fix this.

Comment 8 Caolan McNamara 2021-05-25 14:46:15 UTC

Works in F33 with libreoffice-7.0.6.2 in any case