[OWASP-WEBSCARAB] WebScarab 20060621-003 notes
rogan at dawes.za.net
Sun Jun 25 11:28:21 EDT 2006
Andrew van der Stock wrote:
> Hi Rogan (and everyone),
> I have tried out the latest version of WebScarab, and I've got some
> notes for you. :)
GREAT!! FEEDBACK - I LOVE IT!!
> BTW, I like this version better than the earlier versions. I'm seriously
> going to try and become an ex-Paros user, but I need it to be relatively
> easy to work with. Paros had a nice learning curve, and I think with by
> bringing the WebScarab UI back into line with common UI guidelines, I
> think a easy to learn but deep interface is possible.
Excellent. All feedback is much appreciated.
> Palette - the palette is black on MacOS X. See screen shot.
> I don't know how to fix that, but if you like, I can find out.
Yes, this seems to be some kind of bug in MacOS's implementation of
JDestopPane. It has been quite difficult for me to debug, not having
access to a Mac. However, the point is moot, I think. I am actually
planning to move back to the TabbedPane interface from early Webscarab days.
This is partially to address your problem, but also to address the issue
that we are getting more and more plugins in WebScarab, which are using
up too much horizontal space in the toolbar, and running off the edge of
> Memory leaks - I will find out from my mates in the J2EE room at work
> how they diagnose memory leaks. I'm sure you're already working on it.
Well, I have a pretty good idea where it is - if you open up a
conversation window with a large response in it (e.g. a downloaded jar,
or doc, or something), and then close it, the memory used by the window
is not reclaimed. It is very easy to demonstrate now that I have added
the heap monitor widget ;-)
I'm just not sure what the best way to deal with the problem is . . . :-(
This is certainly a major culprit, which is not to say that others do
not exist, of course . . .
> Message log - Once the message log is clicked, it cannot be closed. Why?
Well, it should be minimizable - in fact, what you are seeing as black
blocks in your macOs display are the minimized windows representing the
various plugins. But the message window should always be available, I
think, so there is not really any point in closing it.
> Menu bars
> In MacOS X, a small amount of repackaging (Stephen De Vries knows
> exactly how) allows the menu bar to move to the Apple menu without any
> code changes. This would be great for MacOS X users as it gets us ~ 40
> vertical pixels back, which on most of the widescreen laptops is
> absolutely essential.
Ok, I think this is just a packaging issue as you say. However, not
having access to a Mac means that I can't make the packages my self, and
am dependent on others to do so for me. Stephen has volunteered to do
this for WebScarab, so I'm hopeful that new packages will be available soon.
> Tool buttons
> Some of the buttons are preferences. Some are tools. Some are views. I'd
> suggest only "verbs"=actions / tools go across the top. The other things
> should be in the menus. Search for example, should just be a text entry
> box with a "Search" button.
Well, they are all implemented as plugins. So it is basically the case
that I create the Summary and Message windows, and then each of the
other buttons is created to represent a different plugin. But yes, you
are right that this could be reworked a lot.
> Pull down menus
> These should be constrained to be a certain width wide at maximum. I
> have a screen which is 1400 pixels wide. No other application has near
> 1400 pixel wide pull down menus.
Are you talking about menus or comboboxes? I know that the comboboxes
are pretty wide, but it makes sense in a way, since the conversations
summary (id + method + URL + status) can actually take up a lot of space
. . .
> Message log
> This produces a secondary window which is not properly placed on the
> screen. It looks like it is part of the lower pane of the underlying
> screen. It might be best to make this more of a dialog.
It is a free floating JInternalPane. You can drag it around and resize
it, just as you can with any of the other plugin windows.
> Tools menu
> Has a mixture of options / preferences, and tools. Should be divided
> into a clear delineation - the Windows, KDE, Gnome, Java, and Mac UI
> guidelines all suggest that preferences are in the one area.
Makes sense. I'll look into that.
> Tools -> Scripted events
> Has two tree views, but without any nodes to populate either tree, you
> can't activate the tree and see the tree nodes. The tree metaphor could
> very well be the wrong approach here; maybe a left pane for enable and
> right hand pane is for the properties of the item being selected.
Yes, this doesn't work very well. It is pretty powerful, but certainly
not intuitive. However, you should at least see tree nodes for a variety
of plugins, Framework, Proxy, etc, and these should be expandable. e.g.
Proxy has "Connection received", "intercept request" and "intercept
response" hooks, that can have scripts attached to them. Do you not see
> Manual Request - this screen requires a very big window. On my G4
> laptop, it's not big enough. Might I suggest that you use Request and
> Response on two different pages, either as a master tab? Parsed / raw /
> hex is a radio button combo anyway - not a tab.
Interesting. It worked fine on my old Dell, at 1024*768. A bit squashed,
but still usable. I don't like the idea of separating request and
response onto separate tabs, so that you can't see both at once. How do
you like the idea of putting them side by side? To see what that would
look like, open a conversation window, click in one of the fields in the
request or response, and press Ctrl-T. This will toggle between a
horizontal and vertical split layout. This won't work in the Manual
Request, but it could easily be added if people like it.
> That's enough for tonight - I need to do some work before getting to
> work tomorrow.
Thanks a lot for the feedback. I'll work through it, and post some
interim solutions to the list for feedback from members.
> What's the best method for dealing with this - should I check out a copy
> in Eclipse and hack away at the issues? What do you use to code with?
I've been using NetBeans for hacking on the old version of WebScarab,
primarily because it had the GUI builder. In the new version of
Webscarab (NG), I'm using Eclipse, so I won't be fussy about whichever
The EASIEST way to get a copy of the source is to use the tarball on my
website, which is automatically updated whenever I check something in to
the GIT repository.
The ideal way to gt a copy of the source is to download Git
(http://git.or.cz), and clone it:
$ git clone http://dawes.za.net/rogan/webscarab/webscarab.git/
You can keep up to date with:
$ git pull
More information about the Owasp-webscarab