Last Comment Bug 482293 - ajax requests freezing with firebug enabled
: ajax requests freezing with firebug enabled
Status: RESOLVED WONTFIX
[firebug-p3]
: regression
Product: Core
Classification: Components
Component: XML (show other bugs)
: Trunk
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap) (please use needinfo!)
:
Mentors:
http://www.panoramio.com/
: 480807 482721 (view as bug list)
Depends on:
Blocks: 460706
  Show dependency treegraph
 
Reported: 2009-03-09 12:08 PDT by Rob Campbell [:rc] (:robcee)
Modified: 2015-10-16 11:50 PDT (History)
22 users (show)
dveditz: wanted1.9.0.x+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposed (untested) fix (9.98 KB, patch)
2009-03-17 17:16 PDT, Blake Kaplan (:mrbkap) (please use needinfo!)
no flags Details | Diff | Review

Description Rob Campbell [:rc] (:robcee) 2009-03-09 12:08:35 PDT
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.
Comment 1 Samuel Sidler (old account; do not CC) 2009-03-11 18:46:41 PDT
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.
Comment 2 John J. Barton 2009-03-15 20:49:18 PDT
It would be helpful to know if bug 460796 was also committed to 1.9.1, Firebug is failing there also.
Comment 3 John J. Barton 2009-03-15 20:53:46 PDT
*** Bug 480807 has been marked as a duplicate of this bug. ***
Comment 4 John J. Barton 2009-03-15 20:55:58 PDT
*** Bug 482721 has been marked as a duplicate of this bug. ***
Comment 5 Rob Campbell [:rc] (:robcee) 2009-03-16 05:08:32 PDT
(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.
Comment 6 John J. Barton 2009-03-16 07:18:21 PDT
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 John J. Barton 2009-03-16 11:48:46 PDT
(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?
Comment 8 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-03-16 11:59:02 PDT
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 Rob Campbell [:rc] (:robcee) 2009-03-16 13:30:45 PDT
(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.
Comment 10 Daniel Veditz [:dveditz] 2009-03-16 14:46:28 PDT
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?
Comment 11 John J. Barton 2009-03-16 14:55:56 PDT
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.
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-03-17 11:27:29 PDT
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)?
Comment 13 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-03-17 11:30:46 PDT
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 John J. Barton 2009-03-17 11:47:14 PDT
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 ;-)
Comment 15 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-03-17 12:05:21 PDT
You're not going to see a JS_ASSERT with a non-debug build.
Comment 16 Mike Beltzner [:beltzner, not reading bugmail] 2009-03-17 12:09:53 PDT
We'd take a fix, but need a testcase and a good reproducible case before we can block.
Comment 17 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-03-17 12:14:03 PDT
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 John J. Barton 2009-03-17 13:25:28 PDT
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
Comment 19 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-03-17 13:54:55 PDT
Can you give me step-by-step instructions on step 2 there ("enable script debugging for the page")?
Comment 20 John J. Barton 2009-03-17 14:00:26 PDT
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 Blake Kaplan (:mrbkap) (please use needinfo!) 2009-03-17 17:16:22 PDT
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 Blake Kaplan (:mrbkap) (please use needinfo!) 2009-03-17 20:28:30 PDT
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.
Comment 23 John J. Barton 2009-03-17 21:36:17 PDT
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?
Comment 24 Jan Honza Odvarko [:Honza] 2009-03-18 08:19:19 PDT
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
Comment 25 John J. Barton 2009-03-18 08:29:53 PDT
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 John J. Barton 2009-03-19 14:01:32 PDT
(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?
Comment 27 Ashley Bischoff (blog at handcoding.com) 2009-03-20 10:45:37 PDT
Should this be marked as blocking bug 453978?
Comment 28 John J. Barton 2009-03-20 10:49:53 PDT
(In reply to comment #27)
> Should this be marked as blocking bug 453978?
No, this bug is against FF3.0.7, not FF3.1.
Comment 29 Jan Honza Odvarko [:Honza] 2009-03-23 08:25:27 PDT
> 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
Comment 30 Rob Campbell [:rc] (:robcee) 2009-06-02 10:48:18 PDT
waiting for firebug 1.4beta to see if this is still a problem. Marking wanted, but not blocking.
Comment 31 John J. Barton 2009-06-12 08:54:29 PDT
At this point it looks like this will not be fixed, so we should not have it on [firebug-p1]
Comment 32 Boris Zbarsky [:bz] (Out June 25-July 6) 2009-06-12 09:01:41 PDT
To be clear, the steps in comment 29 did NOT reproduce the bug for me.
Comment 33 Daryl Herzmann 2009-06-29 14:29:07 PDT
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
Comment 34 John J. Barton 2009-06-29 20:14:10 PDT
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 Daryl Herzmann 2009-06-29 20:17:02 PDT
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 John J. Barton 2009-06-29 20:19:41 PDT
Ok thanks, but how can I tell if if fails?
Comment 37 Daryl Herzmann 2009-06-29 20:22:14 PDT
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 John J. Barton 2009-06-29 20:28:17 PDT
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 Daryl Herzmann 2009-07-07 08:59:17 PDT
Hello.  I can't reproduce on FF 3.5 either. thanks!
Comment 40 John J. Barton 2009-10-13 21:23:19 PDT
The chances of this being fixed are vanishingly low.
Comment 41 Rob Campbell [:rc] (:robcee) 2012-02-22 12:54:47 PST
clearing flags on ancient bugs.

Note You need to log in before you can comment on or make changes to this bug.