When run with script debugger and console enabled, and click on
testBug(), it works fine.
However, when you place a breakpoint on line 16 it fails (strings do
not match)
To further isolate the bug, I built the object a different way -
noBugHere(), if you place a breakpoint on line 31, it does not fail.
Can anyone confirm this bug?
Or is it just me?
Application: Firefox 3.0 (2008060309)
Operating System: Linux (x86-gcc3)
- Adblock Filterset.G Updater 0.3.1.3
- Adblock Plus 0.7.5.5
- CustomizeGoogle 0.72
- Delicious Bookmarks 2.0.72
- EditCSS 0.3.7
- Extension List Dumper 1.14.1
- Firebug 1.2.0b6
- Google Notebook 1.0.0.20
- Google Web Comments 1.4.20070529.0
(Disabled, Incompatible)
- Greasemonkey 0.8.20080609.0
- HttpFox 0.8.2
- iMacros for Firefox 6.0.5.4
(Disabled)
- It's All Text! 0.8.5
- Line Marker 2.0.2008040702
(Disabled)
- Live HTTP headers 0.14
- MeasureIt 0.3.8
- NoScript 1.7.7
- SQLite Manager 0.3.4
- Tamper Data 10.0.4
- Ubuntu Firefox Modifications 0.5
- Vimperator 1.1
(Disabled)
- Xdebug Helper 0.3
- YSlow 0.9.5b2
(Disabled)
> I've managed to reproduce a bug that I've been having while debugging
> with 1.2.0b6 in Firefox 3.0 on Linux (I admit to having not tried it
> on Windows)
> When run with script debugger and console enabled, and click on
> testBug(), it works fine.
> However, when you place a breakpoint on line 16 it fails (strings do
> not match)
> To further isolate the bug, I built the object a different way -
> noBugHere(), if you place a breakpoint on line 31, it does not fail.
> Can anyone confirm this bug?
> Or is it just me?
> Application: Firefox 3.0 (2008060309)
> Operating System: Linux (x86-gcc3)
> I do get different results depending on whether the debugger breaks or
> not. That can't be a good thing.
> If I break at line 16 and put
> aObject.aString === "Hello World"
> in the Watch expression it says "true". It continues to say true when
> I single step.
> If I set a breakpoint on 19, stop at 16, then Go, I break at 19 with
> "true".
> This suggests that the test is ok, but the control flow is broken. Can
> you try it with more lines of code in the if /else blocks?
> John.
> On Jul 21, 7:03 pm, Freman <fre...@gmail.com> wrote:
> > G'day there.
> > I've managed to reproduce a bug that I've been having while debugging
> > with 1.2.0b6 in Firefox 3.0 on Linux (I admit to having not tried it
> > on Windows)
> > When run with script debugger and console enabled, and click on
> > testBug(), it works fine.
> > However, when you place a breakpoint on line 16 it fails (strings do
> > not match)
> > To further isolate the bug, I built the object a different way -
> > noBugHere(), if you place a breakpoint on line 31, it does not fail.
> A break on line 16 still results in a true test.
> A break on line 17 results in a false test while line 22 still returns
> true.
> Is this about the time I make an official bug report?
> On Jul 22, 3:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > I do get different results depending on whether the debugger breaks or
> > not. That can't be a good thing.
> > If I break at line 16 and put
> > aObject.aString === "Hello World"
> > in the Watch expression it says "true". It continues to say true when
> > I single step.
> > If I set a breakpoint on 19, stop at 16, then Go, I break at 19 with
> > "true".
> > This suggests that the test is ok, but the control flow is broken. Can
> > you try it with more lines of code in the if /else blocks?
> > John.
> > On Jul 21, 7:03 pm, Freman <fre...@gmail.com> wrote:
> > > G'day there.
> > > I've managed to reproduce a bug that I've been having while debugging
> > > with 1.2.0b6 in Firefox 3.0 on Linux (I admit to having not tried it
> > > on Windows)
> > > When run with script debugger and console enabled, and click on
> > > testBug(), it works fine.
> > > However, when you place a breakpoint on line 16 it fails (strings do
> > > not match)
> > > To further isolate the bug, I built the object a different way -
> > > noBugHere(), if you place a breakpoint on line 31, it does not fail.
> > A break on line 16 still results in a true test.
> > A break on line 17 results in a false test while line 22 still returns
> > true.
> > Is this about the time I make an official bug report?
> > On Jul 22, 3:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > I do get different results depending on whether the debugger breaks or
> > > not. That can't be a good thing.
> > > If I break at line 16 and put
> > > aObject.aString === "Hello World"
> > > in the Watch expression it says "true". It continues to say true when
> > > I single step.
> > > If I set a breakpoint on 19, stop at 16, then Go, I break at 19 with
> > > "true".
> > > This suggests that the test is ok, but the control flow is broken. Can
> > > you try it with more lines of code in the if /else blocks?
> > > > I've managed to reproduce a bug that I've been having while debugging
> > > > with 1.2.0b6 in Firefox 3.0 on Linux (I admit to having not tried it
> > > > on Windows)
> > > > When run with script debugger and console enabled, and click on
> > > > testBug(), it works fine.
> > > > However, when you place a breakpoint on line 16 it fails (strings do
> > > > not match)
> > > > To further isolate the bug, I built the object a different way -
> > > > noBugHere(), if you place a breakpoint on line 31, it does not fail.
Please post your example to http://code.google.com/p/fbug/issues/list.
Ideally add your comments above the buttons (and make them buttons so
we don't have to guess ;-). Then we'll take this up with Firefox
folks. My guess now, based on your excellent bug/noBug isolation is a
problem caused by FF3 security mechanism but I'm just guessing...
On Jul 23, 3:45 pm, Freman <fre...@gmail.com> wrote:
> > > A break on line 16 still results in a true test.
> > > A break on line 17 results in a false test while line 22 still returns
> > > true.
> > > Is this about the time I make an official bug report?
> > > On Jul 22, 3:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > I do get different results depending on whether the debugger breaks or
> > > > not. That can't be a good thing.
> > > > If I break at line 16 and put
> > > > aObject.aString === "Hello World"
> > > > in the Watch expression it says "true". It continues to say true when
> > > > I single step.
> > > > If I set a breakpoint on 19, stop at 16, then Go, I break at 19 with
> > > > "true".
> > > > This suggests that the test is ok, but the control flow is broken. Can
> > > > you try it with more lines of code in the if /else blocks?
> > > > > I've managed to reproduce a bug that I've been having while debugging
> > > > > with 1.2.0b6 in Firefox 3.0 on Linux (I admit to having not tried it
> > > > > on Windows)
> > > > > When run with script debugger and console enabled, and click on
> > > > > testBug(), it works fine.
> > > > > However, when you place a breakpoint on line 16 it fails (strings do
> > > > > not match)
> > > > > To further isolate the bug, I built the object a different way -
> > > > > noBugHere(), if you place a breakpoint on line 31, it does not fail.
In my experience, it is just the line-indicator that is playing up!
In many "if" statements, if the result is false, the indicator jumps
to the last of the statements of depending on the if-condition.
Try to have a function-call as the last statment and step-through. You
will find, that the function is NOT called.
The "current-statement"-indicator seems to have a life of its own.
It is shown on lines never stepped through, etc.
On Jul 24, 12:45 am, Freman <fre...@gmail.com> wrote:
> > > A break on line 16 still results in a true test.
> > > A break on line 17 results in a false test while line 22 still returns
> > > true.
> > > Is this about the time I make an official bug report?
> > > On Jul 22, 3:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > I do get different results depending on whether the debugger breaks or
> > > > not. That can't be a good thing.
> > > > If I break at line 16 and put
> > > > aObject.aString === "Hello World"
> > > > in the Watch expression it says "true". It continues to say true when
> > > > I single step.
> > > > If I set a breakpoint on 19, stop at 16, then Go, I break at 19 with
> > > > "true".
> > > > This suggests that the test is ok, but the control flow is broken. Can
> > > > you try it with more lines of code in the if /else blocks?
> > > > > I've managed to reproduce a bug that I've been having while debugging
> > > > > with 1.2.0b6 in Firefox 3.0 on Linux (I admit to having not tried it
> > > > > on Windows)
> > > > > When run with script debugger and console enabled, and click on
> > > > > testBug(), it works fine.
> > > > > However, when you place a breakpoint on line 16 it fails (strings do
> > > > > not match)
> > > > > To further isolate the bug, I built the object a different way -
> > > > > noBugHere(), if you place a breakpoint on line 31, it does not fail.
> In my experience, it is just the line-indicator that is playing up!
> In many "if" statements, if the result is false, the indicator jumps
> to the last of the statements of depending on the if-condition.
> Try to have a function-call as the last statment and step-through. You
> will find, that the function is NOT called.
> The "current-statement"-indicator seems to have a life of its own.
> It is shown on lines never stepped through, etc.
> On Jul 24, 12:45 am, Freman <fre...@gmail.com> wrote:
> > > > A break on line 16 still results in a true test.
> > > > A break on line 17 results in a false test while line 22 still returns
> > > > true.
> > > > Is this about the time I make an official bug report?
> > > > On Jul 22, 3:07 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > > I do get different results depending on whether the debugger breaks or
> > > > > not. That can't be a good thing.
> > > > > If I break at line 16 and put
> > > > > aObject.aString === "Hello World"
> > > > > in the Watch expression it says "true". It continues to say true when
> > > > > I single step.
> > > > > If I set a breakpoint on 19, stop at 16, then Go, I break at 19 with
> > > > > "true".
> > > > > This suggests that the test is ok, but the control flow is broken. Can
> > > > > you try it with more lines of code in the if /else blocks?
> > > > > > I've managed to reproduce a bug that I've been having while debugging
> > > > > > with 1.2.0b6 in Firefox 3.0 on Linux (I admit to having not tried it
> > > > > > on Windows)
> > > > > > When run with script debugger and console enabled, and click on
> > > > > > testBug(), it works fine.
> > > > > > However, when you place a breakpoint on line 16 it fails (strings do
> > > > > > not match)
> > > > > > To further isolate the bug, I built the object a different way -
> > > > > > noBugHere(), if you place a breakpoint on line 31, it does not fail.
