[plasmashell] [Bug 371943] New: Top search results can often be unexpected for users
https://bugs.kde.org/show_bug.cgi?id=371943 Bug ID: 371943 Summary: Top search results can often be unexpected for users Product: plasmashell Version: 5.8.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: k...@davidedmundson.co.uk Reporter: k...@kdex.de CC: plasma-b...@kde.org Target Milestone: 1.0 When typing "fire" into the search box, one might expect "Firefox" to appear as the top result. Instead, the search can yield unexpected top results (e.g. "Tor Browser"), because on some distributions, Tor comes with a desktop file that includes the following line: Comment=Tor Browser Bundle: Anonymous browsing using firefox and tor It might be a good idea to prefer matches within a desktop file's `Name` field over matches within the `Comment` field. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 424672] Add option to disable antialiasing/blur in zoom/magnify effect
https://bugs.kde.org/show_bug.cgi?id=424672 kdex changed: What|Removed |Added CC||k...@kdex.de -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 416615] New: krunner randomly crashes on Alt + F2
https://bugs.kde.org/show_bug.cgi?id=416615 Bug ID: 416615 Summary: krunner randomly crashes on Alt + F2 Product: krunner Version: 5.17.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@privat.broulik.de Reporter: k...@kdex.de Target Milestone: --- Application: krunner (5.17.5) Qt Version: 5.14.0 Frameworks Version: 5.66.0 Operating System: Linux 5.4.11-arch1-1 x86_64 Distribution: "Arch Linux" -- Information about the crash: - What I was doing when the application crashed: I had my monitors off and my KDE session locked. The computer was *not* suspended or hibernating. I turned on my monitors, logged in and hit Alt + F2 to start krunner. It immediately crashed without showing a GUI. The crash can be reproduced sometimes. -- Backtrace (Reduced): #6 0x7f5444cd2bbc in QXcbIntegration::createPlatformOpenGLContext(QOpenGLContext*) const () at /usr/lib/libQt5XcbQpa.so.5 #7 0x7f544a30c11e in QOpenGLContext::create() () at /usr/lib/libQt5Gui.so.5 #8 0x7f544b8210ec in () at /usr/lib/libQt5Quick.so.5 #9 0x7f544b822fc4 in () at /usr/lib/libQt5Quick.so.5 #10 0x7f544b8273d7 in () at /usr/lib/libQt5Quick.so.5 Possible duplicates by query: bug 416549, bug 416379, bug 416228, bug 416113, bug 416024. Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[kaddressbook] [Bug 415220] New: Custom field deletion silently fails if the field hasn't been created with KAddressbook
https://bugs.kde.org/show_bug.cgi?id=415220
Bug ID: 415220
Summary: Custom field deletion silently fails if the field
hasn't been created with KAddressbook
Product: kaddressbook
Version: 5.13.0
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kdepim-b...@kde.org
Reporter: k...@kdex.de
CC: to...@kde.org
Target Milestone: ---
SUMMARY
KAddressbook differentiates between two types of custom fields:
(1) Custom fields created by KAddressbook. These get prefixed with
"X-KADDRESSBOOK-${UUID}" internally.
(2) Any other custom fields, only prefixed with "X-". These are usually created
by third-party software and get imported into KAddressbook.
When trying to delete a custom field of type (2), the UI behaves just as if it
would delete the field, but the HTTP PUT request will still contain said field,
so a CardDav server will *not* attempt to delete it. Hence, when viewing the
vCard again, the field will still be there.
STEPS TO REPRODUCE
1. Export any vCard with KAddressbook.
2. In the exported file, manually insert a custom `X-FAVORITE-COLOR` field and
set it to "Blue".
3. Import your vCard and attempt to delete the `X-FAVORITE-COLOR` field by
editing the contact.
4. When you delete the field and you press "Apply/OK", open the edit window
again and view the list of custom fields.
OBSERVED RESULT
The `X-FAVORITE-COLOR` field is still there.
EXPECTED RESULT
The `X-FAVORITE-COLOR` field should have been deleted.
SOFTWARE/OS VERSIONS
Linux, KDE Plasma:
KDE Plasma Version: 5.17.4
KDE Frameworks Version: 5.64.0
Qt Version: 5.14.0
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 393231] New: Thousands separator for locale de_DE is wrong
https://bugs.kde.org/show_bug.cgi?id=393231 Bug ID: 393231 Summary: Thousands separator for locale de_DE is wrong Product: systemsettings Version: unspecified Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm_formats Assignee: se...@kde.org Reporter: k...@kdex.de Target Milestone: --- The locale `de_DE` erroneously uses '.' as its thousands (group) separator, which was only used historically. As per DIN 1333, DIN 5008, and EN ISO 8, the separator is a thin space. DIN 1333 explicitly forbids the usage of '.' to group thousands, and EN ISO 8 explicitly excludes all other characters than a thin space. For further information, please also refer to the relevant section on Wikipedia at [1] (German). [1] https://de.wikipedia.org/wiki/Zifferngruppierung#Zur_Problematik_von_Punkt_und_Komma_f%C3%BCr_Tausender-_und_Dezimaltrennzeichen -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 393519] New: Add support for mail delivery confirmations
https://bugs.kde.org/show_bug.cgi?id=393519 Bug ID: 393519 Summary: Add support for mail delivery confirmations Product: kmail2 Version: Git (master) Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: composer Assignee: kdepim-b...@kde.org Reporter: k...@kdex.de Target Milestone: --- In case the title is unclear, note that there is a significant difference between "read confirmation" and "delivery confirmation". As it stands, kmail only supports the former. You can activate it on a per-message basis by enabling [Composer] -> [Options] -> [Request Disposition Notification]. You can also enable it holistically in the settings. This issue requests the addition of the latter. This would imply that the following is implemented: - [Composer] -> [Options] -> [Request Delivery Confirmation] - [Kmail] -> [Settings] -> [Composer] -> [Automatically request message delivery notifications] This has also been discussed to some degree over at #88988 for kmail 1, but has never been resolved due to formal faults (it appears). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 388307] New: Scaling an image breaks symmetry axes for multibrush tool
https://bugs.kde.org/show_bug.cgi?id=388307 Bug ID: 388307 Summary: Scaling an image breaks symmetry axes for multibrush tool Product: krita Version: 3.3.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tools Assignee: krita-bugs-n...@kde.org Reporter: k...@kdex.de Target Milestone: --- 1) Press `Q` to select the multibrush tool in an image. 2) Not sure if this setup is really necessary, but I set the tool up as follows in the "Tool Options" tab: [Basic Smoothing] [ ] Assistant [x] Snap single [x] Show Axes Axes Angle: 0.0° [Mirror] [x] Horizontally [ ] Vertically Make sure to verify that it works as expected by drawing: i.e., if you draw something on (x, y), the same value should appear on (-x, y) if you imagine the horizontal center lies at x = 0. 3) Now, scale the image up. In my case, I resized an image from 64×32 px to 1024×512 px, hence keeping its proportions. 4) Try to use the multibrush tool again. If you show the axes (in the tool settings), you will see that they still apply to the old image of dimensions 64×32 px. Essentially, this breaks the multibrush tool and requires the user to save, close and re-open the image for the axis to be recalculated. I would have expected these axes to be recomputed whenever the image size changes. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 388307] JJ: Scaling an image breaks symmetry axes for multibrush tool
https://bugs.kde.org/show_bug.cgi?id=388307 --- Comment #4 from kdex --- (In reply to simeirxh from comment #3) > (In reply to kdex from comment #0) > > 1) Press `Q` to select the multibrush tool in an image. > > 2) Not sure if this setup is really necessary, but I set the tool up as > > follows in the "Tool Options" tab: > > > > [Basic Smoothing] > > [ ] Assistant > > [x] Snap single > > [x] Show Axes > > Axes Angle: 0.0° > > [Mirror] > > [x] Horizontally [ ] Vertically > > > > Make sure to verify that it works as expected by drawing: i.e., if you draw > > something on (x, y), the same value should appear on (-x, y) if you imagine > > the horizontal center lies at x = 0. > > > > 3) Now, scale the image up. In my case, I resized an image from 64×32 px to > > 1024×512 px, hence keeping its proportions. > > > > 4) Try to use the multibrush tool again. If you show the axes (in the tool > > settings), you will see that they still apply to the old image of dimensions > > 64×32 px. Essentially, this breaks the multibrush tool and requires the user > > to save, close and re-open the image for the axis to be recalculated. > > > > I would have expected these axes to be recomputed whenever the image size > > changes. > > Hi, > > I looked into this issue. You can actually reset the axes by clicking the > "Reset" button under the "Show Origin" checkbox in the tools options docker. > I would say how it works now is better than automatically change the > positions of the axis immediately after changing the size of the canvas, as > sometimes artists might want to have the axis remain where it is. Maybe we > should add this to the wiki? I don't have that button/checkbox in my docker (krita 3.3.3). Anyway, I can't see the usefulness of omitting the axis reset after the resize. What useful properties would this yield? Depending on how you resize the image, it's likely that the new axes don't even touch the image anymore. IMHO this would lead to questionable UX and to artists getting confused, including myself before I figured out why the multibrush tool had stopped working (which in turn is why this ticket exists in the first place). ;) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 387349] New: Application Launcher causes plasma to crash when menu button is clicked
https://bugs.kde.org/show_bug.cgi?id=387349 Bug ID: 387349 Summary: Application Launcher causes plasma to crash when menu button is clicked Product: plasmashell Version: 5.11.3 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: k...@kdex.de CC: plasma-b...@kde.org Target Milestone: 1.0 Application: plasmashell (5.11.3) Qt Version: 5.9.3 Frameworks Version: 5.40.0 Operating System: Linux 4.13.12-1-ARCH x86_64 Distribution (Platform): Archlinux Packages -- Information about the crash: - What I was doing when the application crashed: I clicked the Application Launcher's menu button. After a short freeze, plasma crashed. -- Backtrace: Application: Plasma (plasmashell), signal: Aborted Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7fe0e2cb6800 (LWP 5734))] Thread 10 (Thread 0x7fe00a9a3700 (LWP 6135)): #0 0x7fe0d6b40670 in g_mutex_unlock () at /usr/lib/libglib-2.0.so.0 #1 0x7fe0d6b17771 in g_main_context_check () at /usr/lib/libglib-2.0.so.0 #2 0x7fe0d6b18e76 in () at /usr/lib/libglib-2.0.so.0 #3 0x7fe0d6b18fae in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #4 0x7fe0dcb8fcf4 in QElapsedTimer::msecsSinceReference() const () at /usr/lib/libQt5Core.so.5 #5 0x in () Thread 9 (Thread 0x7fe022339700 (LWP 5932)): #0 0x7fe0dc251f7b in poll () at /usr/lib/libc.so.6 #1 0x7fe0d6b18ed3 in () at /usr/lib/libglib-2.0.so.0 #2 0x7fe0d6b18fae in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #3 0x7fe0dcb8fcf4 in QElapsedTimer::msecsSinceReference() const () at /usr/lib/libQt5Core.so.5 #4 0x in () Thread 8 (Thread 0x7fe02bb53700 (LWP 5915)): #0 0x7fe0dbb0f38d in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7fe0b54baddc in () at /usr/lib/xorg/modules/dri/r600_dri.so #2 0x7fe0b54bace8 in () at /usr/lib/xorg/modules/dri/r600_dri.so #3 0x7fe0dbb0908a in start_thread () at /usr/lib/libpthread.so.0 #4 0x7fe0dc25c47f in clone () at /usr/lib/libc.so.6 Thread 7 (Thread 0x7fe02c354700 (LWP 5914)): #0 0x7fe0dbb0f38d in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7fe0b54baddc in () at /usr/lib/xorg/modules/dri/r600_dri.so #2 0x7fe0b54bace8 in () at /usr/lib/xorg/modules/dri/r600_dri.so #3 0x7fe0dbb0908a in start_thread () at /usr/lib/libpthread.so.0 #4 0x7fe0dc25c47f in clone () at /usr/lib/libc.so.6 Thread 6 (Thread 0x7fe0b7deb700 (LWP 5912)): #0 0x7fe0dbb0f38d in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7fe0e2396ef7 in () at /usr/lib/libQt5Script.so.5 #2 0x7fe0e2396f39 in () at /usr/lib/libQt5Script.so.5 #3 0x7fe0dbb0908a in start_thread () at /usr/lib/libpthread.so.0 #4 0x7fe0dc25c47f in clone () at /usr/lib/libc.so.6 Thread 5 (Thread 0x7fe0c1f73700 (LWP 5896)): #0 0x7fff9cf8ab3d in clock_gettime () #1 0x7fe0dc269d26 in clock_gettime () at /usr/lib/libc.so.6 #2 0x7fe0dcb8f5e2 in QTimerInfoList::activateTimers() () at /usr/lib/libQt5Core.so.5 #3 0x in () Thread 4 (Thread 0x7fe0c3fff700 (LWP 5846)): #0 0x7fff9cf8aa88 in clock_gettime () #1 0x7fe0dc269d26 in clock_gettime () at /usr/lib/libc.so.6 #2 0x7fe0dcb8f5e2 in QTimerInfoList::activateTimers() () at /usr/lib/libQt5Core.so.5 #3 0x in () Thread 3 (Thread 0x7fe0ca026700 (LWP 5791)): #0 0x7fe0dc251f7b in poll () at /usr/lib/libc.so.6 #1 0x7fe0d6b18ed3 in () at /usr/lib/libglib-2.0.so.0 #2 0x7fe0d6b18fae in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #3 0x7fe0dcb8fcf4 in QElapsedTimer::msecsSinceReference() const () at /usr/lib/libQt5Core.so.5 #4 0x in () Thread 2 (Thread 0x7fe0cc5cb700 (LWP 5770)): #0 0x7fe0dc251f7b in poll () at /usr/lib/libc.so.6 #1 0x7fe0e12978e0 in () at /usr/lib/libxcb.so.1 #2 0x7fe0e1299679 in xcb_wait_for_event () at /usr/lib/libxcb.so.1 #3 0x7fe0ceb4385a in () at /usr/lib/libQt5XcbQpa.so.5 #4 0x55d5645361f0 in () #5 0x55d564535f40 in () #6 0x7fe0cc5cae40 in () #7 0x7fe0cc5cae08 in () #8 0x7fff9ce0030f in () #9 0x7fe0dc950fcb in () at /usr/lib/libQt5Core.so.5 #10 0x83b5ee7dff32aebe in () #11 0x7fff9ce0030e in () #12 0x7fff9ce0030f in () #13 0x7fe0cc5cb700 in () #14 0x in () Thread 1 (Thread 0x7fe0e2cb6800 (LWP 5734)): [KCrash Handler] #5 0x7fe0dc19a8a0 in raise () at /usr/lib/libc.so.6 #6 0x7fe0dc19bf09 in abort () at /usr/lib/libc.so.6 #7 0x7fe0dc93b858 in () at /usr/lib/libQt5Core.so.5 #8 0x7fe0dcb61f0f in QMetaCallEvent::~QMeta
[kwin] [Bug 387420] New: Kwin crashes when application changer is used
https://bugs.kde.org/show_bug.cgi?id=387420 Bug ID: 387420 Summary: Kwin crashes when application changer is used Product: kwin Version: 5.11.3 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: k...@kdex.de Target Milestone: --- Application: kwin_x11 (5.11.3) Qt Version: 5.9.3 Frameworks Version: 5.40.0 Operating System: Linux 4.13.12-1-ARCH x86_64 Distribution (Platform): Archlinux Packages -- Information about the crash: - What I was doing when the application crashed: 1) Press and + to open the application switcher. 2) Let go of , but keep holding . 3) Press to close the application switcher. 4) Kwin crashes. The crash can be reproduced every time. -- Backtrace: Application: KWin (kwin_x11), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f1e9fa20840 (LWP 18821))] Thread 6 (Thread 0x7f1e61a97700 (LWP 18835)): #0 0x7f1e9834b38d in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1e9b8feef7 in () at /usr/lib/libQt5Script.so.5 #2 0x7f1e9b8fef39 in () at /usr/lib/libQt5Script.so.5 #3 0x7f1e9834508a in start_thread () at /usr/lib/libpthread.so.0 #4 0x7f1e9f3b547f in clone () at /usr/lib/libc.so.6 Thread 5 (Thread 0x7f1e62c9e700 (LWP 18833)): #0 0x7f1e9834b38d in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1e6c739ddc in () at /usr/lib/xorg/modules/dri/r600_dri.so #2 0x7f1e6c739ce8 in () at /usr/lib/xorg/modules/dri/r600_dri.so #3 0x7f1e9834508a in start_thread () at /usr/lib/libpthread.so.0 #4 0x7f1e9f3b547f in clone () at /usr/lib/libc.so.6 Thread 4 (Thread 0x7f1e6349f700 (LWP 18832)): #0 0x7f1e9834b38d in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1e6c739ddc in () at /usr/lib/xorg/modules/dri/r600_dri.so #2 0x7f1e6c739ce8 in () at /usr/lib/xorg/modules/dri/r600_dri.so #3 0x7f1e9834508a in start_thread () at /usr/lib/libpthread.so.0 #4 0x7f1e9f3b547f in clone () at /usr/lib/libc.so.6 Thread 3 (Thread 0x7f1e7cdae700 (LWP 18830)): #0 0x7f1e9f3ab076 in ppoll () at /usr/lib/libc.so.6 #1 0x7f1e9c9e0d23 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5 #2 0x7f1e9c9e24bf in QEventDispatcherUNIX::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #3 0x7f1e9c98899b in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #4 0x7f1e9c7a127e in QThread::exec() () at /usr/lib/libQt5Core.so.5 #5 0x7f1e96e4ccf9 in () at /usr/lib/libQt5Qml.so.5 #6 0x7f1e9c7a61cb in () at /usr/lib/libQt5Core.so.5 #7 0x7f1e9834508a in start_thread () at /usr/lib/libpthread.so.0 #8 0x7f1e9f3b547f in clone () at /usr/lib/libc.so.6 Thread 2 (Thread 0x7f1e7fb59700 (LWP 18827)): #0 0x7f1e9f3ab076 in ppoll () at /usr/lib/libc.so.6 #1 0x7f1e9c9e0d23 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () at /usr/lib/libQt5Core.so.5 #2 0x7f1e9c9e24bf in QEventDispatcherUNIX::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #3 0x7f1e9c98899b in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #4 0x7f1e9c7a127e in QThread::exec() () at /usr/lib/libQt5Core.so.5 #5 0x7f1e95fee376 in () at /usr/lib/libQt5DBus.so.5 #6 0x7f1e9c7a61cb in () at /usr/lib/libQt5Core.so.5 #7 0x7f1e9834508a in start_thread () at /usr/lib/libpthread.so.0 #8 0x7f1e9f3b547f in clone () at /usr/lib/libc.so.6 Thread 1 (Thread 0x7f1e9fa20840 (LWP 18821)): [KCrash Handler] #5 0x7f1e6ca7a664 in () at /usr/lib/xorg/modules/dri/r600_dri.so #6 0x7f1e6c85e61c in () at /usr/lib/xorg/modules/dri/r600_dri.so #7 0x7f1e6c641200 in () at /usr/lib/xorg/modules/dri/r600_dri.so #8 0x7f1e6c604ad8 in () at /usr/lib/xorg/modules/dri/r600_dri.so #9 0x7f1e6c60525f in () at /usr/lib/xorg/modules/dri/r600_dri.so #10 0x7f1e974f87d7 in QSGBatchRenderer::Renderer::renderMergedBatch(QSGBatchRenderer::Batch const*) () at /usr/lib/libQt5Quick.so.5 #11 0x7f1e974f9a76 in QSGBatchRenderer::Renderer::renderBatches() () at /usr/lib/libQt5Quick.so.5 #12 0x7f1e974ff2ee in QSGBatchRenderer::Renderer::render() () at /usr/lib/libQt5Quick.so.5 #13 0x7f1e974ef922 in QSGRenderer::renderScene(QSGBindable const&) () at /usr/lib/libQt5Quick.so.5 #14 0x7f1e974efdec in QSGRenderer::renderScene(unsigned int) () at /usr/lib/libQt5Quick.so.5 #15 0x7f1e9752afc0 in QSGDefaultRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () at /usr/lib/libQt5Quick.so.5 #16 0x7f1e975898a0 in QQuickWindowPrivate::renderSceneGraph(QSize const&) () at /usr/lib/libQt5Quick.so.5 #17 0x7f1e9751d118 in () at /usr/lib/libQt5Quick.so.5 #18 0x
[kmail2] [Bug 387439] New: Regression: "Rich Text" can not be permanently disabled anymore
https://bugs.kde.org/show_bug.cgi?id=387439 Bug ID: 387439 Summary: Regression: "Rich Text" can not be permanently disabled anymore Product: kmail2 Version: unspecified Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: composer Assignee: kdepim-b...@kde.org Reporter: k...@kdex.de Target Milestone: --- If I remember correctly, clicking the "Rich Text" button at the top and hence disabling HTML composition used to cause this preference to be saved for future e-mails. Further, I think "Rich Text" was turned off by default. Composing a new mail, "Rich Text" always seems to be re-enabled, and I always have to re-disable it manually, as I prefer to send plain-text e-mails. This setting should either be saved or configurable in kmail's options. Looks like a regression. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 387439] Regression: "Rich Text" can not be permanently disabled anymore
https://bugs.kde.org/show_bug.cgi?id=387439 --- Comment #1 from kdex --- (I'm using kmail2 5.6.3, which is not listed in the selection above.) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 371943] Top search results can often be unexpected for users
https://bugs.kde.org/show_bug.cgi?id=371943 --- Comment #2 from kdex --- Looks like this has been fixed in the meantime; can't reproduce it myself anymore on the latest stable. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 358049] URLs that end in . or ? aren't parsed correctly
https://bugs.kde.org/show_bug.cgi?id=358049 --- Comment #2 from kdex --- No; then the URI wouldn't *end* in the question mark. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 358049] URLs that end in . or ? aren't parsed correctly
https://bugs.kde.org/show_bug.cgi?id=358049 --- Comment #4 from kdex --- I don't see a clear benefit from teaching people to misunderstand URLs. Suggesting that they might not end in a dot will naturally break lots of valid URLs, and the same goes for question marks (and potentially other tokens that I haven't checked). Also, expecting that users will put punctuation symbols after their URLs to end a sentence is a constructed heuristic; the majority of my sent and received mails actually contain footnotes such as "[1]", which will be completed with their URLs at the bottom of the mail, line by line. This format is also very wide-spread and suffers from KMail's heuristic. Next, observe that this is not just about usernames that might end in punctuation. See [1] to agree that a dot at the end of a domain is, too, valid syntax and should be parsed to reflect that. In the case of usernames or other dynamic parts in a URL, KMail *will* break websites (like [2], which allows trailing dots in usernames and thus, in their profile page URLs). [1] https://webmasters.stackexchange.com/questions/73934/how-can-urls-have-a-dot-at-the-end-e-g-www-bla-de/73937 [2] https://www.npmjs.com -- You are receiving this mail because: You are watching all bug changes.
[telepathy] [Bug 358048] New: URL parser doesn't handle edge cases well
https://bugs.kde.org/show_bug.cgi?id=358048
Bug ID: 358048
Summary: URL parser doesn't handle edge cases well
Product: telepathy
Version: git-latest
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: common-internals
Assignee: kde-telepathy-b...@kde.org
Reporter: k...@kdex.de
The current implementation doesn't play well with URLs that contain a trailing
dot:
https://example.com/users/example.
is wrongly parsed as
https://example.com/users/example
and
https://example.com/users/example?
is, too, wrongly parsed as:
https://example.com/users/example
The relevance of the latter case is debatable, since in URLS, "?" commonly only
serves as a delimiter in front of the GET arguments. So, not parsing it
shouldn't make a difference to the URL pointed to.
The period, on the other hand, makes a drastic difference, since this is a
quite common character allowed in usernames for a lot of websites. Since most
RESTful websites have URL schemes such as `/users/${username}`, this completely
breaks the ability to freely link to your user page (which is how I found this
bug).
Reproducible: Always
Steps to Reproduce:
1. Open a KTp conversation.
2. Send a URL to somebody that ends with "." or "?".
Actual Results:
The characters "." and "?" aren't parsed, although they are valid URLs.
Expected Results:
The parser should match these characters, too.
--
You are receiving this mail because:
You are watching all bug changes.
[telepathy] [Bug 358048] URLs that end in . or ? aren't parsed correctly
https://bugs.kde.org/show_bug.cgi?id=358048 kdex changed: What|Removed |Added Summary|URL parser doesn't handle |URLs that end in . or ? |edge cases well |aren't parsed correctly -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 358049] New: URLs that end in . or ? aren't parsed correctly
https://bugs.kde.org/show_bug.cgi?id=358049
Bug ID: 358049
Summary: URLs that end in . or ? aren't parsed correctly
Product: kmail2
Version: 5.1
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: kdepim-b...@kde.org
Reporter: k...@kdex.de
The current implementation doesn't play well with URLs that contain a trailing
dot:
https://example.com/users/example.
is wrongly parsed as
https://example.com/users/example
and
https://example.com/users/example?
is, too, wrongly parsed as:
https://example.com/users/example
The relevance of the latter case is debatable, since in URLs, "?" commonly only
serves as a delimiter in front of the GET arguments. So, not parsing it
shouldn't make a difference to the URL pointed to.
The period, on the other hand, makes a drastic difference, since this is a
quite common character allowed in usernames for a lot of websites. Since most
RESTful websites have URL schemes such as `/users/${username}`, this completely
breaks the ability to freely link to your user page (which is how I found this
bug).
Reproducible: Always
Steps to Reproduce:
1. Write a mail that contains URLs that end in "." or "?"
2. View them in the message viewer
Actual Results:
The characters "." and "?" aren't parsed, although they are valid URLs.
Expected Results:
The parser should match these characters, too.
--
You are receiving this mail because:
You are watching all bug changes.
[telepathy] [Bug 358051] New: HTML source of XMPP stanzas with HTML bodies is visible
https://bugs.kde.org/show_bug.cgi?id=358051 Bug ID: 358051 Summary: HTML source of XMPP stanzas with HTML bodies is visible Product: telepathy Version: 15.08.2 Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: text-ui Assignee: kde-telepathy-b...@kde.org Reporter: k...@kdex.de Whenever a message is received that was sent from an XMPP client that supports HTML in message stanzas, it escapes the HTML and puts this into the conversation window. What should really be done here is either parse the HTML and display it accordingly, or grab the alternative stanza body that doesn't contain any HTML tags. Reproducible: Always Steps to Reproduce: 1. Send a URL to an image or a formatted message from Pidgin to KTp 2. View the message that is received in KTp Actual Results: The conversation contains an escaped form of the raw HTML in the stanza's body that was generated by Pidgin Expected Results: Either, the HTML is parsed and displayed accordingly, or the non-HTML body is displayed (Pidgin actually sends two bodies; one for HTML-aware clients, and one with all HTML tags stripped). -- You are receiving this mail because: You are watching all bug changes.
[telepathy] [Bug 358051] HTML source of XMPP stanzas with HTML bodies is visible in OTR messages
https://bugs.kde.org/show_bug.cgi?id=358051 kdex changed: What|Removed |Added Summary|HTML source of XMPP stanzas |HTML source of XMPP stanzas |with HTML bodies is visible |with HTML bodies is visible ||in OTR messages -- You are receiving this mail because: You are watching all bug changes.
[telepathy] [Bug 358051] HTML source of XMPP stanzas with HTML bodies is visible in OTR messages
https://bugs.kde.org/show_bug.cgi?id=358051 --- Comment #1 from kdex --- Note that I just realized that this issue only occurs within OTR sessions. -- You are receiving this mail because: You are watching all bug changes.
