[Tracking Requested - why for this release]: STR: 1. Open this website page - https://bugzilla.mozilla.org/show_bug.cgi?id=1357486#c41 2. Scroll down to " Treeherder Bug Filer" comment 3. Hover bug 1379721 (or do it here) and enjoy 100% CPU usage, memory leak eating nearly all memory and GUI hang
FYI - Also set to "Off" "Use modal user interface" preference in Bugzilla General Preferences ( https://bugzilla.mozilla.org/userprefs.cgi?tab=settings )
Keywords: footprint, mlk
Summary: Mozilla Firefox Nightly 56.0a1 (2017-07-10) (64-bit) using 100% CPU, leaks memory and hangs on some links hovering → Disabled modal Bugzilla user interface causes Firefox to use 100% CPU, memory leak and hang on some links hovering
2 years ago
status-firefox54: ? → unaffected
status-firefox55: ? → unaffected
status-firefox-esr52: ? → unaffected
"Speedy" Regression window (mozilla-central) Good: https://ftp.mozilla.org/pub/firefox/nightly/2017/07/2017-07-05-03-02-06-mozilla-central/ Bad: https://ftp.mozilla.org/pub/firefox/nightly/2017/07/2017-07-05-09-59-41-mozilla-central/ Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0893f6685e154aaa3252ed091abb16a2feb2806d&tochange=11755fd63168581e194258d04bb6a7337779ec78
2 years ago
Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=41b421e98b77575451f5769f89af788fe68f183b&tochange=d1181db727669d3f0902c9ace520c377f67ae46a Regressed by: Bug 1356317
Component: Untriaged → Graphics: Layers
Product: Firefox → Core
Thank you Alice0775 White very much for finding specific regression range!
Has Regression Range: --- → yes
Has STR: --- → yes
I'm able to reproduce and I'm looking into it.
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
2 years ago
Summary: Disabled modal Bugzilla user interface causes Firefox to use 100% CPU, memory leak and hang on some links hovering → Hovering some hyperlinks causes 100% CPU usage, memory leaks and UI hangs after landing patch from bug #1356317
Kris, could you take a look at this as well? I've observed a continuous increase in memory consumption when displaying the tooltip when hovering links, but the memory consumption reverts to its initial state once the mouse is moved and the tooltip disappears. At this point, I don't believe we're dealing with a memory "leak", but rather some kind of unnecessary, continuous memory allocation. Unfortunately, I've been unable to isolate where or why this is occurring so far.
At the risk of possibly stating the obvious, a tooltip (which is displayed when hovering a link) is a popup and gIsPopupCompositingEnabled is set to false, which is why previous to attachment 8881870 [details] [diff] [review] landing, we would not use OMTC.
Created attachment 8885792 [details] [diff] [review] Patch This basically restores attachment 8881870 [details] [diff] [review], but changes nsWindow::ShouldUseOffMainThreadCompositing() to enable OMTC for remote content. This fixes the issue reported in this bug. However, I'm not sure if this change is satisfactory because I don't know if we're also experiencing excessive memory consumption with OOP WebExtension popups.
Tracking 56+ for this regression.
tracking-firefox56: ? → +
I think we should probably just disable OMTC for "small" popups, which would include things like tooltips and menus: http://searchfox.org/mozilla-central/rev/31311070d9860b24fe4a7a36976c14b328c16208/widget/nsBaseWidget.cpp#882
Created attachment 8885851 [details] [diff] [review] Patch As suggested. I've confirmed that this fixes the memory consumption issue for me locally.
Attachment #8885851 - Flags: review?(kmaglione+bmo) → review+
On Windows tool tips in bugzilla currently aren't displaying. Possibly a dupe of this bug?
(In reply to Jim Mathies [:jimm] from comment #14) > On Windows tool tips in bugzilla currently aren't displaying. Possibly a > dupe of this bug? never mind, appears this is caused by level 3 sandboxing.
I'm setting this to checkin-needed to get a second pair of eyes on it before landing. The try run seemed to show a lot of failures, but I was unable to determine if those were all just known intermittents, or if this patch would introduce new failures. For comparison, here is a try run with this patch applied: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3710fb78cf3deca4828ffd3d21af4f5e81d03fc2 And here is a try run with a patch that should just behave as nightly does right now: https://treeherder.mozilla.org/#/jobs?repo=try&revision=166dda3e730dd66bc1cd53042ba1ad56fc32812c Rather than just introduce some whitespace for the second patch, I wanted to run a try run with a patch that touches the same files as the first patch. This was to make sure that we rebuild the same files and run the same tests. I've noticed before that a no-op patch with just some added whitespace does not necessarily trigger the same tests to run. It appears to me that both try runs show almost exactly the same failures, which leads me to believe that these are known intermittents. Is this correct?
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/c623242b62da Fix high memory consumption when hovering links on Windows. r=kmag
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox56: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
I'm confirming that this issue is fixed, starting since Mozilla Firefox Nightly 56.0a1 (2017-07-15). Thank you very much! \o/
Status: RESOLVED → VERIFIED
status-firefox56: fixed → verified
2 years ago
QA Contact: Virtual
2 years ago
You need to log in before you can comment on or make changes to this bug.