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)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: justin.lebar+bug, Unassigned)

References

Details

Attachments

(1 file)

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.
> 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.
Group: mozilla-corporation-confidential
I just saw this too, but didn't have the profiler running at the time :-/
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*)
Looks like a whole lotta PostMessage.
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?)
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.
Seems likely! But we should also check with them about whether their unload code does anything dumb.
Depends on: 802929
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.
(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)?
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?
I haven't had problems recently, happy to close this.
Flags: needinfo?
great - let's call it bug 802929 and be done!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: