Thanks for the report and sorry no-one got to you sooner. I tried this with 3.6 and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a5pre) Gecko/20100412 Minefield/3.7a5pre and was didn't have any hangs. Can you reproduce on the most recent 3.6.x release? On a nightly build from mozilla-central <http://nightly.mozilla.org/>? I don't think this stack trace is real, you need symbols to get a real stack, e.g.: https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Whiteboard: [needs more info from the reporter]
Hi, thanks for the response. That trace was produced from SysInternals Process Explorer so no, I guess its not a true stack trace. I think its just showing the byte offset into each DLL file the calls are being made to. Anyway, I've just re-run the test case using Firefox 3.6.3 on Win7 64bit. The UI remains responsive and loading was fast even after opening 10 instances of the test page and interacting with all tabs. I've also not had any recent complaints about the bug come in from our users so I guess we can assume it was fixed/mitigated in 3.6.x. I'm a bit reluctant to say resolved as I still see occasional pauses during garbage collection in my day to day browsing. However, the key complaint here seems to be gone. It does leave me wondering why garbage collection isn't scheduled differently though. Any links/discussion about this I could read?
Okay, I'll resolve it as WFM then. > Any links/discussion about this I could read? bug 549533, bug 539532, but I'm not following that work closely.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.