A little Javascript / DOM reversing exercise [Archive]

View Full Version : A little Javascript / DOM reversing exercise

dELTA

March 16th, 2010, 20:40

Hi all,

I have a little interesting reversing exercise in the field of Javascript/DOM for you. It might be very easy for those a little more experienced in this field, but it's confusing enough to annoy me anyway, so in that case, please enlighten me.

A short(ish) background story is that I'm trying to "refill" a pay-card mobile phone with credits, and since a couple of days, the phone company in question has started to demand that customers register an account on their website to be able to do this. So, I think to myself, "that's annoying, but sure, whatever".

Then comes the funny thing. This company (one of Sweden's biggest mobile phone telecom companies...) has made such a huge screw-up on the website, that it is impossible for customers to register these new required accounts, and they haven't managed to fix the stupid thing for two whole days, just asking people to "hold on" with refilling their cards while they are working to resolve this problem, when you call their support... Errr, can you imagine the amounts of money they are losing for every hour their worthless web consultants are sleeping on the job...?

So, anyway, the apparent problem (or at least first problem) seems to be that the stupid application form uses some kind of Javascript client side checking, which in turn has some kind of bug making it reject any and all suggestions for passwords, no matter how secure of compliant with their guidelines. The password boxes just turn red, with a big stop sign next to them, as soon as you type anything in them, and the submit button for the form consequently won't work.

So, I think to myself, ok, I won't let some stupid bug in some crappy client side format validation code stop me, I'll just take a look at the code and bypass it (or even fix their stupid bug for them...).

Then comes the problem. I cannot seem to find any friggin' event handling code whatsoever connected to those textboxes, and still, they obviously actively react to me typing in them, WTF?!

So, the exercise is as simple as:
Exactly how can I locate the Javascript event handling code for these text box controls, using any tool or technique?

No event handling code is defined directly in the HTML code for the form, so I assume it must be assigned dynamically by some other Javascript code somewhere.

I have used both the Firebug debugger and DOM inspector to try to find any event code connected to the controls, without any useful results. I have also searched for any reference to e.g. the "password2" text box, in all script code connected to the page (as reported by both Firebug and the "Web Developer" Firefox extension), but still nothing.

There is some packed Javascript code in the connected script file "http://www.comviq.se/script/s_code.js" though, but my main goal is to dynamically be able to resolve the event code connected to the text boxes, not necessarily to locate the code that assigns it. That's normally the beauty of DHTML, i.e. no matter how people try to obfuscate their HTML code, you can easily "dump" it once it has been "unpacked" for viewing in the browser. That's the exact kind of thing I would like to do for the Javascript event code assigned to these text boxes, and I really think it should be possible, or isn't it, really?

You will find the mystery form at the following URL:

http://www.comviq.se/tanka.html

Search this page for the string "skapa ett h", and click the link that makes up the word starting with the "h" in the end of that string (it contains a Swedish letter that may not be available on your keyboards ("här", which is why I don't mention the entire word in the search string), and the application form will show up, having the title "Skapa konto".

The two password text boxes have the following titles:

"Lösenord (minst 6 tecken varav en bokstav och en siffra)" [= "Password (at least 6 characters, out if which one letter and one number)"]

and

"Lösenord igen" [= "Password again"]

And again, the single objective of this exercise is to find the Javascript code that is assigned as an event handler for these textboxes (or any other DOM object), e.g. the code that makes them red and shows the stop sign when you type something in them - using any tool or technique.

Any and all help with this is much appreciated!

PS.
Yes, you can easily bypass the entire client-side checking by forcing the form to submit manually with some injected javascript code or whatever, but that's not the point. What caught my interest was that I was not able to locate the event handling code, and it annoys the hell out of me, so please let's just focus on that.

PS2.
Even if they have fixed the problem (that makes the password boxes red whatever you type) when you take a look at the page, it doesn't matter for this exercise, I would still very much like to know how to locate that event handling code, no matter my original reason for stumbling upon this problem.

dELTA

March 16th, 2010, 21:34

Some more googling reveals that this was apparently completely/theoretically impossible to do before Firefox 3.6, but that APIs on the browser level was introduced to support such enumeration in Firefox 3.6, and that there is a very new (still in beta) Firebug plugin called EventBug (http://www.softwareishard.com/blog/category/eventbug/) which will assist with making use of these APIs in Firebug.

Seems like I at least had some good timing with this little reversing exercise, but the problem sadly still remains for the page in question though, since for some reason the EventBug plugin still fails to get hold of the source code for the event handler (which it says it should be able to do), but rather only shows some uninteresting information about it...

Any further ideas / tips?

Kayaker

March 16th, 2010, 23:02



There's this (open &quot;här&quot; link in new window for source), but the password fields still turn red when you enter something into them (as long as you maintain the modal window association with the parent, and not open the link in a new window).








Is there an error in the regex?





password: { required: true, minlength: 4, regex: &quot;^.*(?=.{6,})(?=.*[a-zA-Z])(?=.*[0-9]).*$&quot; }





Since I can't generally read this crap without help, my old buddy RegexBuddy says this means...





<div style="margin:20px; margin-top:5px; "><div class="smallfont" style="margin-bottom:2px">Quote:</div><table cellpadding="6" cellspacing="0" border="1" width="90%"><tr><td class="alt2" style="border:1px inset"><i>Assert position at the beginning of the string


Match any single character that is not a line break character


Between zero and unlimited times, as many times as possible, giving back as needed (greedy)


Assert that the regex below can be matched, starting at this position (positive lookahead)


Match any single character that is not a line break character


Between 6 and unlimited times, as many times as possible, giving back as needed (greedy)


Assert that the regex below can be matched, starting at this position (positive lookahead)


Match any single character that is not a line break character


Between zero and unlimited times, as many times as possible, giving back as needed (greedy)


Match a single character present in the list below


A character in the range between &quot;a&quot; and &quot;z&quot;


A character in the range between &quot;A&quot; and &quot;Z&quot;


Assert that the regex below can be matched, starting at this position (positive lookahead)


Match any single character that is not a line break character


Between zero and unlimited times, as many times as possible, giving back as needed (greedy)


Match a single character in the range between &quot;0&quot; and &quot;9&quot;


Match any single character that is not a line break character


Between zero and unlimited times, as many times as possible, giving back as needed (greedy)


Assert position at the end of the string (or before the line break at the end of the string, if any)</i></td></tr></table></div>
















&lt;script type=&quot;text/javascript&quot;&gt;


$(document).ready(function(){


    $(&quot;#phoneNumber&quot.focus();


    $(&quot;#phoneNumber&quot.mask(&quot;9999999999&quot;


    $(&quot;#year&quot.mask(&quot;9999&quot;


    $(&quot;#month&quot.mask(&quot;99&quot;


    $(&quot;#day&quot.mask(&quot;99&quot;


});


$(&quot;#register-button&quot.click(function() {


    $(&quot;#register-form&quot.submit();


    return false;


});


$.validator.addMethod(


        &quot;regex&quot;,


        function(value, element, regexp) {


            var check = false;


            var re = new RegExp(regexp);


            return this.optional(element) || re.test(value);


        },


        &quot;Please check your input.&quot;


);


$(&quot;#register-form&quot.validate({


    rules: {


        phoneNumber: { required: true, regex: &quot;07(\\d){8}&quot; },


        password: { required: true, minlength: 4, regex: &quot;^.*(?=.{6,})(?=.*[a-zA-Z])(?=.*[0-9]).*$&quot; },


        password2: { required: true, minlength: 4, regex: &quot;^.*(?=.{6,})(?=.*[a-zA-Z])(?=.*[0-9]).*$&quot;, equalTo: &quot;#password&quot; },


        email: { required: true, email: true },


        email2: { equalTo: &quot;#email&quot; },


        year: { required: true, digits: true, minlength: 4, maxlength: 4, min: 1900, max: new Date().getFullYear() },


        month: { required: true, digits: true, minlength: 2, maxlength: 2, min: 1, max: 12 },


        day: { required: true, digits: true, minlength: 2, maxlength: 2, min: 1, max: 31 }


    },


    errorPlacement: function(error, element) {


        element.parent().parent().addClass(&quot;error-resize&quot;    },


    success: function(label) {


      elementName = &quot;#&quot; + label.attr(&quot;for&quot;


      $(elementName).parent().parent().removeClass(&quot;error-resize&quot;


    },


    submitHandler: function() {


        var f = $(&quot;#register-form&quot;


        $(&quot;#loading-animation&quot.show();


        $.post(f.attr(&quot;action&quot, 


           f.serialize(),


           function(data) {


               $(&quot;#loading-animation&quot.hide();


               if(data.indexOf(&quot;register-error&quot != -1) {


                    if(data.indexOf(&quot;Account already exist&quot != -1) {


                      $(&quot;#account-message&quot.show();


                      $(&quot;#agreement-message&quot.hide();


                    } else if(data.indexOf(&quot;agreement&quot != -1) {


                      $(&quot;#agreement-message&quot.show();


                    } else {


                      $(&quot;#account-message&quot.show();


                      $(&quot;#agreement-message&quot.hide();


                      $(&quot;#error-message&quot.show();


                    }             


                } else {


                   $(&quot;#TB_ajaxContent&quot.html(data);


               }


           }


        ;


        return false;


    }


});


$(&quot;#tb_close_button&quot.click(function(e) {


    tb_remove();


    return false;


});


$(&quot;#register-form input&quot.keydown(function(e){


    if (e.keyCode == 13 &amp;&amp; $(&quot;#register-form&quot.validate()) {


        $(&quot;#register-form&quot.submit();


        return false;


    }


});


&lt;/script&gt;

dion

March 17th, 2010, 06:42

got the same result.

and yes. all the 3 lines (phone, pass1 and pass2) with 'regex' parameter were screwed up.

dunno about regexp, but it seems the 'regex' function declaration looks strange..

dELTA

March 17th, 2010, 08:09

Thanks for your replies!

Even though this does not solve the real exercise, it's helpful to see that code, in order not to go mad.

I have analyzed the difference in the dynamic DOM source between the scenarios of loading that "window" in it's own browser window, and loading it "AJAX style" into a DIV layer (as is done by default).

For some reason, the jQuery code that you found is completely vanished in the latter case, but for some reason left intact in the former case. And note that I'm not talking about the static source of that page (i.e. as sent over the wire from the server), but rather the dynamic DOM source, as resolved dynamically from the page DOM after having completed the page loading.

For those not much into HTML/DOM/Javascript reversing, these two types of source are very different, and the static one can always be viewed with the "View page source" option in Firefox if the page is loaded in a single static block, or captured in pieces by means of an intercept proxy if it's an AJAX style page where the page components are loaded separately with XMLHttpRequest() calls (since the static source given by the "View page source" will only show the static "base page" in that case). The dynamic DOM source on the other hand can be queried from the browser by means of debug APIs, which are being used by several useful Firefox extensions, e.g. the well-known Firebug debugger, and also e.g. another useful extension I often use, called "View Source Chart".

The problem in this case is that as long as this "window" with the form is loaded as intended (i.e. AJAX style), the jQuery script elements that contained the code you found simply aren't there in the dynamic DOM source, while they are apparently left in this very same dynamic DOM source if you open this "window" in its own browser window.

But, as mentioned in my original post above "my main goal is to dynamically be able to resolve the event code connected to the text boxes, not necessarily to locate the code that assigns it". This is for the very simple reason that if they would only have packed/obfuscated that JQuery code that you found, you would not have been able to find it that way (i.e. neither by viewing the dynamic DOM source or by viewing/intercepting the static source). That's why I want to be able to resolve the event code dynamically, after the fact (i.e. after the target has been "unpacked and loaded", just like when you dump packed x86 targets).

This is apparently not even possible in the separately opened browser window version of the code (the events don't even seem to be attached correctly to the text boxes in this case, most likely due to all the jQuery and CSS includes that are not available in this separate window), but even if it would be, it would still not be completely relevant to the core question, since if the form window would not be opened by means of a simple HTML link, but rather by means of (possibly packed) Javascript code, you would not be able to open it in that separate window in the first place (in any simple way).

The moral of the story above is that if a protector would just open that new AJAX "window" by means of packed/obfuscated Javascript code, and also pack/obfuscate the jQuery code that defines those events, we, as reversers, would be toast if we cannot resolve the event code dynamically. Being able to "handle" that situation is the entire underlying objective of this little exercise.

So, the question remains, how can we dynamically resolve/obtain the source of arbitrary event handlers of DOM objects like this on a page, and why does the EventBug plugin fail to do this on this page?

Oh, and regarding that regexp, it's actually a correct regexp in this context, even if they make some stupid/unnecessary use of lookahead quantifiers, which are practically the most incompatible feature of regular expressions between different regex implementations.

Those quantifiers should actually be supported by Javascript regexps using that syntax though, so now I'm also a little curious why this code is broken?

Dion, you mention above that you see some errors in the jQuery syntax defining the regex code, rather than in the regexps themselves? Could you possibly clarify this further? (I'm no jQuery pro)

Again, thanks a lot for your replies, and even more thanks for the ones you are about to write.

dion

March 17th, 2010, 09:25

i'm not jquery expert too

neither i am fluent in javascript. but from the declaration :

Code:

"regex",

        function(value, element, regexp) {

            var check = false;

            var re = new RegExp(regexp);

            return this.optional(element) || re.test(value);

        },

exactly 3 param, where pass2 can pass 4. and the other is, re.test(value), from which the value itself is seems always true (for all 3 line). also, where the 'check' var going in the end??

Kayaker

March 17th, 2010, 11:05

Quote:

[Originally Posted by dELTA;85661]...Firebug debugger...

The Opera Dragonfly debugger picks up the popup registration box inline javascript, but kind of hidden under the Scripts dropdown box and labelled as "Script id:1053".

Woodmann

March 17th, 2010, 20:04

I have limited knowledge of Ajax.........

I dont think it can handle more then one "submit" at a time.

Woodmann

dELTA

March 18th, 2010, 07:39

Thanks for the info Kayaker, I guess we have found a good protector trick then (for the time being anyway)...

Thanks also for the clarification dion. The only part of that code I don't know what it is is the "this.optional(element)". The problem is though that if this "regex" function returned true all the time, there shouldn't be any validation problem at all, since that should mean that the validation was "ok", hmm...?

I will try to talk to the EventBug developers and see what they have to say about it anyway.

In the meantime, the morons at the telecom company still haven't fixed their buggy code, so I bypassed it with some injected Javascript code in order to be able to continue using my phone.

But that's not the point anyway, I don't like this protector's trick, and I won't be happy until EventBug can show me all dynamically assigned DOM event handlers, so stay tuned...

Honza

March 18th, 2010, 10:35

Hi All,
dELTA reached me through email and here is my observation, related to the Eventbug extension problem.

I did following:

1) Install Firebug 1.6b8 + Eventbug 1.5b3 http://getfirebug.com/releases/eventbug/1.5/eventbug-0.1b3.xpi
http://getfirebug.com/releases/firebug/1.6X/firebug-1.6X.0a8.xpi

2) Load http://www.comviq.se/tanka.html

3) Search this page for the string "skapa ett h", and click the link that makes up the word starting with the "h" in the end of that string

4) A form appears. The important text box is labeled as "Lösenord (minst 6 tecken varav en bokstav och en siffra)"

5) Select the HTML panel in Firebug and consequently Events side panel.

6) Use the HTML inspector and select text box from #4

7) The proper <input> element is selected in the HTML panel and I see bunch of event handlers (also keyboard related) that are associated with it in the Events panel. Most of the keyboard-related events are saying "not implemented in Javascript", but there is one keydown for which I see

function () {
return typeof o !== "undefined" && !o.event.triggered ? o.event.handle.apply(arguments.callee.elem, arguments) : g;
}

So, this could be the glue you are looking for?

There is also a link that should point to the right place in the code, which doesn't work for me. So, there seems to be two problems, one is that you don't see the source of the handler and the second related to the link.

Do we have the same results?
Honza

Honza

March 18th, 2010, 11:17

Related issue report in official Firebug list:
http://code.google.com/p/fbug/issues/detail?id=2940

Honza

dELTA

March 18th, 2010, 12:36

Hi Honza, nice to have you here!

(for those who don't know, Honza is the author of the EventBug plugin)

I have now again performed the exact steps that you mention in your post, and I do not get the same results actually. The difference is that I don't get the source code (the glue code that you mention in your post) for any of the handlers.

Please see the screenshot attached to this post, for my exact results.

There is indeed one keydown handler that does not have the "(not implemented in javascript)" marker in the list in the event panel, but once you expand it, there is only a message saying "1 not implemented in javascript".

Again, please see the screenshot below, to see exactly how it looks. I can also add that the keydown handlers you see in the screenshot are all that are present in the panel list, so nothing relevant is outside of the screenshot.

Finally, there is one known difference between my setup and yours though, I'm using the last official/auto-updated version of Firebug (1.5.3), while you state above that you are using a 1.6 beta. Might that be affecting this? I will try to install that same beta a little later, and get back to you about the results anyway.

The EventBug version is the same though (even though it is a little confusingly named, you call it "1.5b3", while the addons list in Firefox lists it as "0.1b3", which is also in the filename of the xpi URL you mention in your post above, even though that URL also contains "1.5" in another part of the URL

).

Oh, and yes, I did indeed use the "Refresh" button of the Events tab, but it did not make any difference.

dELTA

March 18th, 2010, 19:24

Hi again Honza,

I have now tried it with the exact same version of everything as you (Firefox, Firebug and Eventbug), and the problem still remains exactly the same.

Please see the screenshot below (where I also moved all the relevant version info windows into a position in the screenshot, to eliminate any suspicion about my software versions).

Damn, I really hate these kind of problems, where lot of users experience a bug, but it works just fine for the developers (except for that related link issue in this case), and thus cannot be debugged easily.

Honza, could you please take a look at these screenshots of mine to see if there is any chance I may have misunderstood anything?

Also, if you have any ideas for things I could test in order to help you debug this, please just let me know, I would be more than willing to do that.

Btw, maybe you could try it yourself in a clean VMware machine or similar? As a developer of this application, I can imagine that your machine is quite an "unusual environment" test-case-wise?

Thanks for any help or comments anyway!

Honza

March 19th, 2010, 04:43

Yeah, you are right the latest Eventbug is *0.1b3*

---

After some further testing I am able to see the problem (the keydown event handler doesn't show the source, even if apparently implemented in JS).

The difference is that Firebug is off (Firebug status bar icon is grey) at the time when the page is loaded.
If Firebug is automatically activated for the page (ie FB UI opened when the page is loaded) it works for me.

Can you check these two cases on your machine?

My configuration:
Firefox 3.6
Firebug 1.5.3
Eventbug 0.1b3

Honza

Honza

March 19th, 2010, 07:19

I have fixed two bugs that could help to solve this issue, see more
http://code.google.com/p/fbug/issues/detail?id=2940#c3
(please try Eventbug 0.1b4)

Also, Eventbug is using some debugger features so, the Script panel must be enabled (since the page load as I mentioned above).

The Eventbug UI should somehow indicate the dependence on the Script panel (and inform the user if it's disabled)

Honza

dELTA

March 19th, 2010, 08:22

Confirmed!

First I tried with Eventbug 0.1b3, and your workaround did the job. Just manually start Firebug before entering the page, and it works!

I then tried the new Eventbug version 0.1b4, and there it works even without this workaround, as expected!

Great, thanks a lot!

Now I'm very much looking forward to your planned functionality of being able to directly breakpoint/step the event code in the event panel, since e.g. jQuery glue handlers like the one in this case are a real pain to debug without that capability.

Another small question related to all this: What are the alternatives if an event handler isn't implemented in Javascript, i.e. what language/code type could it otherwise typically be implemented in?

Btw, speaking of dependencies and notifications thereof, when I was messing around with installing/uninstalling the different versions of Firebug during these tests, I noticed that another Firebug plugin called FireQuery (0.7) had registered some kind of global dependency to the Firebug extension in the browser, so that Firefox warned me during the uninstall of Firebug, that this extension (i.e. FireQuery) had a dependency to Firebug and would become disabled if I performed this uninstall. Might be a nice feature for Eventbug too I guess?

Finally, I've added Eventbug to our reversing tool library (CRCETL), here:

http://www.woodmann.com/collaborative/tools/Eventbug

I cannot seem to find any suitable URL to enter as its "website" or "official homepage" though, what would you suggest there? (you can even easily edit the entry for Eventbug in the tool library yourself to add this if you like)

dELTA

March 19th, 2010, 08:51

Oh, btw, this morning I got a text message from the phone company, saying that they finally fixed this Javacode validation bug that prevented any of their customers to register accounts and refill their mobile accounts on their site now, 4-5 days later! They really should look for new web consultants...

A funny detail though was that not a single byte was changed in the jQuery code documented by Kayaker previous in this thread, so I have no idea what could have caused the validation problem in the end?

Oh, and btw, Honza, do you have any explanation for the behavior of the "disappearing javascript code" described previous in this thread (only showing in the DOM/Firebug HTML window if the form is loaded in a separate window, not when being loaded AJAX style in a DIV layer on the current page)?

Is it perhaps even a candidate for a Firebug bug report?

If not, it sure would be a fine feature suggestion for Firebug anyway, since it would make it a better debugger if it would show all Javascript code that is actually loaded/running on a page. Otherwise this trick could be used by people to hide Javascript code from Firebug (as described in more detail previously in this thread)!

Honza

March 19th, 2010, 09:19

Quote:

[Originally Posted by dELTA]Confirmed!
First I tried with Eventbug 0.1b3, and your workaround did the job. Just manually start Firebug before entering the > page, and it works!
I then tried the new Eventbug version 0.1b4, and there it works even without this workaround, as expected!
Great, thanks a lot!

Great

Quote:

[Originally Posted by dELTA]Now I'm very much looking forward to your planned functionality of being able to directly
breakpoint/step the event code in the event panel, since e.g. jQuery glue handlers like the
one in this case are a real pain to debug without that capability.

Yes, so the idea is to allow direct debugging of selected handler.
(a) I think it should be possible to create breakpoint directly within the handler's source displayed within the Events panel.
(b) This could be also somehow integrated with "Break on next" feature. See more here: http://www.softwareishard.com/blog/firebug/firebug-15-break-on-next/
E.g. right clicking on an event type and selecting a "Break on this (particular) event" could be neat.

If you have any tips/comments for this, please don't hesitate to report a new issue for it in the Firebug issue list.

Quote:

[Originally Posted by dELTA]Another small question related to all this: What are the alternatives if an event handler
isn't implemented in Javascript, i.e. what language/code type could it otherwise typically
be implemented in?

Mostly C/C++ (i.e. Firefox code). I think that Flash (action script) can also register new event handlers and in such case there would be also "not implemented in Javascript" message, but I never tried that.

Quote:

[Originally Posted by dELTA]I noticed that another Firebug plugin called FireQuery (0.7) had registered some kind of global
dependency to the Firebug extension in the browser, so that Firefox warned me during the uninstall
of Firebug, that this extension (i.e. FireQuery) had a dependency to Firebug and would become
disabled if I performed this uninstall. Might be a nice feature for Eventbug too I guess?

Good point, could you please report an issue for this so, it's not lost?

Quote:

[Originally Posted by dELTA]Finally, I've added Eventbug to our reversing tool library (CRCETL), here:
http://www.woodmann.com/collaborative/tools/Eventbug
I cannot seem to find any suitable URL to enter as its "website" or "official homepage" though,
what would you suggest there? (you can even easily edit the entry for Eventbug in the tool library
yourself to add this if you like)

I think http://getfirebug.com/releases/extensions.html#eventbug is slightly better, but I need to create a real home page for Eventbug on getfirebug.com/wiki. If you can use this link for now, it would be great and as soon as the wiki page is created I'll drop you a line.

Thanks for great cooperation, this can happen only in open source world! :-)
Honza

dELTA

March 19th, 2010, 10:38

Quote:

[Originally Posted by Honza;85699]Yes, so the idea is to allow direct debugging of selected handler.
(a) I think it should be possible to create breakpoint directly within the handler's source displayed within the Events panel.
(b) This could be also somehow integrated with "Break on next" feature. See more here: http://www.softwareishard.com/blog/firebug/firebug-15-break-on-next/
E.g. right clicking on an event type and selecting a "Break on this (particular) event" could be neat.

Sounds great to me! And sure, I'll let you know if I think of something else, absolutely.

Quote:

[Originally Posted by Honza;85699]
Quote:
[Originally Posted by dELTA]I noticed that another Firebug plugin called FireQuery (0.7) had registered some kind of global
dependency to the Firebug extension in the browser, so that Firefox warned me during the uninstall
of Firebug, that this extension (i.e. FireQuery) had a dependency to Firebug and would become
disabled if I performed this uninstall. Might be a nice feature for Eventbug too I guess?

Good point, could you please report an issue for this so, it's not lost?

Done.
http://code.google.com/p/fbug/issues/detail?id=2944
I could not find the way to post it as an "Enhancement" though (how is that done?), so it is not listed as an issue, which might not be completely optimal.

Btw, did you see my question about the "disappearing script code" in my last post above? I have now created a bug tracker issue for that one too:

http://code.google.com/p/fbug/issues/detail?id=2946

It would be very interesting to get any kind of feedback/resolution to that one too!

Finally, I found yet another bug in Firebug, in the Break On Next feature, seemingly very similar to the one you just fixed in Eventbug, and reported it here:

http://code.google.com/p/fbug/issues/detail?id=2945

Oh, and thank you, for your assistance and for some really great tools.