ajax requests freezing with firebug enabled




9 years ago
2 years ago


(Reporter: rc, Assigned: mrbkap)



Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [firebug-p3], URL)


(1 obsolete attachment)



9 years ago
This is a regression found between February 17 and 18th on branch 1.9.0 with Firebug 1.3.3 (version on AMO) enabled. We believe this is a bug in Firefox' networking or related code.

Bug tracked in Firebug issue 1565:

From comment 3 there:
steps to reproduce:

1. open www.panoramio.com
2. open Firebug and enable console, script, and net panels
3. reload (Cmd-R)
4. select a picture in the minimap area.
5. click on the inset picture that pops up

Expected output? Actual results?
Expect to view next page showing the photo selected in step 4. Instead, we freeze with a request to ajax.googleapis.com. Clicking reload causes the page to load. Going back via browser navigation causes another freeze -- reload causes the page to load.

Symptoms visible are "Read ajax.googleapis.com" on the status bar, no updates in the net panel or console, while the page freezes. Clicking reload as stated above causes the page to complete loading.

I've verified this is a problem in current 1.9.1 nightlies as well, but our latest released version of Firebug (1.4a12 at http://getfirebug.com/releases/firebug/1.4/) is still somewhat flakey. The results are somewhat different than described above, but there are still issues when loading this page. In any case, the overlayed images don't appear to come up.
Flags: blocking1.9.0.8?


9 years ago
Whiteboard: [firebug-p1]
Flags: wanted1.9.0.x+
Keywords: regression
Blocks: 460706
Blake, can you look at this since bug 460706 was yours? I know you own a lot of bugs for so if there's someone you can throw this to, that'd be great.
Assignee: nobody → mrbkap
Component: Networking → XML
QA Contact: networking → xml

Comment 2

9 years ago
It would be helpful to know if bug 460796 was also committed to 1.9.1, Firebug is failing there also.


9 years ago
Duplicate of this bug: 480807


9 years ago
Duplicate of this bug: 482721

Comment 5

