Closed
Bug 482293
Opened 15 years ago
Closed 15 years ago
ajax requests freezing with firebug enabled
Categories
(Core :: XML, defect)
Core
XML
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?
Reporter | ||
Updated•15 years ago
|
Whiteboard: [firebug-p1]
Updated•15 years ago
|
Flags: wanted1.9.0.x+
Keywords: regression
Comment 1•15 years ago
|
||
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
Comment 2•15 years ago
|
||
It would be helpful to know if bug 460796 was also committed to 1.9.1, Firebug is failing there also.
Reporter | ||
Comment 5•15 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.
Updated•15 years ago
|
Flags: blocking1.9.1?
Comment 6•15 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•15 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?
Comment 8•15 years ago
|
||
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...
Reporter | ||
Comment 9•15 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.
Comment 10•15 years ago
|
||
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?
Updated•15 years ago
|
Flags: blocking1.9.0.8? → blocking1.9.0.9+
Comment 11•15 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.
Comment 12•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
You're not going to see a JS_ASSERT with a non-debug build.
Comment 16•15 years ago
|
||
We'd take a fix, but need a testcase and a good reproducible case before we can block.
Comment 17•15 years ago
|
||
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•15 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: http://code.google.com/p/fbug/issues/detail?id=1580
Comment 19•15 years ago
|
||
Can you give me step-by-step instructions on step 2 there ("enable script debugging for the page")?
Comment 20•15 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.
Assignee | ||
Comment 21•15 years ago
|
||
I haven't tested this yet, but I suspect this will fix this (and the leak).
Assignee | ||
Comment 22•15 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•15 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?
Comment 24•15 years ago
|
||
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•15 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•15 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?
Comment 27•15 years ago
|
||
Should this be marked as blocking bug 453978?
Comment 28•15 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.
Comment 29•15 years ago
|
||
> 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
Reporter | ||
Comment 30•15 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•15 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]
Comment 32•15 years ago
|
||
To be clear, the steps in comment 29 did NOT reproduce the bug for me.
Comment 33•15 years ago
|
||
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•15 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•15 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•15 years ago
|
||
Ok thanks, but how can I tell if if fails?
Comment 37•15 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•15 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•15 years ago
|
||
Hello. I can't reproduce on FF 3.5 either. thanks!
Comment 40•15 years ago
|
||
The chances of this being fixed are vanishingly low.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
Whiteboard: [firebug-p2] → [firebug-p3]
Updated•9 years ago
|
Keywords: testcase-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•