Bug 1291074
| Summary: | Repainting problems with text inside boxes (e.g. the text box for the search field) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David H. Gutteridge <dhgutteridge> | ||||||||
| Component: | libreoffice | Assignee: | Caolan McNamara <caolanm> | ||||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 23 | CC: | altarasyuk, caolanm, dhgutteridge, dtardon, erack, fabrice.salvaire, greartes, ltinkl, mstahl, sbergman | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | libreoffice-5.1.4.2-3 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2016-06-30 16:25:33 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: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 1105309 [details]
Sample of garbled text, exhibit B
Created attachment 1105310 [details]
Sample of garbled text, exhibit C
The problem appears to be due to negative interactions of some kind between LibreOffice and the breeze-gtk package that was added to KDE Plasma in the latest updates pushed to testing. (See https://bodhi.fedoraproject.org/updates/FEDORA-2015-0f88189b65.) I was testing those KDE updates, including breeze-gtk-5.5.0.1-1.fc23. Under KDE it has no negative impact to me (probably since I have libreoffice-kde installed), but under Gnome it quite visibly changes many of the basic LibreOffice menu elements to be more KDE-like, and as another side-effect, it screws up rendering in text boxes. I confirmed this by un-installing and re-installing breeze-gtk. So I'm not sure whose bug this would be: LibreOffice is exhibiting problems that no other GTK2/3 application I have installed has shown any sign of, but KDE packages shouldn't be influencing the basic look and feel of any GTK2/3 client sessions in Gnome, and certainly shouldn't be causing rendering issues. I should add, I use LibreOffice with the default Tango theme settings, not Breeze. So I don't follow why it would be picking up anything from Breeze when running under Gnome. I un-installed libreoffice-kde to check whether it was influencing anything under Gnome (I wouldn't expect it would be), and it wasn't. Without libreoffice-kde and with breeze-gtk installed, things still get garbled. Still an issue with breeze-gtk-5.5.1-1.fc23.x86_64 in updates-testing. I logged into gnome-classic, dnf install breeze-gtk, used gnome-tweak-tool to select that theme. Launched LibreOffice (looked quite pretty). And wasn't able to reproduce any problem. breeze-gtk is now at version 5.5.3-1 however so maybe that makes a difference ? *** Bug 1300230 has been marked as a duplicate of this bug. *** *** Bug 1294221 has been marked as a duplicate of this bug. *** I can reproduce this with breeze-gtk 5.5.3-1 just the same. I'm not using gnome-tweak-tool to select that theme, everything is left with the default Adwaita theme. It's just that in LibreOffice (and nothing else), the Breeze theme decides to somehow partly muscle its way in anyway, and that triggers the text box issue for me. It is a top level bug for such package. I had to install manually libreoffice-kde to fix it. I can confirm that installed 'libreoffice-kde' package solved the issue. The libreoffice-kde package does not solve the issue, if one's desktop environment is Gnome rather than KDE. (Which is my context.) I just retested with breeze-gtk-5.5.4 and there's no change here, it's still broken. I cannot reproduce this issue under Fedora 24 with the libreoffice-5.1.4.2-3 and breeze-gtk-5.6.5-2 packages, either with the GTK3 or GTK2 VCL plug-ins. (My original report was against Fedora 23 with 5.0.x using the GTK2 VCL plug-in.) Separately, my aside about the greyed-out search buttons has been reported upstream as https://bugs.documentfoundation.org/show_bug.cgi?id=89616. The problem seems solved on FC24. After upgrade from FC23 it looks good. ok, fair enough, lets call it fixed in f24 for "unknown reasons". I spoke too soon. The garbled text rendering in boxes appears to be gone, but the underlying issue of breeze-gtk muscling its way into LibreOffice's look is still happening, when using the GTK2 VCL plug-in. (I can't reproduce it with the GTK3 VCL plug-in.) While this isn't a very significant bug from a user's perspective, it's odd that it's interacting with LibreOffice in that way, since it isn't affecting any other applications -- I haven't chosen it as a theme for Gnome. |
Created attachment 1105308 [details] Sample of garbled text, exhibit A Description of problem: Over the last few days, I've started seeing many repainting problems (delays in refreshing content and visible artefacts left over) in various input boxes in LibreOffice. This only occurs in Gnome (I do not have libreoffice-gtk3 installed) and not in KDE (I do have libreoffice-kde installed). I'm not sure exactly when it first appeared, as I've been testing/using it more in KDE of late. As the most consistent example, see the search box. When empty, it shows "find" greyed out. It's supposed to immediately clear itself when it receives input, but now it's rendering the new text over top the old. (See attachment titled "Exhibit A", in which I've typed "Al" into the box.) This becomes more annoying when sometimes the box completely fails to redraw, where I've cleared the input and typed something else in, yet it shows the older text. (See attachment titled "Exhibit B", where it's showing "Alfalfa", to which it says "Search key not found" when it's in the document, because I've really typed something else in there but the box hasn't refreshed.) I've also attached "Exhibit C" which is a variant of A or B where I've tried to clear the input box and type "Alpha" where previously I had "Alfalfa". The words end up superimposed. A separate problem: if I hide the search tool bar and then bring it back, it still shows the previous text I searched for. All good. But the search buttons are greyed-out, so I can't actually search for that term without editing the contents of the input box first, which mitigates the point of offering the previously-used term. Version-Release number of selected component (if applicable): I've seen this with both 5.0.3.2-11 and 5.0.3.2-12 builds. How reproducible: Always. Steps to Reproduce: 1. Open the find function (if it isn't already on the tool bar). 2. Type something into it. Actual results: Garbled rendering of text. Expected results: Input box should clear its pre-existing content when it receives focus and keyboard input.