[PATCH] Make it possible to file a report directly from the backtrace dialog

[avarab@…]

This patch modifies the backtrace dialog so that it'll link to josm.openstreetmap.de with all the info needed to fill in a bug already provided (by providing a lot of GET parameters in the URL).

It also pre-fills in the description field with something I ripped off from the ​Chrome bug report form which looks like this:

What steps will reproduce the problem?
 1. 
 2. 
 3. 

What is the expected result?

What happens instead?

Please provide any additional information below. Attach a screenshot if
possible.

{{{
Backtrace & other info here
}}}

[avarab@…]

Patch to make the backtrace dialog awesomer

[avarab@…]

Screenshot showing how this looks like

[avarab@…]

Ticket #2845 has been marked as a duplicate of this ticket.

[Gubaer]

I think we should wait to apply it until after the release because there a couple of strings in this patch which should be translated before they become part of tested.

[stoecker]

Two things:

• Include "Include your steps to get to the error (as detailed as possible)!" in last paragraph.
• Please use PUT. The GET request does not work here and also produces very long URL's.

[stoecker]

Regarding the strings I have not that bad feelings, but it does not work as expected. I.e. my Firefox noscript filtered large parts of the request :-)

[stoecker]

Ah, now that I think about it, PUT will not work as expected. It needs server support to save the data for the browser call. Maybe there is a trac plugin for such purposes?

[avarab@…]

Replying to stoecker:

Regarding the strings I have not that bad feelings, but it does not work as expected. I.e. my Firefox noscript filtered large parts of the request :-)

So the URL was passed correctly to firefox but some plugin you have installed intercepted it?

Replying to stoecker:

Ah, now that I think about it, PUT will not work as expected. It needs server support to save the data for the browser call. Maybe there is a trac plugin for such purposes?

I'm not familiar with using PUT like this, is this what e.g. launchpad uses to attach bug report info from ubuntu-bug(1)? Where can I find documentation on it, do you know?

Is this PUT mechanism as portable across browsers as just using a URL as I'm doing now? How should the browser be invoked to use it?

[avarab@…]

Replying to stoecker:

Two things:

• Include "Include your steps to get to the error (as detailed as possible)!" in last paragraph.

I included "Please include information on how to reproduce the error and try to supply as much detail as possible." in the third paragraph which is hopefully as far as most users will read since the auto-fillin bug will work for them.

Do you want something to that effect repeated in the last paragraph?

[Gubaer]

Dirk probably means POST, not PUT, because you're trying to submit structured info (like in a "form"). You're not trying to upload a file.

Trac itself uses POST for the defect submit form. This could be the reason why GET doesn't work (although it should, for this particular case it doesn't really matter whether the submit uses GET or POST).

If you want to suply a patch using POST:

• don't assemble an URL with the request parameters. Rather build up an "encoded" text document (more or less the same format, googling will help)
• open the URL to the form, get an input stream, write the "request document" to the input stram, close it and you're done

[stoecker]

Generally this would be:

• Do a PUT to server with a random ID
• Call the newticket with same ID in browser

As said this needs server support, as the server needs to remember the data until the browser calls again. There are multiple ways to do this, but I can't think of any solution without server support. I now remember, why I did not implement this myself :-)

After disabling NoScript it works (before it stripped all dangerous parts in URL). But NoScript is one of the most often used plugins for Firefox and needs to be taken into account.

Maybe we can use GET request and URL rewriting. I.e. base64 code the passed parameters and allow trac or Apache to decode the text. I think that will solve our issues without POST.

Anyway delayed until after tested.

@Gubaer:
Don't know. POST or PUT. I always mix them up :-)

[stoecker]

Well I like brainstorming. What about that.

@avar:
Please change the request, so that it assembles the data as for POST request (the parameter separation is a bit different (using returns ??). Use wireshark in case of doubt :-) Do an base64 encoding for it and call

​http://josm.openstreetmap.de/josmticket?<base64data>

I will take care to install a little perl server script, which redirects this to a proper newticket call.

[avarab@…]

Replying to Gubaer:

If you want to suply a patch using POST ..

Yeah I'm familiar with how POST requests are constructed. But the summary of this bug is actually slightly misleading. It doesn't add the ability to submit bugs from the backtrace form, it just gives you a HTTP URI to trac with the form pre-filled in.

Unlike opening a GET url browsers don't usually support submitting POST requests from the command line, and if they do (like cURL) they don't do so using some standard invocation syntax we can use on all of them.

Replying to stoecker:

Maybe we can use GET request and URL rewriting. I.e. base64 code the passed parameters and allow trac or Apache to decode the text. I think that will solve our issues without POST.

Maybe not. Why does noscript filter it? If it's just filtering it because it's a huge URL (test urls of mine are around 3000 bytes) then base64 encoding it won't help. If it's triggering due to something else then perhaps we can work around it as you suggest.

@Gubaer:
Don't know. POST or PUT. I always mix them up :-)