9 years ago
(In reply to comment #2)
> It would be helpful to know if bug 460796 was also committed to 1.9.1, Firebug
> is failing there also.

we verified that the code is indeed in current branch 1.9.1 and trunk nightlies. Also likely a factor in 3.1b3.
Flags: blocking1.9.1?

Comment 6

9 years ago
Does the panoramio test case fail in 3.1b3? If not then we need to get test cases from the reporters that do fail in 3.1.

Comment 7

9 years ago
(In reply to comment #2)

I miss typed the bug number its bug 460706.  Can someone who can read that bug confirm that this is a likely match to our problem?
That bug changed parser resume behavior on event loop processing: the parser is will not resume if it's still blocked on a script.

Whether that's a good match depends on what your code is doing, exactly...

Comment 9

9 years ago
(In reply to comment #6)
> Does the panoramio test case fail in 3.1b3? If not then we need to get test
> cases from the reporters that do fail in 3.1.

John, the test case doesn't fail in the same way in 3.1b3+ but it still fails. A quick run through that page and you'll see what I mean. The image overlays don't come up at all with Firebug enabled.
Would like to fix this regression, but given the schedule I don't know how realistic a fix is. mrbkap is swamped, can anyone else delve into this?
Flags: blocking1.9.0.8? → blocking1.9.0.9+

Comment 11

9 years ago
We would really like to get an assessment of this problem, at least to know that the problem is understood and can be fixed in 3.0.X.
So... I just tried to follow the steps in comment 0 in a debug 1.9.0 branch build and it dies with a fatal JS assert in jsd as soon as I either enable the panels on that page or load the page after startup:

Assertion failure: 0, at /Users/bzbarsky/mozilla/1.9-branch/mozilla/js/jsd/jsd_scpt.c:806

Are there any steps to reproduce that don't trigger that (e.g. in trunk, different site, something else)?
fwiw, that assert is in jsd_ClearExecutionHook and jsdhook is null.  The call into that is coming via jsdScript::ClearBreakpoint from firebug-service.js:1142.

Comment 14

9 years ago
Boris please try this version of firebug:
It will have the same line numbers as we have in svn.

I've never seen the assert with normal builds or my 1.9.1 symbols-only build, you must be special ;-)
You're not going to see a JS_ASSERT with a non-debug build.
We'd take a fix, but need a testcase and a good reproducible case before we can block.
Flags: blocking1.9.1?
Flags: blocking1.9.0.9+
Keywords: testcase-wanted
To be clear, if I comment out the JS_ASSERT, I can't reproduce using steps in comment 0. Neither can robcee, today.

Comment 18

9 years ago
The original case at www.panoramio.com no longer fails.

Using FF 3.0.7 and Firebug 1.3.3 I can reproduce the problem reported via:
Can you give me step-by-step instructions on step 2 there ("enable script debugging for the page")?

Comment 20

9 years ago
On each X in [Console, Script, Net] tabs in firebug, click the arrow on the tab and select 'enable X for <site>".

I was not able to reproduce with 1.3 svn, BTW. So something is amiss.

Comment 21

9 years ago
Created attachment 367922 [details] [diff] [review]
Proposed (untested) fix

I haven't tested this yet, but I suspect this will fix this (and the leak).

Comment 22

9 years ago
Comment on attachment 367922 [details] [diff] [review]
Proposed (untested) fix

This is wrong.

What's happening is that Firebug is spinning the event loop while a script is being executed and things get confused (I'm still not entirely sure of the details yet). I'm working on a different approach.
Attachment #367922 - Attachment is obsolete: true

Comment 23

9 years ago
Ah, I didn't think we could, but now I see how: we are intercepting the XHR processing which async with the script executions? But why are we different from user code? Because we can get to the cache (and deadlock) and they can't?
I was able to reproduce the problem also with http://kswt.beta.365mediaservices.com/

1. open http://kswt.beta.365mediaservices.com/
2. open Firebug and enable console, script, and net panels
3. reload

(you may need to reload the page once or twice to get the problem, which looks like indicating a cache related deadlock).


Comment 25

9 years ago
The symptom is that the reload fails to stop, correct?
The diagnosis from Firebug side is that some call blocks, correct? Which call?

Comment 26

9 years ago
(In reply to comment #24)
> I was able to reproduce the problem also with
> http://kswt.beta.365mediaservices.com/

I can't reproduce with on branches 1.4 with tabCache ff307 false. Honza did you test with 1.3?
Should this be marked as blocking bug 453978?

Comment 28

9 years ago
(In reply to comment #27)
> Should this be marked as blocking bug 453978?
No, this bug is against FF3.0.7, not FF3.1.
> I can't reproduce with on branches 1.4 with tabCache ff307 false. Honza did you
> test with 1.3?
I am also not able to reproduce it using http://kswt.beta.365mediaservices.com/ 

But, I have contacted the guy who reported the problem with www.panoramio.com. He still sees the problem. And I was also able to reproduce the problem according to the following steps.

My configuration:
Firebug 1.0.4 (tabCache ff307 set to false)
Firefox 3.0.7

1. Enable monitor for www.panoramio.com

2. Browse to the homepage

3. Click on the first link to a destination under the main image before where it says ‘… more cool places in Panoramio…’ (these change with every reload)

4. My browser stops and the green progress bar at the bottom of Firefox shows 90% completed but goes no further. Notice that this worked for me the first time (files are *not* in the FF cache). I had to click the back button and 
click on the first destination link again.

5. Try the same thing with Firebug disabled and there are no problems.

If I break Firefox process while the progress shows 90% I see following stack trace:

 	user32.dll!_NtUserWaitMessage@0()  + 0xc bytes	
>	xul.dll!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=0x00000001)  Line 151 + 0x11 bytes	C++
 	xul.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x00c71f88, int mayWait=0x00000001, unsigned int recursionDepth=0x00000000)  Line 296 + 0xf bytes	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait=0x00000001, int * result=0x0012f888)  Line 500	C++
 	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00c71f88, int mayWait=0x00000001)  Line 227 + 0x16 bytes	C++
 	xul.dll!nsBaseAppShell::Run()  Line 170 + 0xb bytes	C++
 	xul.dll!nsAppStartup::Run()  Line 181 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=0x00000004, char * * argv=0x0064ee38, const nsXREAppData * aAppData=0x0064f2c8)  Line 3193 + 0x25 bytes	C++
 	firefox.exe!NS_internal_main(int argc=0x00000004, char * * argv=0x0064ee38)  Line 158 + 0x12 bytes	C++
 	firefox.exe!wmain(int argc=0x00000004, wchar_t * * argv=0x006495d0)  Line 87 + 0xd bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 579 + 0x17 bytes	C
 	kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes	


Comment 30

8 years ago
waiting for firebug 1.4beta to see if this is still a problem. Marking wanted, but not blocking.
Flags: wanted1.9.1?

Comment 31

8 years ago
At this point it looks like this will not be fixed, so we should not have it on [firebug-p1]
Whiteboard: [firebug-p1] → [firebug-p2]
To be clear, the steps in comment 29 did NOT reproduce the bug for me.

Comment 33

8 years ago
Experiencing this same issue with 

My seemingly 100% reproducer is this page:


A shift-reload will always get the page to load correctly.


Comment 34

8 years ago
But the question isn't "how to get the page to load correctly". The problem here is "how to reproduce this problem". If I load the URL above, it works fine. So how can we cause the bug to appear, obviously and clearly 100% of the time. Then we can fix it.

Comment 35

8 years ago
The page will load the first time you visit the page.  The problem is the second time you access the page.  With the above example, try clicking on 'GIS' in the top banner and then click on 'Info' to get back to the same page.  That will fail each time for me.

Comment 36

8 years ago
Ok thanks, but how can I tell if if fails?

Comment 37

8 years ago
The progress bar will get to about 90%,
The status bar will say 'Waiting for gg.google.com'
The page will never fully visually appear.

Sorry that I am not much more help on this....

Comment 38

8 years ago
Thanks Daryl, I just have one more request. I tested your page with Firebug 1.5a6 and Firefox 3.5. I did not see the problem. So there are two possibilities: The problem does not occur in FF 3.5 (which goes live tomorrow) or we are not able to reproduce it for some reason. If you can try it with FF 3.5, that would help.

Comment 39

8 years ago
Hello.  I can't reproduce on FF 3.5 either. thanks!

Comment 40

8 years ago
The chances of this being fixed are vanishingly low.
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
Whiteboard: [firebug-p2] → [firebug-p3]

Comment 41

6 years ago
clearing flags on ancient bugs.
Flags: wanted1.9.1?
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.