Fix a strange warning seen on the log from the CI on Windows in
https://github.com/owncloud/client/pull/6621
The test shows, at the beginning
QObject::connect: No such signal DesktopServiceHook::destroyed(QObject*)
And crashes at the and.
My guess is that when QDesktopServices::setUrlHandler is called, the
QMetaObject is not yet initialized
But this is probably not the reason of the crash
There is no real reason to have a timeout. The connection can stay open
as long as we are not authenticated. The User can still re-open a browser
from the UI at any time.
Issue #6612
* Disentangle the previous 'qdbusWorkarounds' into three different
things
* Make not trusting tray.isVisible() a new workaround
* Introduce env vars for all workaround flags
* Use the workaround flags for OSX
* Determine workaround flags for KDE when the plasma integration plugin
is missing
This can happen when the client is started and the internet connection
was not enabled. Then we would fetch the credentials, but we would
no do the refresh token step (because network is down).
So next time we try to connect, we would also not refresh the token
because the credentials are not marked as 'ready'
Reported in
https://github.com/owncloud/client/issues/6522#issuecomment-396845167
It could happen that readyRead was emitted for incoming data while the
download was not yet finished. Then the network job could finish with
no more data arriving - so readyRead wasn't emitted again.
To fix this, the finished signal also gets connected to the readyRead
slot.
Fixes#279
Some setups don't make Qt emit the right signals and the client would
end up in state where it could not do the initial authentications.
This is a similar hack that apparently already was is place for basic
http auth.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Fix#604
Remove the not actionable button but a direct link to the nextcloud
installation page. In this case the button is changed for a label with an
html link to the website.
