1124063 - e10s - "A web page is causing Nightly to run slowly" isn't actionable by user without more info about which tab/website is doing that

Status: RESOLVED DUPLICATE of bug 1119442

(Firefox :: Untriaged, defect)

Description

[u123541]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150120030203

Steps to reproduce:

Dunno.  It just happens a lot lately.



Expected results:

"A web page" is really not very useful with 500+ tabs over 12 windows open.  Please make this message, and any others more specific, so that we have a chance to find the culprit.

Comment 1

[u123541]

Um....   THAT is the message I, the user, gets...  The complete message disappears too fast to get the entire exact text; but I think it continues with: "What do you want to do about it? [ Options ]"

Even if the message, which appears at the top of the current page, stayed up longer so that I could grab the mouse and click "Options"; I'm not convinced that there would be much more info to go on...  and _this_ is my point about messages which are too generic to be of any use.  There are other performance problems I'm trying to get a handle on; but I've been searching for a FF profiler -- unsuccessful so far.

At least this message is useless enough to ask for more info from FF; which is what this issue is about...   HTH

Comment 2

[u123541]

> FF profiler
exploring within FF; found the Performance tab -- will try that...

Comment 3

[Wil Clouser [:clouserw]]

The options listed are: stop script, debug script, and kill web process.

Comment 4

[u123541]

Moot since the message and Options button don't sick around long enough to grab the mouse, aim it and click...  :]  Is the timer value in about:config?  Didn't find anything obvious.

Comment 6

[Jim Mathies [:jimm]]

oops, sorry.

Comment 7

[alex_mayorga]

(In reply to Pierre Fortin from comment #1)
> messages which are too generic to be of any use.  There are other
> performance problems I'm trying to get a handle on; but I've been searching
> for a FF profiler -- unsuccessful so far.
> 

This perhaps https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler ?

Comment 8

[u123541]

(In reply to alex_mayorga from comment #7) 
> This perhaps
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
> Profiling_with_the_Built-in_Profiler ?

Thanks Alex, but...  Actually, many of the thus-far-unreportable problems I'm experiencing cause FF to hang/stall for many seconds, making built-in profilers useless. Switching FF windows just gives blank window until the problem clears itself.  So I'm looking for something external like gdb|strace|? wrapped with a display of counters showing where FF is spending its time (in order of implementation priority): windows, tabs, sites, scripts, network, ...   Like top, htop, iotop, etc.; but focused on an application's footprint -- functions/subroutines, libs, etc -- not necessarily specific to FF.

In the early days of browsers on wimpy hardware, not a big deal; but I now run FF with 9-12 windows handling 500+ tabs that I move between quite a bit. And no, FF is not acting up because of the load I apply to it -- I see CPU activity either going quite high with no apparent reason, or going to near zero indicating FF has hit a blocking waitfor() of some sort  

At my age, I hate to waste time re-doing previous "search for, find, load, etc", only to get lost in those details and forget why I was going there in the first place... especially when I've already gone through all those steps once -- call it one_time_brain_init()   :)  And why I really appreciate session restore.

FF often realizes something abnormal is happening and informs the user in various ways; but, if FF could be more specific than, for example, "a script...", I could dig in and be able to provide more specific bug reports.  At the moment, I experience loop/hang/stall issues for which there is ZERO clue, so I can only resort to mental pattern matching in the hopes of an eventual "Ah-ha!" moment.

Comment 9

[u123541]

Should add: My recent bug 1120621 was only discovered by accident because I have gkrellm running to the side of FF watching my 4-core(8 thread) CPU with 32GB of memory (recently upgraded from 16GB because swapping was masking real stall/hang issues).  The built-in profiler is similar to gkrellm; except that there should be an external version...