GitLab

Summary:
KWallet::openWallet takes a windowId as a parameter.

QWidget->winId() is a dangerous call, it will create an underlying
platform window when called. This happens even if we're not the toplevel
widget. On X11 this passed winId must have always been broken, but not
in a way that caused a problem.

This leaves QtWayland in a very confused state with the side effect that
all scrolling widgets become broken.

BUG: 418755
BUG: 420035

Test Plan:
Bisected drkonqi till we found the cause
Verified fix by running crashtest (with some mods so I could report a bug)
I can't confirm the winId is correct on X11, but the code looks safe

Reviewers: #plasma, sitter

Reviewed By: sitter

Subscribers: sitter, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D28832

Summary:
we already (re)set the focus on failed login attempt but neglected to do
it when showing the page.

BUG: 418309
FIXED-IN: 5.18.3

Test Plan:
- empty kwallet
- try to report bug
- dialog appears and has focus on email input
- go back
- go forward
- still focus on email input
- provide wrong credentials
- again focus on email input + error message

Reviewers: #plasma, davidedmundson

Reviewed By: #plasma, davidedmundson

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D27776

Summary:
this ensures that all known platforms are actually in the comobox and
reduces the amount of string duplication.

the new code gets the list of platforms from bugzilla and then either
attempts to select the one which was auto-detected by systeminformation
or recycle the one previously used.

setup is now triggered in the constructor. loading from the api is still
fairly cheap but even so takes longer than the hardcoded list, so
loading this on aboutToShow is fairly unattractive at this point.

the now useless members for combobox state tracking are gone entirely.

BUG: 383530
CHANGELOG: The list of available platforms is now always in sync with the list on bugzilla itself

Test Plan:
list gets loaded as expected
list errors as expected when offline

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22492

Summary:
bugzilla has a hardcoded server-side limit for how large a given comment
may be. this can somewhat easily get triggered by heavily threaded
applications as the backtrace would include a lot of "noise" threads.
when this previously happened drkonqi would find itself incapable of
filing the report and leaving the user to their own devices.

now we are much smarter about this
if the reportinterface finds that the bug description is too long it will
try to use a reduced backtrace (only a couple of lines from the relevant
thread) or when that too is too long to exclude the backtrace entirely.
in both events it would then additionally attach the complete backtrace
to the bug.

for this there's a bunch of rejiggering necessary:
- generateReportFullText has had its signature changed, instead of using
  a lazy bool now use enums to control the output. this should be vastly
  more readable
- new Backtrace control on generateReportFullText ranging Complete>
  Redcued>Exclude
- addedToCC was renamed to attachBacktraceWithReport which is a more
  suitable name for what it does. it's logic has been moved to a new
  attachBacktrace which requires the caller to set the actual comment
- attachBacktrace is called with a full report comment when used via \
  attachBacktraceWithReport (i.e. the user indicated that their crash
  is in fact the same as another report, so their report gets
  attached to the other one). it's called with a simplified message when
  attaching as part of a reduced/excluded backtrace dance

the end result is that the reports can no longer exhaust the hardcoded
character limit.

there is one caveat: the user can still write a super long description
manually and exhaust the limit. this is however very hard to do in
real life without "abusing" the description for something.

CHANGELOG: Bug reporting can no longer exhaust the maximum character size enforced by Bugzilla
BUG: 248807
FIXED-IN: 5.17.0

Test Plan:
- file bug report with ETOOLONGTRACE -> gets reduced and attached
- regular attaching still works
- exhausting the limit *exactly* works as expected

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22399

Summary:
the dialog was actually broken through at least all of plasma5 :/

this is no longer necessary. it was used for when random unexpected HTML
would get returned. there is no longer unexpected html:

- the api always returns json blobs
- should the api crap out we'll get protocol errors (HTTP 500 or some such)
  which is also forced into a serialized form and raised as a
  ProtocolException to be handled like errors from the API directly

we always get one "standardized" error message and never an
extended html to display.

Test Plan: builds

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22393

Summary:
previously at a random point in time there'd be a call to get the bugzilla
version, that call would (hopefully) reach the login page and cause it
allow login. this is essentially a blocking safe guard to not talk to
unsupported or unreachable bugzillas. because this was entirely
synchronized there was great potential for signal and state racing
where the login page could randomly end up with a disabled login
button when the api communication failed for whatever reason.

this was further complicated by the fact that there was zero UI backing
for the entire check resulting in the login button getting disabled but
the user not having any indication as to why or any means to retry.

to resolve this problem a bunch of changes are necessary:

- bugzillalib now has an error signal when the version check fails
  (previously not having received a finished signal meant error, when in
   fact that may also mean not-yet-done)
- buzillalib also no longer automatically issues a version lookup as it
  itself has no use of knowing the version right now
- the login page logic has had all awareness of bugzilla availability
  stripped. the assumption now is that when login is reached bugzilla
  could be contacted.
