[kmail2] [Bug 389797] kmail/Kontact automatically opens a link when just clicking on a specific message in the list.

2018-02-02 Thread a . key
https://bugs.kde.org/show_bug.cgi?id=389797

--- Comment #2 from a.key  ---

OK I narrowed it down to interesting html attachments.

I'm attaching one here which I think is not that confidential. 

Basically - sending myself a message containing this attachment and then
clicking on the received email in the list automatically opens the link in
browser.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 389797] kmail/Kontact automatically opens a link when just clicking on a specific message in the list.

2018-02-02 Thread a . key
https://bugs.kde.org/show_bug.cgi?id=389797

--- Comment #1 from a.key  ---
Created attachment 110302
  --> https://bugs.kde.org/attachment.cgi?id=110302&action=edit
HTML attachment that is automatically being parsed by kmail when clicking it on
the list

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 389797] New: kmail/Kontact automatically opens a link when just clicking on a specific message in the list.

2018-02-02 Thread a . key
https://bugs.kde.org/show_bug.cgi?id=389797

Bug ID: 389797
   Summary: kmail/Kontact automatically opens a link when just
clicking on a specific message in the list.
   Product: kmail2
   Version: 5.7.1
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: message list
  Assignee: kdepim-bugs@kde.org
  Reporter: a@moronet.pl
  Target Milestone: ---

Just got an email from one of our partners and noticed that Kontact
automatically opened a link in my browser after I clicked on the message in the
list which made me very worried.


Obviously I'd like to attach the email here but since it's a bit confidential I
wouldn't want it to appear publicly on the net.

Is there a way to attach something here and have it only viewable by developers
rather than general public ?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Akonadi] [Bug 379285] New: Akonadi IMAP doesn't refresh connections after sleep or network change

2017-04-27 Thread a . key
https://bugs.kde.org/show_bug.cgi?id=379285

Bug ID: 379285
   Summary: Akonadi IMAP doesn't refresh connections after sleep
or network change
   Product: Akonadi
   Version: 1.13.0
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: IMAP resource
  Assignee: chrig...@fastmail.fm
  Reporter: a@moronet.pl
CC: kdepim-bugs@kde.org, vkra...@kde.org
  Target Milestone: ---

Hi,
This bug has been around for so long that I don't even remember when I first
started to suffer from it but probably around early kde 4.x

I come to work, dock my laptop and power it on. Unlock the HDD and eventually
login to KDE. Open kmail or kontact, emails are being checked and appear in my
folders - so far so good.
My email accounts are all configured with IMAP and none of them have "Enable
interval mail checking" which should be using IMAP NOTIFY to get emails ASAP. 
And that works perfect. Emails appear in my inboxes almost instantly (please
note I have have my android phone) very close to me where I have the same IMAP
accounts configured and I can hear notifications for whenever a new message
comes in. There's a slight delay (about 1s max) between my phone's new email
notification and emails appearing in kmail/kontact but that's fine. So so far
everything is working great. Until...

I undock my laptop which switches networks through NetworkManager from wired
ethernet to WiFi still having kamil or contact opened and this is where emails
stop coming through to kmail/kontact. I can wait tens of minutes and no single
email will come even though I can hear tons of them came because my phone
notified me about them. This can last for hours.
I normally these days simply execute: akonadictl restart to refresh the
connections but this is not a maintainable solution.

Please note that this happens whenever I switch any of my networks eg:
- I'm at home connected to my wifi then I VPN in to my office where all my
connections are forced through the VPN,
- I'm VPNed in and disconnected the VPN going back to normal WiFi
- I'm on WiFi and the connection drops and is reestablished again
- I'm switching WiFi networks
- etc.










$ sudo dnf info akonadi 
[sudo] password for a.key:  
Last metadata expiration check: 0:02:06 ago on Thu Apr 27 10:47:11 2017.
Installed Packages  
Name: akonadi   
Arch: x86_64
Epoch   : 0 
Version : 1.13.0
Release : 102.fc24  
Size: 274 k 
Repo: @System   
>From repo   : fedora   
> 
Summary : PIM Storage Service Libraries 
URL : http://community.kde.org/KDE_PIM/Akonadi
License : LGPLv2+
Description : PIM Storage Service Libraries.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Akonadi] [Bug 360792] akonadi_davgroupware_resource crashes constandly

