Closed Bug 482293 Opened 15 years ago Closed 15 years ago

ajax requests freezing with firebug enabled

Categories

(Core :: XML, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: rcampbell, Assigned: mrbkap)

References

()

Details

(Keywords: regression, Whiteboard: [firebug-p3])

Attachments

(1 obsolete file)

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:
http://code.google.com/p/fbug/issues/detail?id=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?
Whiteboard: [firebug-p1]
Flags: wanted1.9.0.x+
Keywords: regression
Blake, can you look at this since bug 460706 was yours? I know you own a lot of bugs for 1.9.0.8 so if there's someone you can throw this to, that'd be great.
Assignee: nobody → mrbkap
Component: Networking → XML
QA Contact: networking → xml
It would be helpful to know if bug 460796 was also committed to 1.9.1, Firebug is failing there also.
(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?
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.
(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...
(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 1.9.0.8 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+
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.
Boris please try this version of firebug:
http://getfirebug.com/releases/firebug/1.4X/firebug-1.4X.0a13.xpi
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.
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:
http://code.google.com/p/fbug/issues/detail?id=1580
Can you give me step-by-step instructions on step 2 there ("enable script debugging for the page")?
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.
Attached patch Proposed (untested) fix (obsolete) — Splinter Review
I haven't tested this yet, but I suspect this will fix this (and the leak).
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
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).

Honza
The symptom is that the reload fails to stop, correct?
The diagnosis from Firebug side is that some call blocks, correct? Which call?
(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?
(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	


Honza
waiting for firebug 1.4beta to see if this is still a problem. Marking wanted, but not blocking.
Flags: wanted1.9.1?
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.
Experiencing this same issue with 
  firefox-3.0.11-2.el5_3.x86_64
  firebug-1.3.4b2

My seemingly 100% reproducer is this page:

http://mesonet.agron.iastate.edu/sites/locate.php

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

daryl
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.
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.
Ok thanks, but how can I tell if if fails?
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....
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.
Hello.  I can't reproduce on FF 3.5 either. thanks!
The chances of this being fixed are vanishingly low.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Whiteboard: [firebug-p2] → [firebug-p3]
clearing flags on ancient bugs.
Flags: wanted1.9.1?
You need to log in before you can comment on or make changes to this bug.