- there is a new 'version' page now sorted before the login page. the
  version page's only use is to provide a UI for the version check or
  more generally if bugzilla is reachable. it has a busy state and an
  error stage, once the version check completed once the page is marked
  inappropriate and would automatically skip ahead as necessary.
  the `appropriate` value specifically allows kassistantdialog to ignore
  the page when skipping forward/backward effectively hiding the page from
  the user.
- for purposes of controlling its own appropriateness the KPageWidgetItem
  of this new page is controlled by the page itself, a design which
  IMO should be also adopted for the other pages
- for visual consistency with plasma a qml busyindicator is used on the
  page. also looks nicer than the ksquencepixmap thingy

The result of this is that upon startup of the dialog, the version page
is created (albeit not visible) and issues a version check. When that
returns the page turns itself inappropriate (and skips ahead if necessary).
Ideally this means the user never sees the page, unless there is an error
in which case the page will block progressing to actually submit the
error to bugzilla. At the same time the user can choose to go back to the
backtrace page to manually grab it and file a bug in the event that
drkonqi cannot get beyond the version page.

BUG: 373099
BUG: 354292
FIXED-IN: 5.17.0
CHANGELOG: Contact to drkonqi is now more reliably verified and the login button enabled when possible

Test Plan:
- slow internet results in page to show up
- errors result in page to go into error state
- fast internet lets the page not show up
- retry button retries when there was an error on first try
- page switches between states correctly

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: broulik, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22326

Summary:
we can't save the info if kwalletd is disabled so let's hide the checkbox

BUG: 363570
FIXED-IN: 5.16.3
CHANGELOG: Login information saving is only offered when supported

Test Plan:
- disable kwalletd in kcm
- checkbox not shown

Reviewers: #plasma, apol

Reviewed By: apol

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22329

Summary:
it's very awkward when you don't know when a change happens or
not, so suitably label the next button so it actually says submit when
it will trigger the report submission.

CHANGELOG: Buttons are more suitably labled when bug reports are submitted

Test Plan: file bug report -> preview page has submit button -> going back it is not submit -> clicking submit it also turns back to next (albeit disabled)

Reviewers: #plasma, #vdg, ngraham

Reviewed By: #vdg, ngraham

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22289

Summary:
when the user takes a very long time to prepare the bug report the original
login session may have timed out and prevent submitting the bug report.
as a super simple way to prevent this let's simply force a refresh.
we need to do a query to check validity anyway, so we might as well
force a refresh and get a new token right away.

this temporarily chains the login interfaces to the report interfaces, upon
successful login the report is sent. if any of the two throws an error
the page goes into error state which offers a retry button to run
aboutToShow again. therefore we also want to disconnect the signal chains
to avoid multiple slot invocations on possible retries.

BUG: 338216
FIXED-IN: 5.17.0
CHANGELOG: Login tokens get refreshed before submitting reports to prevent unauthorized errors

Test Plan:
- file bug without any interruption all goody
- add `Bugzilla::connection().setToken(QString());` to simulate the token having gone invalid -> continues to work
- disconnect network before submit causes a network unreachable login error -> connect again -> retry -> submission succeeds

Reviewers: apol

Reviewed By: apol

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22288

Summary:
users in bugzilla are always identified by their email address so it makes
no sense to label the input username.

calling it email address is also consistent with the bugzilla webui itself.

that said, we actually spell it inconstantly email or e-mail across
software. the most prominent cases in kdepim though spell it
"E-mail Address" for input labels. so, going with that

for ease of reading I'm leaving the code variables and the likes to say
username as this more obviously ties to the related password variables.

BUG: 375462
FIXED-IN: 5.17.0

Test Plan: login page now has an email address label

Reviewers: #plasma, ngraham, apol

Reviewed By: apol

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22212

Summary:
it's a bit moot to load the data from the wallet and then still have the
user manually click a log in button when we could just as well have tried
to log in using the stored credentials.

the new behavior is that the user goes through the bug reporting dialog,
and when showing the login page it will automatically try to login using
stored credentials. if the creds check out, the dialog automatically moves
on to the next page.

- page-validity is now in a helper canLogin function as it needs checking
  in two functions now (walletlogin and loginclick)
- the page now automatically goes into login state and attempts to log in
  using stored credentials

in the event that the credentials are wrong (e.g. password changed on
website) the page will enter error state saying the credentials are wrong.
when no credentials are in the wallet or the credentials are incomplete
(password remembering is off) no auto login happens.

BUG: 202495
FIXED-IN: 5.16.3
CHANGELOG: DrKonqi will now automatically log into bugs.kde.org when possible

Test Plan:
- have no credentials -> no auto login
- login manually and store credentials -> restart -> auto login happens
- change password on website -> restart -> auto login fails & error is shown

Reviewers: #plasma, ngraham

Reviewed By: ngraham

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D22190

Summary:
https://bugzilla.readthedocs.io/en/5.0/api/

the old API is deprecated. the new API is RESTy and much easier to use
plus also has some efficiency boosts.

this commit introduces a new supporting library to wrap the REST API
for easy consumption in drkonqi.

- new internal lib wrapping the REST API
- unit testing of the lib
- xmlrpc use gone
- BugzillaManager continues to be a singleton manager for the API
- ancient cookie system for login is entirely gone, this has been
  deprecated (or perhaps even removed?) for years
- duplicate querying is pretty inefficient, needs porting to
  pagination, but is not worse than what it was before. in fact,
  it's faster than before out of the box!

the lib api is split in three pieces:

1. the connection containing protocol logic
2. the clients containing routing logic
2.1. command models that are basically POSIX-style argument structs which can serialize into json
3. the models deserializing the json API replies back into cpp

clients get a request, give back a job and the intended use is for
the consumer to then connect to the finished signal of the job to then
ask the clients for the final return value of the job.
this is a bit 'meh'. what I really wanted was a Future to be returned
and the caller to connect to the future. unfortunately qfuture is fairly
limited and since qtbase has no Promise implementation I'm rather opting
for the double-function-approach than doing it like we did in the previous
decade and have a gazillion signals.
this way the handling of the job is always uniform and all specific
"handling code" is inside the connected slot rather than the actual
connection.

error handling has been put entirely into exceptions which get raised
when trying to access a finished job. in BugzillaManager they get rescued
and turned into the already existing signals. this simplifies error
handling a fair amount and also makes the error handling code
look uniform across the various API calls we have.
the uniform representation of errors on the REST side thus always has
uniform representation on the c++ side.

Reviewers: apol

Reviewed By: apol

Subscribers: apol, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D19612

follow up to fdff5bd4

with some stuff I missed initially

Minor optimization.
Assign parent directly

Reviewers: sitter, broulik

Reviewed By: sitter, broulik

Subscribers: broulik, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D8309

Summary:
- Fix radios' updating UI as they are toggling not buttonclicking :(
- add a cmdline option to enable bringing up the dialog directly. in a testing scenario it makes sense to skip the notification popup thing and go directly to the dialog
- new env var DRKONQI_KDE_BUGZILLA_URL to override the bugzilla url. for testing purposes we'll want to change the bugzilla url to point to a double instance but otherwise not impact functionality of drkonqi
- new env var DRKONQI_IGNORE_QUALITY to bypass trace quality checks. during testing a proper trace may not be creatable, setting the env var allows bypassing the quality constraints
- set a11y names on text inputs to facilitate a11y enablement (also allows finding them through at-spi for testing purposes ;))

add an integration test based on xvfb+dbus+at-spi

- suite wrapper program isolates the environment a bit,
  starts a xvfb instance and runs a session bus
  inside, then starts the actual tests from inside the isolated environment
- duplicate_attach_test.rb starts an xmlrpc server, a defunct ruby, and
  a drkonqi to trace the defunct ruby. it then uses at-spi to massage the
  drkoknqi GUI into attaching a new trace to a bug via xmlrpc server.
- the xmlrpc server partially falls through to bugstest.kde.org but mostly
  doubles for bugzilla

fix a connect bug when attaching a new trace to an existing report

Test Plan:
`make test` should™ run the integration test assuming requirements are met (ruby+atspi+xmlrpc+xvfb-run).

`XEPHYR=1 make test` will run the test through xephyr rather than xvfb, which is somewhat more useful for test writing and debugging.

Reviewers: #plasma, mart

Reviewed By: #plasma, mart

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D6161

Test Plan: Compiled.

Reviewers: #plasma, mart

Reviewed By: mart

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D2849

Summary: add neon mapping to bug report dialog (why is that stuff not queried from server? :|)

Reviewers: apol

Reviewed By: apol

Subscribers: #neon, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D2118

REVIEW: 126993
Committed from host : Portia.local

Replace KWebView with QTextBrowser in unhandled bugzilla error dialog.
KWebView is not used to load a page here, it is just used to display
HTML with setHtml (without baseUrl) so any external URLs (stylesheets,
images, ...) are not resolved.
Replacing it with QTextBrowser should provide similar rendering.

REVIEW: 125886

KXmlRpcClient is a framework now and acceptable to use.

REVIEW: 122383

In July 2014, the bugs.kde.org database switched to v4.4.5 of Bugzilla
and cookies were no longer accepted, causing bug 337742. This patch uses
the new security system, based on tokens, and implements the future use
of passwords only, whenever Bugzilla changes to the announced v4.5.x. It
also avoids a crash in Dr K on Apple OS X when KCookieJar is not found.

Forward port of review 120431 to plasma-workspace.

REVIEW: 120876

This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
techbase wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:

http://community.kde.org/Frameworks/GitOldHistory

If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.

Branched from the monolithic repo kde-runtime, frameworks  branch, at commit
85b1a18736650e28d8addd441f83083987298233