Closed
Bug 1406664
Opened 7 years ago
Closed 7 years ago
Crash in nsContentUtils::FlushLayoutForTree
Categories
(Core :: Graphics: Canvas2D, defect, P3)
Tracking
()
RESOLVED
FIXED
mozilla58
People
(Reporter: zxspectrum3579, Assigned: milan)
Details
(Whiteboard: [gfx-noted])
Crash Data
Attachments
(2 files)
This bug was filed from the Socorro interface and is report bp-4b865734-dce8-48ad-949f-723ab0171007. ============================================================= WHAT WAS BEING DONE: Clicked to show/unfold a new tweet in a Twitter tab (not TweetDeck, just regular Twitter page for an account). WHAT HAPPENED: 1. The main non-GUI process has crashed, erasing the content of the currently opened tab with that Twitter page, as well its address bar and site's icon, showing a grey globe instead. 2. Then FireFox has started that tab process anew, and it grew a few gigabytes as it should, but the GUI was still useless -- when I tried to switch to a different tab it has also erased its content, address field and icon -- so after waiting for about ten minutes I had to kill the browser through task manager. WHAT SHOULD HAVE HAPPENED: 1. Normal continues operation without the crash. 2. Even if a crash has happened the GUI should not die. An independent FireFox process should somehow being able not only restart the main non-GUI process, but also check if the GUI-process is able to connect with the newly restarted main tabs process, and restart it too, if necessary. So far FireFox version 56 can not do that. Is this ability planned for a future version of FireFox? If not, then how to request such architectural change? It is by far not the first time when FireFox is practically unable to survive the death of its main non-GUI process and forces me to kill the browser manually. This should not happen, and yet it happens again and again with different types of crashes/signatures.
Reporter | ||
Comment 1•7 years ago
|
||
As you can see, whenever I tried to select a tab is just gets erased/cleared instead of being loaded/rendered. And the GUI is too slow during all of this time, it reacts to those clicks only after few minutes, despite I waited for a long time prior to trying to click on anything to make sure that the main tab process that was aromatically restarted fully loaded. And my attempt to close the GUI window, id est to exit the browser, has also failed, so I had to kill the browser through task manager.
Assignee | ||
Updated•7 years ago
|
Assignee: nobody → milan
status-firefox56:
--- → wontfix
status-firefox57:
--- → wontfix
status-firefox58:
--- → fix-optional
status-firefox-esr52:
--- → wontfix
Component: Graphics → Canvas: 2D
Priority: -- → P3
Whiteboard: [gfx-noted]
Comment hidden (mozreview-request) |
Comment 3•7 years ago
|
||
mozreview-review |
Comment on attachment 8917352 [details] Bug 1406664: Wallpaper over doc shell GetChildAt returning a failure/null item. Unclear when that would happen, but GetChildAt does have an error return, this handles it. There are very few crashes with this signature, and this just stops the null point https://reviewboard.mozilla.org/r/188354/#review193638 ::: dom/base/nsContentUtils.cpp:6924 (Diff revision 1) > if (nsCOMPtr<nsIDocShell> docShell = aWindow->GetDocShell()) { > int32_t i = 0, i_end; > docShell->GetChildCount(&i_end); > for (; i < i_end; ++i) { > nsCOMPtr<nsIDocShellTreeItem> item; > - docShell->GetChildAt(i, getter_AddRefs(item)); > + if (docShell->GetChildAt(i, getter_AddRefs(item)) == NS_OK && item) { This seems fine as wallpaper but I'd prefer Catalin took a look.
Attachment #8917352 -
Flags: review?(overholt)
Comment 4•7 years ago
|
||
I evidently don't know how to use MozReview. Can you ask :catalinb for a quick look there?
Flags: needinfo?(milan)
Assignee | ||
Updated•7 years ago
|
Flags: needinfo?(milan)
Attachment #8917352 -
Flags: review?(catalin.badea392)
Comment 5•7 years ago
|
||
mozreview-review |
Comment on attachment 8917352 [details] Bug 1406664: Wallpaper over doc shell GetChildAt returning a failure/null item. Unclear when that would happen, but GetChildAt does have an error return, this handles it. There are very few crashes with this signature, and this just stops the null point https://reviewboard.mozilla.org/r/188354/#review194828 ::: dom/base/nsContentUtils.cpp:6924 (Diff revision 1) > if (nsCOMPtr<nsIDocShell> docShell = aWindow->GetDocShell()) { > int32_t i = 0, i_end; > docShell->GetChildCount(&i_end); > for (; i < i_end; ++i) { > nsCOMPtr<nsIDocShellTreeItem> item; > - docShell->GetChildAt(i, getter_AddRefs(item)); > + if (docShell->GetChildAt(i, getter_AddRefs(item)) == NS_OK && item) { If the index is within bounds, why would GetChildAt fail?
Attachment #8917352 -
Flags: review?(catalin.badea392) → review+
Comment hidden (mozreview-request) |
Pushed by msreckovic@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4ab57bf53b59 Wallpaper over doc shell GetChildAt returning a failure/null item. Unclear when that would happen, but GetChildAt does have an error return, this handles it. There are very few crashes with this signature, and this just stops the null pointer crash. r=catalinb
Comment 8•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4ab57bf53b59
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Reporter | ||
Comment 9•7 years ago
|
||
Thank you, Sebastian. But what about a more general question about the ability for FireFox to survive main tabs process crashes more consistently? As I mentioned before, autorestart of the main tabs process after a crash does not help in the cases like this as well as many others when you still end up having used the task manager to manually kill off FireFox processes. Maybe a fundamental solution for this is coming, but I am just unaware of it? Thanks in advance.
Flags: needinfo?(aryx.bugmail)
Comment 10•7 years ago
|
||
I am not aware of that. For issues not resolved by this bug in the next "Nightly" build available at https://www.mozilla.org/de/firefox/channel/desktop/#nightly (please try in 3 hours or later), file new bugs for them. Thank you.
Flags: needinfo?(aryx.bugmail)
You need to log in
before you can comment on or make changes to this bug.
Description
•