2017-04-13 Thread a . key
https://bugs.kde.org/show_bug.cgi?id=360792

a.key  changed:

   What|Removed |Added

 CC||a@moronet.pl

--- Comment #14 from a.key  ---
I'm on Fedora 25 with:
plasma: 5.9.3
Framework: 5.33.0
Qt: 5.7.1
kdepim: 16.12.2
akonadi: 1.13.0
kf5-akonadi-calendar: 16.12.3

akonadi_davgroupware_resource crashes everytime I add google's DAV calendar
using the still working old DAV endpoints which require "application password".
The DAV resource URL I'm using is:
https://www.google.com/calendar/dav/str...@gmail.com

Stack trace:

Application: akonadi_davgroupware_resource (akonadi_davgroupware_resource),
signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fcbb8cc6940 (LWP 29557))]

Thread 5 (Thread 0x7fcba4a97700 (LWP 29562)):
#0  0x7fcbd177029a in timerSourceCheckHelper(GTimerSource*) () at
/lib64/libQt5Core.so.5
#1  0x7fcbc84fbbc9 in g_main_context_check () at /lib64/libglib-2.0.so.0
#2  0x7fcbc84fc104 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#3  0x7fcbc84fc27c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#4  0x7fcbd17706eb in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#5  0x7fcbd172168a in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#6  0x7fcbd157e5e3 in QThread::exec() () at /lib64/libQt5Core.so.5
#7  0x7fcbd15829ca in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#8  0x7fcbd06576ca in start_thread () at /lib64/libpthread.so.0
#9  0x7fcbd0975f7f in clone () at /lib64/libc.so.6

Thread 4 (Thread 0x7fcba5298700 (LWP 29560)):
#0  0x7fcbd096a01d in poll () at /lib64/libc.so.6
#1  0x7fcbc84fc166 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x7fcbc84fc27c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#3  0x7fcbd17706eb in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#4  0x7fcbd172168a in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#5  0x7fcbd157e5e3 in QThread::exec() () at /lib64/libQt5Core.so.5
#6  0x7fcbd15829ca in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#7  0x7fcbd06576ca in start_thread () at /lib64/libpthread.so.0
#8  0x7fcbd0975f7f in clone () at /lib64/libc.so.6

