Bug 1931423

Summary: Updating gtk3 breaks formula editing in LibreOffice
Product: [Fedora] Fedora Reporter: Lubomir Bulej <pallas>
Component: libreofficeAssignee: Caolan McNamara <caolanm>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 33CC: 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:

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