Firebug 1.5 Breakpoints paper submitted to WWW 2010

[John J Barton]

Our paper on breakpoints and a link to the demo page:
http://blog.getfirebug.com/2009/11/03/dynamic-and-graphical-web-page-breakpoints/

jjb

[Prefontim]

Break on Next is useless in all of my attempts to use it, because
there is always at least one script in one of the tabs in my browser
which is using setTimeout(). It will always stop for this timer, so
that i can't set it on anything else.

On Nov 4, 12:58 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Our paper on breakpoints and a link to the demo page:http://blog.getfirebug.com/2009/11/03/dynamic-and-graphical-web-page-...
>
> jjb

[John J Barton]

On Nov 4, 7:44 am, Prefontim <Prefon...@hotmail.com> wrote:
> Break on Next is useless in all of my attempts to use it, because
> there is always at least one script in one of the tabs in my browser
> which is using setTimeout().  It will always stop for this timer, so
> that i can't set it on anything else.

I guess you mean "break on next in the Script" panel, the 1.4 feature?

This sounds like a bug: you are setting break on next in page
"foo.html" and the break is occurring in a JS call in page "bar.html"?
I wish we had a test showing this behavior.
jjb

[Les]

I can provide a test showing this behavior:

1. Go here: http://www.officemax.com/
2. Click Break on Next
3. You will see that almost immediately the debugger stop in a
function function br_indomain_loop()

This function has a timer that wakes up some code every 1000ms, so it
will break inside this loop.

There should be a way for Break on Next to ignore timers.

[John J Barton]

Ok, but this is not what I understood from Prefontim. I mean, "break
on next" worked as designed, but of course you want another design I
understand.
jjb

[Prefontim]

If i set break on next on foo.html, but have a timer in bar.html, the
the break on next will stop on the timer in bar.html, so this is a
bug.

It would be nice to also have a 'ignore timers' feature, so it won't
keep stopping on these timers.

[Don Dwiggins]

John J Barton wrote:
> Our paper on breakpoints and a link to the demo page:
> http://blog.getfirebug.com/2009/11/03/dynamic-and-graphical-web-page-breakpoints/

I'm truly impressed. I've been working with FF3.0.x and FB 1.4x; this
is enough to make me upgrade to FF3.5 to get the new features.

One enhancement occurs to me:

IIUC, some of the new breakpoints can't be set until after an error
occurs, or after an XHR has completed, etc., implying that the page must
be reloaded to cause the breakpoints to be hit. I can imagine
situations where this might be at least bothersome. For example,
perhaps the operation so far has resulted in a database change that will
cause the next reload to take a different execution path; in this case,
it'll take some time to restore the context to ensure that the same
condition will recur, and in extemis, might involve restarting the
browser. Or, perhaps it's late in the day, and I'm getting tired, and a
mysterious problem arises; I don't have time to pursue it, but I'd like
to set the breakpoints before I shut down and have them set tomorrow
morning when I start from fresh.

My suggestion would be to offer a button or menu item to script out the
current breakpoint set to a file, maybe in XML or JSON format, and a
complementary one to load the file to set the breakpoints. If the
format isn't too arcane, the user might be able to edit the file to
change or create new breakpoints.

FWIW,
--
Don Dwiggins
Advanced Publishing Technology

[Nicolas Hatier]

An option to ignore mouseover/move/out events for Break On Next would be very helpful too.

NH

Prefontim wrote:

--

You received this message because you are subscribed to the Google Groups "Firebug" group.
To post to this group, send email to fir...@googlegroups.com.
To unsubscribe from this group, send email to firebug+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/firebug?hl=en.


  

[John J Barton]

I'm looking into an alternative model for these kinds of cases. The
"break on next except not on mouse over not on mouse out not on
setTimeout noto setInterval" seems like problem.

jjb

[Mike Ratcliffe]

I am not sure about whether it would be possible, but an option to
listen for certain events might be a good idea. The pause button could
have a dropdown ... "Break on:" mousemove, keyup, settimeout,
click ... I guess the problem is that the list would be big :o/

Actually, the list 'aint that big:
anyevent, oncopy, oncut, onpaste, onbeforeunload, onblur, onchange,
onclick, oncontextmenu, ondblclick, onfocus, onkeydown, onkeypress,
onkeyup, onmousedown, onmousemove, onmouseout, onmouseover, onmouseup,
onresize, onscroll, ontimeout, onInterval

But I am sure you already have things in mind for this.