Thread 3 (Thread 0x7fcba5a99700 (LWP 29559)):
#0  0x7fcbd096a01d in poll () at /lib64/libc.so.6
#1  0x7fcbc84fc166 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x7fcbc84fc27c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#3  0x7fcbd17706eb in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/libQt5Core.so.5
#4  0x7fcbd172168a in
QEventLoop::exec(QFlags) () at
/lib64/libQt5Core.so.5
#5  0x7fcbd157e5e3 in QThread::exec() () at /lib64/libQt5Core.so.5
#6  0x7fcbd8979739 in QDBusConnectionManager::run() () at
/lib64/libQt5DBus.so.5
#7  0x7fcbd15829ca in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#8  0x7fcbd06576ca in start_thread () at /lib64/libpthread.so.0
#9  0x7fcbd0975f7f in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7fcbae925700 (LWP 29558)):
#0  0x7fcbd096a01d in poll () at /lib64/libc.so.6
#1  0x7fcbcc0f0d10 in _xcb_conn_wait () at /lib64/libxcb.so.1
#2  0x7fcbcc0f2aa9 in xcb_wait_for_event () at /lib64/libxcb.so.1
#3  0x7fcbb2108d69 in QXcbEventReader::run() () at /lib64/libQt5XcbQpa.so.5
#4  0x7fcbd15829ca in QThreadPrivate::start(void*) () at
/lib64/libQt5Core.so.5
#5  0x7fcbd06576ca in start_thread () at /lib64/libpthread.so.0
#6  0x7fcbd0975f7f in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7fcbb8cc6940 (LWP 29557)):
[KCrash Handler]
#6  0x55f76db5ef4b in EtagCache::setEtag(QString const&, QString const&) ()
#7  0x55f76db7dd8f in DavGroupwareResource::onItemFetched(KJob*,
DavGroupwareResource::ItemFetchUpdateType) ()
#8  0x7fcbd1749a56 in QMetaObject::activate(QObject*, int, int, void**) ()
at /lib64/libQt5Core.so.5
#9  0x7fcbd2f1c682 in KJob::result(KJob*, KJob::QPrivateSignal) () at
/lib64/libKF5CoreAddons.so.5
#10 0x7fcbd2f1dfc1 in KJob::finishJob(bool) () at
/lib64/libKF5CoreAddons.so.5
#11 0x55f76db41c6d in DavItemFetchJob::davJobFinished(KJob*) ()
#12 0x7fcbd1749a56 in QMetaObject::activate(QObject*, int, int, void**) ()
at /lib64/libQt5Core.so.5
#13 0x7fcbd2f1c682 in KJob::result(KJob*, KJob::QPrivateSignal) () at
/lib64/libKF5CoreAddons.so.5
#14 0x7fcbd2f1dfc1 in KJob::finishJob(bool) () at
/lib64/libKF5CoreAddons.so.5
#15 0x7fcbd57ed442 in KIO::SimpleJob::slotFinished() () at
/lib64/libKF5KIOCore.so.5
#16 0x7fcbd57f7d26 in KIO::TransferJob::slotFinished() () at
/lib64/libKF5KIOCore.so.5
#17 0x7fcbd57f7491 in KIO::TransferJob::qt_static_metacall(QObject*,
QMetaObject::Call, int, void**) () at /lib

[kmail2] [Bug 373341] kMail2 unread messages quick filter - messages disappear after clicking

2016-12-06 Thread a . key
https://bugs.kde.org/show_bug.cgi?id=373341

--- Comment #1 from a.key  ---
Even more interesting behavior can be noted in akregator which may be
related...
When using the "Unread" quick filter there and setting a focus on any filtered
message the message is set to read and disappears from the list but unlike in
kmail2 focus is automatically set to the next message in the list which quickly
gets set as "read" and removed from the list...
This behavior continues until there are no "unread" messages on the list which
happens very quickly.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 373341] New: kMail2 unread messages quick filter - messages disappear after clicking

2016-12-06 Thread a . key
https://bugs.kde.org/show_bug.cgi?id=373341

Bug ID: 373341
   Summary: kMail2 unread messages quick filter - messages
disappear after clicking
   Product: kmail2
   Version: 5.3.0
  Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: search
  Assignee: kdepim-bugs@kde.org
  Reporter: a@moronet.pl
  Target Milestone: ---

This is basically a copy of this bug report:
https://bugs.kde.org/show_bug.cgi?id=259813 since the old one is filed against
an unmaintained  4.9 version.

Clicking on a message filtered through quick filter "Unread" marks the message
as read and removes it from the list of filtered messages. 

To reproduce:
1.Have at least 1 unread message in the inbox/folder
2.Click on the quick filter icon
3.Tick the "Unread" quick filter icon
4.Select any message from the list of "Unread"
5.The message contents is displayed in the message preview pane but within a
second it's marked as read and disappears from the list of filtered messages

Desired behavior:
At step 4, after clicking on a filtered/found message it should get marked as
read but remain on the list of filtered messages.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[kmail2] [Bug 259813] reading mails in unread mode instantly disappears from list

2015-05-05 Thread a . key
https://bugs.kde.org/show_bug.cgi?id=259813

a.key  changed:

   What|Removed |Added

 CC||a@moronet.pl

--- Comment #36 from a.key  ---
Could this be finally fixed ?
That quick filter "Unread" function is basically useless with this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
Kdepim-bugs mailing list
Kdepim-bugs@kde.org
https://mail.kde.org/mailman/listinfo/kdepim-bugs