<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/119498/">https://git.reviewboard.kde.org/r/119498/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On July 27th, 2014, 11:17 a.m. UTC, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<table width="100%" border="0" bgcolor="white" style="border: 1px solid #C0C0C0; border-collapse: collapse; margin: 2px padding: 2px;">
<thead>
<tr>
<th colspan="4" bgcolor="#F0F0F0" style="border-bottom: 1px solid #C0C0C0; font-size: 9pt; padding: 4px 8px; text-align: left;">
<a href="https://git.reviewboard.kde.org/r/119498/diff/1/?file=293512#file293512line300" style="color: black; font-weight: bold; text-decoration: underline;">drkonqi/reportassistantpages_bugzilla.cpp</a>
<span style="font-weight: normal;">
(Diff revision 1)
</span>
</th>
</tr>
</thead>
<tbody style="background-color: #e4d9cb; padding: 4px 8px; text-align: center;">
<tr>
<td colspan="4"><pre style="font-size: 8pt; line-height: 140%; margin: 0; ">bool BugzillaLoginPage::canSetCookies()</pre></td>
</tr>
</tbody>
<tbody>
<tr>
<th bgcolor="#f0f0f0" style="border-right: 1px solid #C0C0C0;" align="right"><font size="2">287</font></th>
<td bgcolor="#ffffff" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "> <span class="k">return</span><span class="p">;</span></pre></td>
<th bgcolor="#f0f0f0" style="border-left: 1px solid #C0C0C0; border-right: 1px solid #C0C0C0;" align="right"><font size="2">300</font></th>
<td bgcolor="#ffffff" width="50%"><pre style="font-size: 8pt; line-height: 140%; margin: 0; "><span class="cm"> return;</span></pre></td>
</tr>
</tbody>
</table>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">this is commented.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">if the test is pointless altogether (i do not know. no idea. no record on drkonqui) just remove it with the comment in the commit message, but ifdeffing a void statement makes us look silly ;-)</p></pre>
</blockquote>
<p>On July 29th, 2014, 7:57 a.m. UTC, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The comments on lines 295-298 explain why I have commented out the return statement. I am hoping a KDE core developer can suggest a better way of handling the situation than aborting Dr Konqi.</p></pre>
</blockquote>
<p>On July 29th, 2014, 10:42 a.m. UTC, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Well, the claim is that aborting for no cookie support is wrong in the first place.<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
If so, drop the code.<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
If not (or unsure) please don't "break" it with an unrelated patch.</p></pre>
</blockquote>
<p>On July 30th, 2014, 9:27 a.m. UTC, <b>Aaron J. Seigo</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The login relies on cookies so the check must stAy. The check should remain osx in case in future this works. However what should probably happen is the Login button and text fields should be disabled pendiNg a call to see if cookies are enabled. That check should made async and the message boxes removed in favour oof inline messages Incliding A link to tirn cookies on instead of a yes/no dialog.<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
Sorry for the typos. This form barel works at all with the android web browser :(<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
miAnimizin</p></pre>
</blockquote>
<p>On August 1st, 2014, 2:46 a.m. UTC, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The login works OK, cookies or not. Dr K asks you to enter user name and password every time, regardless of whether you are already logged in and have cookies. In my case, the cookies are in Firefox in whatever location it uses with Apple OS X. KDE cannot find them there, but maybe Qt can or will be able to. I have tried (briefly) going the KDE way, using Konqueror and defining it (to KDE preferences) as my preferred browser and then logging in to BKO with Konqueror, but on Apple OS X that is cumbersome to set up and does not work predictably in Dr K, as it must if we want the average user to report bugs.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">After the login, it was possible to report a bug completely https://bugs.kde.org/show_bug.cgi?id=336075#c3 on BKO, but with the cookie check enabled one cannot report anything, because Dr K crashes in the middle of the cookie check (on Apple OS X).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Dr K uses remote procedure calls to do its work on BKO (class KXmlRpc::Client), including logging in. See code in kde-runtime/drkonqi/bugzillalib.cpp, lines 68-210. It would be nice if Dr K could somehow connect to BKO via the user's browser of choice or cookies therein, using something really portable, similar to QDesktopServices::openUrl(), but I cannot see any immediate way to do that.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I have another bug, not yet investigated in detail, where Dr K has lost the login to BKO somehow and cannot submit the completed report, but it was still able to save it in a file.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It is hard to know how to test Dr K's bug-report submission thoroughly without cluttering up BKO with irrelevant reports. Is there a test version of the BKO database somewhere?</p></pre>
</blockquote>
<p>On August 1st, 2014, 8:43 p.m. UTC, <b>Ben Cooksley</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The use of the Bugzilla XMLRPC api is required i'm afraid. The web browser interface cannot be used - due to CSRF protections now built into it. In addition, it changes from time to time breaking compatability. This form of HTML scraping was used by prior versions of Dr Konqi - and broke quite badly when Bugzilla was upgraded to 4.2.x.</p></pre>
</blockquote>
<p>On August 2nd, 2014, 2:12 a.m. UTC, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">@Ben Cooksley: Understood. I was thinking more along the lines of connecting without starting a browser window (which would be a nuisance for the user anyway), but somehow using the cookies that might have been stored by the user's browser of choice, and if that fails THEN ask for username and password. Our problem, on Apple OS X, is that none of Dr K works ATM if your browser of choice is Safari or Firefox or even Konqueror, because the cookies are stored somewhere that is not the KCookieJar. Maybe the Qt guys solved this problem somewhere, e.g. when developing QDesktopServices::openUrl(). Of course, Dr K must still use KXmlRpc::Client for data transfer to and fro.</p></pre>
</blockquote>
<p>On August 2nd, 2014, 8:21 a.m. UTC, <b>RJVB Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">? Maybe it's because I have Chrome as my default browser, but Konqueror uses the kcookiejar over here. If I make sure kded4 is running, that is; otherwise it can't.<br style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;" />
I do have a bit of a hard time believing that someone tweaked things so that KDE would use the native cookie store but as a function of which browser you have configured as a default. (If I'd have to chose I'd say that support for native plugins is a tad more useful!)</p></pre>
</blockquote>
<p>On August 2nd, 2014, 8:53 a.m. UTC, <b>Ben Cooksley</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Unfortunately Bugzilla has removed support for using cookies to submit XMLRPC API queries in version 4.4, in favour of access tokens so it isn't possible to do that either i'm afraid :(</p></pre>
</blockquote>
<p>On August 4th, 2014, 4:45 a.m. UTC, <b>Ian Wadham</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It seems that bugs.kde.org has changed to using Bugzilla 4.4.5 in recent days, but I see no corresponding changes for Dr Konqi source code to use tokens. So what is going on?</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Also it looks as though RPC for WebServices User.login is deprecated in Bugzilla 5.0, all of it (see http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService/User.html) and that tokens will in turn give way to "Bugzilla_api_key" or supplying login name and password with every remote procedure call (see http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/WebService.html#LOGGING_IN).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I might have a try at using tokens in Dr K (conditional on Q_OS_MAC) and see if that will work when no cookies are visible. What do you think?</p></pre>
</blockquote>
<p>On August 4th, 2014, 8:33 a.m. UTC, <b>RJVB Bertin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I think you'd better ascertain first that BKO will stick to unmodified and uptodate Bugzilla first ;)</p></pre>
</blockquote>
<p>On August 4th, 2014, 9:12 a.m. UTC, <b>Ben Cooksley</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">We will be doing as much as possible to reduce the number of modifications - and staying up to date.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">As it seems Bugzilla upstream has no problem with regular changes in their API, we may need to put in place a shim which takes in certain requests needed by Dr Konqi for it to work - and then communicates with Bugzilla to do the necessary actions. Volunteers?</p></pre>
</blockquote>
</blockquote>
<pre style="margin-left: 1em; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It looks as though bugzillalib.cpp, part of Dr K, is already fairly thin. What it needs, perhaps, is a check of the Bugzilla version, backed by alternative compositions of the parameter maps and interpretations of responses from BKO, depending on whether we are still using "this" version of Bugzilla or "the next". Perhaps the changeover to a new version of BKO could then be coded for in Dr K and released in KDE software ahead of time, whenever convenient for the KDE community and downstream people.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I am not volunteering, though. KCrash and Dr K are currently not working at all on Apple OS X. My objective is to fix that, by any means whatever, and move on to the next KDE portability problem on Apple OS X. I have been stuck on this one for far too long already (about 2 months) and have still not reached the end of the Dr Konqi problems.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">See my comments under "Testing Done" above.</p></pre>
<br />
<p>- Ian</p>
<br />
<p>On July 30th, 2014, 1:04 p.m. UTC, Ian Wadham wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tr>
<td>
<div>Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and Michael Pyne.</div>
<div>By Ian Wadham.</div>
<p style="color: grey;"><i>Updated July 30, 2014, 1:04 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kde-runtime
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">When a KDE app crashes in Apple OS X, it just disappears from the screen. At the most, the user is invited to report the crash to Apple. AFAIK this has been a problem in KDE on Apple OS X for years, leading to frustration with KDE among Apple users and MacPorts developers and an attitude among KDE developers of "Why does nobody report the problem(s) on bugs.kde.org?"</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">It is my strong belief that the failure to report crashes of KDE apps in Apple OS X also exists in Frameworks.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">So far I have identified a number of portability bugs in KDE on Apple OS X: 1 in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are submitted in this review. Patches for KCrash and kdeinit4 are submitted in part 1 of this review, against kdelibs. I am still investigating the other two problems in Dr Konqi - and there could be more than two...</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">In this review we have three portability problems:</p>
<ol style="padding: 0;text-rendering: inherit;margin: 0 0 0 2em;line-height: inherit;white-space: normal;">
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">On Apple OS X, Dr Konqi's dialog box hides itself underneath the main window of the app that has just crashed, so is effectively useless. This appears to be because Dr Konqi is started by a Linux/Unix method (fork() + exec()?). If an app is started with the Apple OS X "open" command, it always appears on top. The patch just raises the dialog box.</p>
</li>
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on the last line. This appears to be an error in the algorithm used (i.e. also a bug in Linux KDE), but the patch is treating it as an Apple OS X portability problem for now.</p>
</li>
<li style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: normal;">
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Dr Konqi checks whether the user can save cookies in kcookiejar and, if not, stops reporting the crash. On Apple OS X, cookies would be kept in another browser (e.g. Safari or Firefox) and not in KDE's default browser (Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter what, as long as it can connect to bugs.kde.org and log in.</p>
</li>
</ol></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an Apple OS X environment and used it to test against the KDE 4.13 branch. I have been testing with a KDE app that I can crash at will and using stderr and Apple OS X Console log output to determine the outcome.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Please note that I am the -only- KDE developer who has this kind of setup, but I am NOT a KDE core developer. My experience before now has been in KDE Games. However I used to be a UNIX and database guru before I retired in 1998.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I NEED HELP from KDE -core- developers to proceed further. These problems will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks repositories. I am sure there are many more Apple OS X portability problems in Dr Konqi and other KDE software.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user, often fails to complete the backtrace report and then fails to connect to bugs.kde.org.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">With my patches, Dr Konqi on Apple OS X can generate a full crash report, including the backtrace and the results of the dialog with the user. Sometimes, however, it fails to submit the completed report to bugs.kde.org. This problem is still under investigation.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I would not have got this far without help from Michael Pyne, Thomas Lübking and several of the MacPorts developers, as well as the unfailing enthusiasm and encouragement of my friend Marko Käning.</p></pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>drkonqi/reportassistantpages_bugzilla.cpp <span style="color: grey">(86ca327)</span></li>
<li>drkonqi/gdbhighlighter.cpp <span style="color: grey">(7cd0aa9)</span></li>
<li>drkonqi/main.cpp <span style="color: grey">(75e060e)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/119498/diff/" style="margin-left: 3em;">View Diff</a></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">File Attachments </h1>
<li><a href="https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt">Log of Dr K ASSERT problem</a></li>
</ul>
</td>
</tr>
</table>
</div>
</body>
</html>