POST and PUT are both standard HTTP methods but PUT is only used in advanced clients like those who use WebDAV. Which is why this confused me.

Replying to stoecker:

I will take care to install a little perl server script, which redirects this to a proper newticket call.

Redirects to what? If it redirects to ​another GET url won't noscript filter that all over again? Also see above comment about what it's filtering.

[avarab@…]

Also I've installed noscript 1.9.9.18 for Firefox 3.5.5 on Ubuntu and opening huge URLs like the one JOSM uses with this patch from the command line works just fine without any interference from noscript, e.g.:

firefox 'http://josm.openstreetmap.de/newticket?keywords=template_report&description=What+steps+will+reproduce+the+problem%3F%0A+1.+%0A+2.+%0A+3.+%0A%0AWhat+is+the+expected+result%3F%0A%0AWhat+happens+instead%3F%0A%0APlease+provide+any+additional+information+below.+Attach+a+screenshot+if%0Apossible.%0A%0A{{{%0ABuild-Date:+2009-11-28+16:57:35%09%09%0ARevision:+2533%0AIs-Local-Build:+true%0A%0AMemory+Usage:+51+MB+/+986+MB+(38+MB+allocated,+but+free)%0AJava+version:+1.6.0_16%0A%0A%0APlugins:+tageditor%1Eterracer%0APlugin+tageditor+Version:+18700%0APlugin+terracer+Version:+17874%0A%0Ajava.lang.NullPointerException%0A%09at+org.openstreetmap.josm.actions.FullscreenToggleAction.toggleSelectedState(FullscreenToggleAction.java:76)%0A%09at+org.openstreetmap.josm.actions.FullscreenToggleAction.actionPerformed(FullscreenToggleAction.java:85)%0A%09at+javax.swing.SwingUtilities.notifyAction(SwingUtilities.java:1636)%0A%09at+javax.swing.JComponent.processKeyBinding(JComponent.java:2851)%0A%09at+javax.swing.KeyboardManager.fireBinding(KeyboardManager.java:267)%0A%09at+javax.swing.KeyboardManager.fireKeyboardAction(KeyboardManager.java:216)%0A%09at+javax.swing.JComponent.processKeyBindingsForAllComponents(JComponent.java:2928)%0A%09at+javax.swing.JComponent.processKeyBindings(JComponent.java:2920)%0A%09at+javax.swing.JComponent.processKeyEvent(JComponent.java:2814)%0A%09at+java.awt.Component.processEvent(Component.java:6040)%0A%09at+java.awt.Container.processEvent(Container.java:2041)%0A%09at+java.awt.Component.dispatchEventImpl(Component.java:4630)%0A%09at+java.awt.Container.dispatchEventImpl(Container.java:2099)%0A%09at+java.awt.Component.dispatchEvent(Component.java:4460)%0A%09at+java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1848)%0A%09at+java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:704)%0A%09at+java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:969)%0A%09at+java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:841)%0A%09at+java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:668)%0A%09at+java.awt.Component.dispatchEventImpl(Component.java:4502)%0A%09at+java.awt.Container.dispatchEventImpl(Container.java:2099)%0A%09at+java.awt.Window.dispatchEventImpl(Window.java:2475)%0A%09at+java.awt.Component.dispatchEvent(Component.java:4460)%0A%09at+java.awt.EventQueue.dispatchEvent(EventQueue.java:599)%0A%09at+java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)%0A%09at+java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)%0A%09at+java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)%0A%09at+java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)%0A%09at+java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)%0A%09at+java.awt.EventDispatchThread.run(EventDispatchThread.java:122)%0A%0A}}}%0A'

What Firefox/noscript version are you using, how is it configured and what exactly doesn't work?

[stoecker]

It filtered e.g. all return characters and other special characters due to cross-site-scripting attack. The result was a very distorted description field. I don't think the long URL is a problem.

@Gubaer:
For the server redirect firefox will not see the redirected URL, as this will be server internal. For the user the base64-coded URL is the only one :-) Using CGI's and webserver configuration can do miracles.

[stoecker]

I added a redirector: ​http://josm.openstreetmap.de/josmticket?data=ZGVzY3JpcHRpb249SGFsbG8= creates a newticket and gets arguments as base64 data.

[stoecker]

P.S. The above URL sets "description=Hallo" :-)

[stoecker]

Reworked version with base64 encoding. Please try.

[avarab@…]

Ok then, you write the hacky redirect. I really don't see the point of going through this trouble to avoid a bug in a rarely used extension in its non-standard configuration though :)

Have fun.

[stoecker]

My NoScript is standard configuration. I did not change a single setting there except the site specific allow/disables. And NoScript is not a rarely used extension. It is one of the most downloaded ones (currently 397.648 downloads a week). When we don't take this into account we get corrupted hard to read bug reports.

Like NoScript there may be many other proxy firewalls, intrusion detection systems and things like that which block or encripple such requests.

[stoecker]

(In [2544]) fix #4035 - patch by avar - directly fill bug report request