This started after updating from Firefox 29 to Firefox 30?

Firefox 30 switched most plugins from "Always Activate" to "Ask to Activate" so that sites require your permissions to use them. It's possible that OWA 2013 is trying to use a plugin that it isn't permitted to use without your approval. Maybe one of your Microsoft plugins?

You could try liberalizing the plugin permissions on the Add-ons page. Either:

• Command+Shift+a
• "3-bar" menu button (or Tools menu) > Add-ons

In the left column, click Plugins. Then on the right, switch your plugins to either "Always Activate" or "Never Activate" (for the less useful ones).

Try OWA in a new window, or after exiting Firefox and starting it up again.

Any luck?

Actually, I never had the chance to try OWA 2013 on Firefox 29. My company switched to OWA 2013 recently from another web mail platform that has its own issues.

I tried all the variations and the problem persists (pegs one core 100% and memory grows to 3+GB (6+GB virtual) within a short period of time, while logged in to OWA 2013, idling) even with a brand new profile (nothing imported) and NO add-ons and ALL plugins disabled.

Here is process sample/profile of firefox 3.0 (new profile, no add-ons, plugins disabled) idling on OWA 2013, in case it's helpful:

https://gist.github.com/anonymous/aa2463e7cb8bbe24dffb

Note, I'm using gist simply because mozilla only allows attaching images.

The problem persists in 31.0.

Sorry, I didn't know how to interpret the data linked in your last post. Hopefully someone else can spot a pattern there.

Do you want to post links to your crash reports? Or is there no formal crash, just grinding to a halt and force quitting?

If you have submitted crash reports, please check the support article "Firefox Crashes" (especially the last section) for steps to get the corresponding crash IDs, and then post some of the recent ones here.

It takes a while to crash on my 16GB rMBP, as memory growth seems to slow down beyond 2.7GB (new profile, no add-ons, plugins disabled; still pegs 100% a core). Here is a list of crash IDs that I believe are related:

Crash ID: bp-8b78fa7b-be9c-4f29-b827-fcea42140715 Crash ID: bp-92ed28fb-7cde-49d1-b08a-78ef92140712 Crash ID: bp-4ad5f3c5-46b4-4cd2-94f5-ad4272140710 Crash ID: bp-5add2e01-cceb-4a1e-a974-9c3332140710

The first crash signature (July 15th) is identified in the bug tracking database as a top crash and various people are working on trying to figure out what is causing it and how to fix it. When I look though the user comments, it isn't consistent, some people using maps (e.g., Google maps), Facebook, streaming media services; I don't see a pattern suggesting a quick workaround.

The second through fourth are less common and there's very little information in the crash reports.

These various types of crashes tend to occur on Mac OSX and Linux more than Windows. I'm not familiar with troubleshooting for those operating systems.

You can try to check for corrupted and duplicate fonts and other font issues.

• http://www.thexlab.com/faqs/multipleappsquit.html - Font Book 2.0 Help: Checking for damaged fonts
• http://www.creativetechs.com/iq/garbled_fonts_troubleshooting_guide.html

Played with the OWA a little more (clicking around, switching between folders) I can now easily reproduce the dreaded "Unresponsive Scripts" dialogs (boot.0.mouse.js:91 and preboot.js:34 and 32). The memory usage shot up to 8+ GB. I managed to get a crash with new profile, no add-ons, all plugins disabled, while using OWA on FF 31.0.

Crash ID: bp-04cfd787-5395-497a-91ef-5a1232140724

I took a quick look at the js files (https://gist.github.com/anonymous/8b854cf66a9cc9aab969). They appear to be generic Jquery and jquery UI code.

It appears that FF is extremely inefficient in creating (modest (a few thousand) number of ) DOM objects (for the scrollable email titles div), even if most of them are not rendered. In contrast, Chrome (35+) handled large number of DOM objects with aplomb, rendering them lazily and quickly. The hypothesis seems to be verified by showing only "unread" items, which FF seems to handle with ease (no CPU and memory spikes).

Looks like I'll have to keep Chrome open for OWA for a while...

Not sure whether it will make a difference, but Firefox 31 is now available (Help > About Firefox will check for updates).

Not sure if you've read my previous comments. The problem (resource hog and crashes) persists with Firefox 31.

Sorry, mixed this up with a different question on another tab.

I see reports of this problem starting with Exchange 2013 Cumulative Update 3, but no documented solution.

• Released: Exchange Server 2013 Cumulative Update 3 - Exchange Team Blog - Site Home - TechNet Blogs
• Firefox crashes with OWA 2013

I don't see similar comments on or after subsequent updates:

• Released: Exchange Server 2013 Service Pack 1 - Exchange Team Blog - Site Home - TechNet Blogs
• Released: Exchange Server 2013 Cumulative Update 5 - Exchange Team Blog - Site Home - TechNet Blogs

Maybe one of those fixed the problem -- or everyone just gave up on using Firefox with OWA 2013...

I don't have access to OWA 2013 myself (or a Mac, if that's relevant).