I have just had another rejection of a crash I had hoped to report *quickly* via DrKonqi. This time, I hit a max. comment limit I have never seen before (error code 114), which is evidently not very difficult to do when you include a full backtrace in the initial report body. I've asked about the plans with DrKonqi on the plasma-devel ML, but I'd hope we all agree that it's important that users file bug reports where appropriate, and that they're more likely to do so the more streamlined the process is. Keeping a reporting tool around that gets you a rejection message (and then doesn't even let you back up and prune the report if it's simply too long) is counterproductive: the risk is real that many users will simply dismiss the dialog after a few such experiences and not bother reporting at all. Anyway, may I suggest doing whatever it takes in BKO settings to increase compatibility with DrKonqi until that tool gains a working feature to include backtraces as an attachment (if the site even supports such a feature)? I'm pretty sure it must be possible to distinguish reports coming in via the website and via DrKonqi. It might also be possible to raise or remove the length limit on the initial message (I'd argue the initial report is not a comment and thus not subject to comment length limits ...).
Sorry, but we're going to need far more specific details on what exactly is being rejected here to look into this in greater detail.... The full error message would be a good start.
I no longer have the exact error message, but the code (114) should be all you need. It was explained as "comment exceeds limit (65535 bytes)". The report compiled in DrKonqi was submitted manually as https://bugs.kde.org/show_bug.cgi?id=371933. I put everthing above DrKonqi's "backtrace" line in the ticket text (copy/paste), and everything below that line as an attachment. You should be able to combine text and backtrace and try to file that to see what happens, but I think you'll find there is indeed a simple length limit somewhere that's being applied.
This behaviour has always been there, even in the old Bugzilla 4.4.10 codebase we ran. This particular backtrace is simply too long to be pasted in, so this is a Dr Konqi bug in so far that it does not respect the (quite reasonable) limitations imposed by Bugzilla. We won't be making changes to Bugzilla's codebase and database structure (which is the hard constraint here) and incurring maintenance costs in the process, this needs to be fixed in Dr Konqi as it is behaving incorrectly. Reassigning to Dr Konqi.
Who remembers the days where 640Kb seemed a reasonable limit? ;) I'm a bit surprised the database would (still) use a hard length limit, but then I'm not a DB engineer and I guess KDE didn't write their own bug tracker from scratch. Either way: can remote clients query the system for the length limit? And on a more future note: how feasible would a be to implement a mechanism through which backtraces can be submitted as a backtrace with a standardised name, and then requested by remote clients like DrKonqi to use in searching for duplicate reports? I'm thinking of a custom entry field (like there are now for "steps to reproduce" and "Expected behaviour") which puts content entered there into an attachment with a standardised name, and a corresponding hook for remote clients to achieve the same thing. Does the tracker software have a search-for-duplicates feature one can evoke remotely, ideally one that knows about the backtrace formats used by the major debuggers?
*** This bug has been marked as a duplicate of bug 385721 ***