Closed
Bug 802671
Opened 12 years ago
Closed 12 years ago
Disabling Facebook integration in the social API hangs the browser for ~30s (due to postMessage?)
Categories
(Firefox Graveyard :: SocialAPI, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: justin.lebar+bug, Unassigned)
References
Details
Attachments
(1 file)
217.36 KB,
application/x-xz
|
Details |
I disabled Facebook integration from the tools menu, and my browser was unresponsive for ~30s. It was not entirely hung, but UI interactions took many seconds to occur. I'll see if I can reproduce this.
Reporter | ||
Comment 1•12 years ago
|
||
> I'll see if I can reproduce this.
Not immediately. But maybe you have to leave the API running for a few days.
If someone else can try with a profiler at the ready, that might be useful.
Updated•12 years ago
|
Group: mozilla-corporation-confidential
Comment 2•12 years ago
|
||
I just saw this too, but didn't have the profiler running at the time :-/
Reporter | ||
Comment 3•12 years ago
|
||
Got it in perf. glandium tells me that perf's profiles are suspect due to elfhack, so I don't know how much this is worth. But probably something.
The delay this time was just a few seconds this time. Maybe it's Ω(time API has been open for).
Abbreviated profile below. I'll attach the full profile in a moment.
>- 9.33% firefox libxul.so [.] js::mjit::ExpandInlineFrames(JSCompartment*)
> - js::mjit::ExpandInlineFrames(JSCompartment*)
> - 95.07% js::StackIter::StackIter(JSContext*, js::StackIter::SavedOption)
> js::ScriptFrameIter::ScriptFrameIter(JSContext*, js::StackIter::SavedOption)
> JS_GetScriptedGlobal
> nsGlobalWindow::CallerInnerWindow()
> nsGlobalWindow::PostMessageMoz(JS::Value const&, nsAString_internal const&, JSContext*)
> nsGlobalWindow::PostMessageMoz(JS::Value const&, nsAString_internal const&, JSContext*)
> NS_InvokeByIndex_P
> XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)
> + XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)
> + 4.93% js::ScriptFrameIter::ScriptFrameIter(JSContext*, js::StackIter::SavedOption)
>- 2.72% firefox libxul.so [.] JSCompartment::wrap(JSContext*, JS::Value*)
> - JSCompartment::wrap(JSContext*, JS::Value*)
> - 28.89% js::CrossCompartmentWrapper::get(JSContext*, JSObject*, JSObject*, long, JS::Value*)
> - js::Proxy::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<long>, JS::MutableHa
> - 90.44% proxy_GetGeneric(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<long>, J
> - 99.34% JSObject::getGeneric(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<l
> - 98.48% js::GetPropertyGenericMaybeCallXML(JSContext*, JSOp, JS::Handle<JSObject*>, JS::Handle<l
> + js::mjit::stubs::GetProp(js::VMFrame&, js::PropertyName*)
> + 1.52% Str(JSContext*, JS::Value const&, StringifyContext*)
> + 0.66% js::Interpret(JSContext*, js::StackFrame*, js::InterpMode)
> + 6.83% js::baseops::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<l
> + 2.73% js::GetPropertyHelper(JSContext*, JS::Handle<JSObject*>, JS::Handle<long>, unsigned int, JS::Mu
> - 19.26% js::CrossCompartmentWrapper::call(JSContext*, JSObject*, unsigned int, JS::Value*)
> proxy_Call(JSContext*, unsigned int, JS::Value*)
> - js::InvokeKernel(JSContext*, JS::CallArgs, js::MaybeConstruct)
> - 76.80% js::mjit::stubs::SlowCall(js::VMFrame&, unsigned int)
> + 89.32% js::mjit::ic::NativeCall(js::VMFrame&, js::mjit::ic::CallICInfo*)
> + 10.68% 0x7fb12d462d36
> + 22.25% js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value
> + 0.95% js::Interpret(JSContext*, js::StackFrame*, js::InterpMode)
> + 17.68% JSCompartment::wrap(JSContext*, JSObject**)
> + 15.94% JS_WrapValue
> + 9.97% JSCompartment::wrapId(JSContext*, long*)
> + 4.34% js::CrossCompartmentWrapper::set(JSContext*, JSObject*, JSObject*, long, bool, JS::Value*)
> + 2.36% proxy_Call(JSContext*, unsigned int, JS::Value*)
> + 0.79% JS_WrapObject
>- 1.91% firefox libpthread-2.15.so [.] pthread_mutex_lock
> - pthread_mutex_lock
> - 10.20% nsACString_internal::MutatePrep(unsigned int, char**, unsigned int*)
> nsACString_internal::ReplacePrepInternal(unsigned int, unsigned int, unsigned int, unsigned int)
> nsACString_internal::Assign(char const*, unsigned int, mozilla::fallible_t const&)
> nsACString_internal::Assign(nsACString_internal const&)
> nsStandardURL::GetHost(nsACString_internal&)
> nsContentUtils::GetUTFOrigin(nsIURI*, nsString&)
> nsContentUtils::GetUTFOrigin(nsIPrincipal*, nsString&)
> nsGlobalWindow::PostMessageMoz(JS::Value const&, nsAString_internal const&, JSContext*)
> nsGlobalWindow::PostMessageMoz(JS::Value const&, nsAString_internal const&, JSContext*)
> NS_InvokeByIndex_P
> XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)
> + XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)
Reporter | ||
Comment 4•12 years ago
|
||
Reporter | ||
Comment 5•12 years ago
|
||
Looks like a whole lotta PostMessage.
Reporter | ||
Updated•12 years ago
|
Summary: Disabling Facebook integration in the social API hangs the browser for ~30s → Disabling Facebook integration in the social API hangs the browser for ~30s (due to postMessage?)
Comment 6•12 years ago
|
||
Good possibility it is bug 802929 - that leaks a "message port" once per second or so and terminating the worker closes all ports via postMessage.
Comment 7•12 years ago
|
||
Seems likely! But we should also check with them about whether their unload code does anything dumb.
Depends on: 802929
Comment 8•12 years ago
|
||
I have 10s hangs every few minutes while having enabled facebook SocialAPI Looks like a problem is in combination with addon. I'm trying to find out witch one.
Reporter | ||
Comment 9•12 years ago
|
||
(In reply to Boris Prpic from comment #8) > I have 10s hangs every few minutes while having enabled facebook SocialAPI > > Looks like a problem is in combination with addon. I'm trying to find out > witch one. That's definitely something we'd want to look into, but can you please file it as a separate bug (since it sounds like it doesn't have to do with disabling the API)?
Comment 10•12 years ago
|
||
Anyone seen this recently? I believe it probably was bug 802929 causing us to have a huge number of ports to close on worker terminate.
Flags: needinfo?
Reporter | ||
Comment 11•12 years ago
|
||
I haven't had problems recently, happy to close this.
Flags: needinfo?
Comment 12•12 years ago
|
||
great - let's call it bug 802929 and be done!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Updated•5 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•