Bug 1931423 - Updating gtk3 breaks formula editing in LibreOffice
Summary: Updating gtk3 breaks formula editing in LibreOffice
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: libreoffice
Version: 33
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-22 11:52 UTC by Lubomir Bulej
Modified: 2021-02-24 19:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.