Created attachment 178121 [details] screenshot of the issue SUMMARY STEPS TO REPRODUCE 1. Depends on the merge conflict 2. 3. OBSERVED RESULT Sometimes when I rebase/merge a branch some files with merge conflicts open in the mergetool (kdiff3) with visual glitches (in the attached screenshot you can see the black from the Console behind, like if it was transparent). Also the buttons in the menu on the top appear to be grayed out and cannot be clicked. When trying to resolve merge conflicts on other files it works flawlessly. I can reproduce the issue whenever I try to solve the same conflict. EXPECTED RESULT It shouldn't glitch. SOFTWARE/OS VERSIONS I use Gnome on Arch Linux ADDITIONAL INFORMATION I tried to recompile the kdiff package, same issue. I tried to recompile an older version of kdiff3 (1.11.5) and it works flawlessly.
Able to reproduce with KDE Plasma 6.3.1
When resolving merge conflicts using kdiff3 version 1.12.3, I have observed similar results to those shown at https://bugs.kde.org/attachment.cgi?id=178121. I use kdiff3 as the Git merge tool. When the bug occurs, the kdiff3 starts up but the text views are missing. Restarting kdiff3 on such a merge reliably produces this result each time and I have to resolve the file manually when this happens.
I have just hit upon this issue in kdiff3 1.12.2 in Kubuntu 25.04 (Plasma 6.3.4, Frameworks 6.12.0, Qt 6.8.3, Gear 24.12.3) with Wayland. Logging out and logging back in from KDE(X11), however, this issue doesn't come up on the same merge conflict. Since git mergetool creates _LOCAL, _REMOTE, _BASE files and then runs `kdiff3 $LOCAL $REMOTE $BASE -o $MERGED`, would be nice to attach files for which this reproduces to this ticket. Unfortunately, I cannot do this myself because the code I'm working on is non-FOSS.
Created attachment 183456 [details] video of issue I attached a video of the issue. I have created three local files for the diff that I open in kdiff3 inbetween calling git mergetool, but it seems the bug only happens when calling kdiff3 from git. Also it seems that depending on the size of the window it will glitch out or not. I cannot tell if there is a pattern or if it is just random. Maybe the issue is that the popup is blocked?
It seems I have hit the same issue with 1.12.3 version in Fedora 41. I were able to track that at least on my system, it happens only when --auto mode is used. When I added --noauto, it renders okay. Unfortunately there does not seem to be simple way to add --noauto into git mergetool. My Fedora bug with my screenshots: https://bugzilla.redhat.com/show_bug.cgi?id=2386547 Strange is it happens on my computer only when I did maximize the window in previous run. If I made the window smaller, it renders okay next time. If I maximize the window again and close, then next time it is broken. It may need a bit more text with scrollbar. It did not appear with short text, but visible on conflict file not tiny. It worked reliably on 412 lines long glibc license file. My primary screen is 2560x1440 pixels Lenovo, if that matters. My Steps to Reproduce: 1. cp /usr/share/licenses/glibc/LICENSES L 2. cp L L2 3. cp L L3 4. echo "# make diff" >> L3 5. /usr/bin/kdiff3 --auto -o L L2 L3 6. if it renders, maximize window and restart with the same parameters.
*** Bug 507065 has been marked as a duplicate of this bug. ***
good thing is this can be avoided by using --noauto parameter. But I have not found simple way to add it from git. It might be possible to avoid it by shell wrapper: ``` #!/bin/sh [ "$1" = "--auto" ] && shift exec /usr/bin/kdiff3 "$@" ``` Not sure why, --noauto always rendered correctly to me. Avoiding --auto might require me to save it and close unnecessary, but at least I see the text on conflicts.
*** Bug 506355 has been marked as a duplicate of this bug. ***
This issue were not happening on version before 1.12.0. I think 1.11.5 had other issues, but at least always rendered the text.
Note: Bug 507065 contains also commit references to the cause of this issue. https://bugs.kde.org/show_bug.cgi?id=507065#c1
Ah, there exists even simpler workaround. Just enable Word Wrap Diff Windows in Diffview menu. (3rd from bottom). Bruno has identified correctly commit https://github.com/KDE/kdiff3/commit/1ae607daa4c2153bbf88295fae153aa08f3bd5b#r163513079 is responsible for this change. It seems it negated word wrapping condition by mistake. Toggling it to avoid using getVisibleTextAreaWidth() call seems to fix the rendering also. At least to me.
It started to happen much more often for me with recent updates. Having "Word Wrap" flag set does not help the issue either. Can something be done about this bug, please?
Have you tried the latest git version? This commit https://invent.kde.org/sdk/kdiff3/-/commit/b6e97aeb2541f770fe114467259df44e46413862 should fix the bug.
I have kdiff3 1.12.3 that still reproduces this issue. It seems the referenced commit is from 4 months ago. Do you know whether 1.12.3 should already contain it?
No released version contains the fix. See https://invent.kde.org/sdk/kdiff3/-/commits/1.12?ref_type=heads
(In reply to jonaskarlsson from comment #13) > Have you tried the latest git version? This commit > https://invent.kde.org/sdk/kdiff3/-/commit/ > b6e97aeb2541f770fe114467259df44e46413862 should fix the bug. I have tried it just now - kdiff3 built with commit 6045e1cd4fa484a77e35c5eb8f25f8a5a6aa838c, which includes b6e97aeb2541f770fe114467259df44e46413862 in history. Issue still reproduces. I have also found a cmdline and file examples that reproduce this issue - files will be attached as kdiff3-499772-repro.tar.gz, cmdline is as follows: kdiff3 --auto --L1 "vsftpd.init (Base)" --L2 "vsftpd.init (Local)" --L3 "vsftpd.init (Remote)" -o vsftpd.init ./vsftpd_BASE_78355.init ./vsftpd_LOCAL_78355.init ./vsftpd_REMOTE_78355.init
Created attachment 186948 [details] Files that reproduce the issue