Closed Bug 1124063 Opened 10 years ago Closed 10 years ago

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

Categories

(Firefox :: Untriaged, defect)

37 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1119442
Tracking Status
e10s ? ---

People

(Reporter: u123541, Unassigned)

Details

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.
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Ever confirmed: true
Summary: A web page is causing Nightly to run slowly → e10s - "A web page is causing Nightly to run slowly" isn't actionable without more info about which website is doing that
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
Summary: e10s - "A web page is causing Nightly to run slowly" isn't actionable without more info about which website is doing that → 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
> FF profiler exploring within FF; found the Performance tab -- will try that...
The options listed are: stop script, debug script, and kill web process.
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
oops, sorry.
(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 ?
Flags: needinfo?(pf)
(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.
Flags: needinfo?(pf)
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...
You need to log in before you can comment on or make changes to this bug.