high CPU usage when sea containers is displayed

[Jan02]

sea containers performance profile.zip

tested with nightly 59.0a1 20180103230158 Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Firefox/59.0

[ScottRFrost]

I'm on the beta channel and just got 59 today. I also get the high CPU usage.

[tradewatcher]

yes same here, hopefully this will be fixed soon.

[ScottRFrost]

I had to switch to Tree Style Tabs for now. It's not great (there's no way to force a given tree to always use a specific container), but it's a decent stop gap until Sea Containers is fixed.

[tradewatcher]

Yes very sad. Sea Containers is not usable with Firefox 59. I'm on Firefox 58 until it get fixed. But it looks like the Developer have no time to update this great addon.

I switched from Tree Style Tab to Sea Containers cause of the great grouping feature but i really miss the tree structure :( Groups > Tree :( If there is no Patch until next FF Release I'm also back to Tree Style Tab.

[ScottRFrost]

I've been experimenting with Conex today and it seems to work pretty well. You have to set extensions.webextensions.tabhide.enabled to true in about:config, but after that tab hiding works and it groups nicely using containers.

[jonathanKingston]

I see issues with the addon however not high CPU usage, I need someone to actually isolate when and why this is happening as I can't replicate it.

[tradewatcher]

Firefox 59 up2date

Create new Profile Open Task Manager Open Firefox Look Task Manager CPU usage Install Sea containers Display Sea containers (no cpu usage while not displayed) Look Task Manager CPU usage (my I7-4 need 10-30% more with no tabs) Open 100x times the same link and look CPU usage while loading 99% (I tried facebok.com as example)

This is not usable at the moment and no other Addon cause this issue :/

No problems @FF58

[dlicois]

I can confirm I also experience the 100% cpu usage on a thread, when displaying the sea containers sidebar (enabling the add-on without the sidebar is fine), since 59.

reproducing steps given by @tradewatcher are ok

Here is a capture with gecko profiler if it can help. https://perfht.ml/2G2sMNq

From the capture it would seem a lot of time is being wasted in this this stack (?) : imgLoader::LoadImage(nsIURI*, nsIURI*, nsIURI*, mozilla::net::ReferrerPolicy, nsIPrincipal*, unsigned long, nsILoadGroup*, imgINotificationObserver*, nsINode*, nsIDocument*, unsigned int, nsISupports*, unsigned int, nsTSubstring<char16_t> const&, bool, imgRequestProxy**) nsContentUtils::LoadImage(nsIURI*, nsINode*, nsIDocument*, nsIPrincipal*, unsigned long, nsIURI*, mozilla::net::ReferrerPolicy, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, unsigned int, bool) nsImageLoadingContent::LoadImage(nsIURI*, bool, bool, nsImageLoadingContent::ImageLoadType, bool, nsIDocument*, unsigned int, nsIPrincipal*) [clone .part.64] nsImageLoadingContent::LoadImage(nsTSubstring<char16_t> const&, bool, bool, nsImageLoadingContent::ImageLoadType, nsIPrincipal*) mozilla::dom::HTMLImageElement::AfterMaybeChangeAttr(int, nsAtom*, nsAttrValueOrString const&, nsAttrValue const*, nsIPrincipal*, bool, bool) mozilla::dom::HTMLImageElement::OnAttrSetButNotChanged(int, nsAtom*, nsAttrValueOrString const&, bool) mozilla::dom::Element::SetAttr(int, nsAtom*, nsAtom*, nsTSubstring<char16_t> const&, nsIPrincipal*, bool) mozilla::dom::Element::SetAttribute(nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&, nsIPrincipal*, mozilla::ErrorResult&) mozilla::dom::ElementBinding::setAttribute(JSContext*, JS::Handle<JSObject*>, mozilla::dom::Element*, JSJitMethodCallArgs const&) EnterJit(JSContext*, js::RunState&, unsigned char*) js::RunScript(JSContext*, js::RunState&) js::RunScript js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>) JS::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) mozilla::dom::EventListener::HandleEvent(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, mozilla::ErrorResult&) void mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*>(mozilla::dom::EventTarget* const&, mozilla::dom::Event&, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JSCompartment*) mozilla::EventListenerManager::HandleEventSubType(mozilla::EventListenerManager::Listener*, nsIDOMEvent*, mozilla::dom::EventTarget*) mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) EventListenerManager::HandleEventInternal error mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) EventDispatcher::Dispatch mozilla::EventDispatcher::DispatchDOMEvent(nsISupports*, mozilla::WidgetEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) nsINode::DispatchEvent(nsIDOMEvent*, bool*) mozilla::AsyncEventDispatcher::Run() nsThread::ProcessNextEvent(bool, bool*) NS_ProcessNextEvent(nsIThread*, bool) mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) MessageLoop::Run() nsBaseAppShell::Run() nsAppStartup::Run() XREMain::XRE_mainRun() XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) XREMain::XRE_main (root)

Might be a Mozilla regression but it would be nice to investigate.

[justfortherec]

I have the same issue: When sidebar with Sea Containers is opened in one window, Firefox CPU usage goes through the roof (> 100% of one core).

I am on Ubuntu 16.04.

Occasionally this seemed to not occur in all windows. During debugging I noticed that even within one session, most windows work fine, while one window shows this behaviour (the "main" window which I started the session with and has all the open tabs not used for debugging this issue). However, when trying to verify this now, opening Sea Containers in any window.

Sometimes I am able to reproduce the issue by opening a new window and opening a second tab while Sea Containers is open.

One other thought I had was that pinned tabs cause the issues. However, after unpinning all tabs in all containers, the issue persists.

I now tried reproducing the issue with a new profile. The steps for this are:

1. Create new Firefox profile and start Firefox. Note: Two tabs are open already and CPU usage is low.
2. Open a new tab to install Sea Containers

• Expected result: CPU usage settles at a low value after a few seconds.
• Actual result: CPU usage goes up and stays up.

Edit: Tried reproducing with a new Firefox profile.