D22326: fix API availability/version detection to not be terribly racey

[Harald Sitter]

sitter created this revision.
sitter added a reviewer: Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
sitter requested review of this revision.

REVISION 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

REPOSITORY
  R871 DrKonqi

BRANCH
  versioncheck

REVISION DETAIL
  https://phabricator.kde.org/D22326

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/bugzillaintegration/assistantpage_bugzilla_version.cpp
  src/bugzillaintegration/assistantpage_bugzilla_version.h
  src/bugzillaintegration/bugzillalib.cpp
  src/bugzillaintegration/bugzillalib.h
  src/bugzillaintegration/qml.qrc
  src/bugzillaintegration/qml/BusyIndicator.qml
  src/bugzillaintegration/reportassistantdialog.cpp
  src/bugzillaintegration/reportassistantdialog.h
  src/bugzillaintegration/reportassistantpages_bugzilla.cpp
  src/bugzillaintegration/reportassistantpages_bugzilla.h
  src/bugzillaintegration/ui/assistantpage_bugzilla_version.ui
  src/drkonqi_globals.h

To: sitter, #plasma
Cc: plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20190708/8f3d0643/attachment-0001.html>