Modify

Opened 12 years ago

Closed 12 years ago

#4035 closed enhancement (fixed)

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

Reported by: avarab@… Owned by: team
Priority: normal Milestone:
Component: Core Version: latest
Keywords: patch Cc:

Description

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
}}}

Attachments (3)

better-bugreport.patch (4.9 KB) - added by avarab@… 12 years ago.
Patch to make the backtrace dialog awesomer
new-bugreport.png (146.9 KB) - added by avarab@… 12 years ago.
Screenshot showing how this looks like
directurl.diff (5.1 KB) - added by stoecker 12 years ago.
Reworked version with base64 encoding. Please try.

Download all attachments as: .zip

Change History (22)

Changed 12 years ago by avarab@…

Attachment: better-bugreport.patch added

Patch to make the backtrace dialog awesomer

Changed 12 years ago by avarab@…

Attachment: new-bugreport.png added

Screenshot showing how this looks like

comment:1 Changed 12 years ago by avarab@…

Keywords: patch added
Type: defectenhancement

comment:2 Changed 12 years ago by avarab@…

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

comment:3 Changed 12 years ago by 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.


comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by 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 :-)

comment:6 Changed 12 years ago by 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?

comment:7 in reply to:  6 Changed 12 years ago by 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?

comment:8 in reply to:  4 Changed 12 years ago by 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?

comment:9 Changed 12 years ago by 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

comment:10 Changed 12 years ago by 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 :-)

comment:11 Changed 12 years ago by 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.

comment:12 in reply to:  11 Changed 12 years ago by 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.

comment:13 Changed 12 years ago by 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?

comment:14 Changed 12 years ago by 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.

comment:15 Changed 12 years ago by stoecker

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

comment:16 Changed 12 years ago by stoecker

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

Changed 12 years ago by stoecker

Attachment: directurl.diff added

Reworked version with base64 encoding. Please try.

comment:17 Changed 12 years ago by 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.

comment:18 Changed 12 years ago by 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.

comment:19 Changed 12 years ago by stoecker

Resolution: fixed
Status: newclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.