Closed
Bug 1423208
Opened 6 years ago
Closed 6 years ago
Permanent tabswitch spinners when opening some links in new tabs with tab warming enabled
Categories
(Firefox :: Tabbed Browser, defect, P3)
Firefox
Tabbed Browser
Tracking
()
RESOLVED
FIXED
Firefox 59
Tracking | Status | |
---|---|---|
firefox59 | --- | fixed |
People
(Reporter: mconley, Assigned: mconley)
References
Details
Attachments
(2 files)
STR: 1) Be logged into a Bugzilla account 2) View any bug where any other user has commented 3) Click on their username, which should bring up a popup that includes "Activity" 4) Click on "Activity", which should open and switch to a new tab to show that user's activity ER: The user's activity should be displayed. AR: A permanent tab switch spinner appears. Workaround: In the Browser Console, put in: gBrowser.selectedBrowser.renderLayers = false and press enter.
Assignee | ||
Comment 1•6 years ago
|
||
I can reproduce this on: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20171204234137 and I'm reasonably certain this is a regression from bug 1397426.
Assignee: nobody → mconley
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•6 years ago
|
||
Ah, the STR only seem to be valid if warming is enabled, so I'll re-wire this bug to block enabling warming by default.
Assignee | ||
Updated•6 years ago
|
Comment 3•6 years ago
|
||
Maybe a different bug with with 'tab warming' enabled when opening a link that is set to 'open in new tab' the tab opens, but the content is blank - nothing displayed. Pick any build on m-c from the (tc) Click on 'B' note info page opens on bottom of screen click on 'target txt' - tab opens, but content is blank
Assignee | ||
Comment 4•6 years ago
|
||
Thanks Jim - I suspect they're likely the same bug, but I appreciate the STR regardless. When I figure out the solution to this one, we can check to see if it fixed your issue.
Summary: Permanent tabswitch spinners when opening some links in new tabs → Permanent tabswitch spinners when opening some links in new tabs with tab warming enabled
Updated•6 years ago
|
Priority: -- → P3
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Assignee | ||
Comment 9•6 years ago
|
||
The problem was that a DocShell deactivation was being deferred by this code: https://searchfox.org/mozilla-central/rev/cf149b7b63ff97023e28723167725e38cf5df757/dom/ipc/ContentChild.cpp#1068-1072 Which means that we'd render layers, and then deactivate the DocShell (which deactivates the PresShell) which hides the layers again. My solution is to use the same mechanism for delaying DocShell activation to delay RenderLayers calls. mystor, do you feel comfortable reviewing this?
Assignee | ||
Updated•6 years ago
|
Attachment #8940871 -
Flags: review?(nika)
Attachment #8940872 -
Flags: review?(nika)
Comment 10•6 years ago
|
||
mozreview-review |
Comment on attachment 8940871 [details] Bug 1423208 - Make DocShell active state in TabParent default to true, since that's the actual default state. https://reviewboard.mozilla.org/r/211124/#review217528
Attachment #8940871 -
Flags: review?(nika) → review+
Comment 11•6 years ago
|
||
mozreview-review |
Comment on attachment 8940872 [details] Bug 1423208 - Queue pending RenderLayers calls when there are DocShell creation blockers. https://reviewboard.mozilla.org/r/211126/#review217526 ::: dom/ipc/TabChild.h:986 (Diff revision 1) > #if defined(ACCESSIBILITY) > PDocAccessibleChild* mTopLevelDocAccessibleChild; > #endif > bool mCoalesceMouseMoveEvents; > > bool mPendingDocShellIsActive; Please add a comment here explaining the mPendingDocShellBlockers field and how it interacts with the other mPending fields. I think that now that there are more things blocked by it there should be more clear documentation. ::: dom/ipc/TabChild.cpp:441 (Diff revision 1) > , mTopLevelDocAccessibleChild(nullptr) > #endif > , mPendingDocShellIsActive(false) > , mPendingDocShellReceivedMessage(false) > + , mPendingRenderLayers(false) > + , mPendingRenderLayersReceivedMessage(false) Please initialize mPendingLayerObserverEpoch
Attachment #8940872 -
Flags: review?(nika) → review+
Assignee | ||
Comment 12•6 years ago
|
||
mozreview-review-reply |
Comment on attachment 8940872 [details] Bug 1423208 - Queue pending RenderLayers calls when there are DocShell creation blockers. https://reviewboard.mozilla.org/r/211126/#review217526 > Please add a comment here explaining the mPendingDocShellBlockers field and how it interacts with the other mPending fields. I think that now that there are more things blocked by it there should be more clear documentation. Done! Thanks. > Please initialize mPendingLayerObserverEpoch Good eye, thanks.
Comment hidden (mozreview-request) |
Comment 14•6 years ago
|
||
Pushed by mconley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4eeee702a4ef Make DocShell active state in TabParent default to true, since that's the actual default state. r=mystor https://hg.mozilla.org/integration/autoland/rev/24aa7ff25c3d Queue pending RenderLayers calls when there are DocShell creation blockers. r=mystor
Comment 15•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4eeee702a4ef https://hg.mozilla.org/mozilla-central/rev/24aa7ff25c3d
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox59:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
Comment 16•6 years ago
|
||
Shouldn't the fix be on Nightly by now? I still can reproduce the bug on Build ID 20180113100255.
Assignee | ||
Updated•6 years ago
|
Flags: needinfo?(mconley)
Assignee | ||
Comment 17•6 years ago
|
||
(In reply to tgn-ff from comment #16) > Shouldn't the fix be on Nightly by now? I still can reproduce the bug on > Build ID 20180113100255. Hi tgn-ff, Are you saying you can reproduce the permanent spinner using the steps-to-reproduce from comment 0 using a Jan 13th build? I just tried and I couldn't.
Flags: needinfo?(mconley) → needinfo?(tgnff242)
Comment 18•6 years ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews and needinfos from comment #17) > Hi tgn-ff, > > Are you saying you can reproduce the permanent spinner using the > steps-to-reproduce from comment 0 using a Jan 13th build? I just tried and I > couldn't. Hi, Indeed, I can't reproduce it using the STR from comment 0. I used the steps I described on Bug 1423200, and I can reproduce it consistently using those (now on Build ID 20180113220355 too). Tell me if you want me to clarify or test anything. There were two recent Nightly builds on which the issue wasn't present. Those were (I just tested it again to make sure): 20180111100722 [1], and 20180111220102 [2]. Then 20180112100121 [3] was again bad. Mozregression, without the need of downloading any build to test, points to: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8142a68bf0a7b44c2502888ba6b2a930edf428fd&tochange=f7f5ba2214d2ce7b1ce9647b0e2540490a6098a8 [1]: https://archive.mozilla.org/pub/firefox/nightly/2018/01/2018-01-11-10-07-22-mozilla-central/ [2]: https://archive.mozilla.org/pub/firefox/nightly/2018/01/2018-01-11-22-01-02-mozilla-central/ [3]: https://archive.mozilla.org/pub/firefox/nightly/2018/01/2018-01-12-10-01-21-mozilla-central/
Flags: needinfo?(tgnff242) → needinfo?(mconley)
Assignee | ||
Comment 19•6 years ago
|
||
(In reply to tgn-ff from comment #18) > Mozregression, without the need of downloading any build to test, points to: > https://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=8142a68bf0a7b44c2502888ba6b2a930edf428fd&tochange=f7f5 > ba2214d2ce7b1ce9647b0e2540490a6098a8 > > Hm, okay. Interesting. I've re-opened bug 1423200 and will needinfo you there.
Flags: needinfo?(mconley)
Comment 20•6 years ago
|
||
Is the same issue if you enable webrender, where you get the infinite wheel?
Comment 21•6 years ago
|
||
(In reply to mdew from comment #20) > Is the same issue if you enable webrender, where you get the infinite wheel? This bug is with webrender disabled.
You need to log in
before you can comment on or make changes to this bug.
Description
•