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)

defect

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.
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
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.
Blocks: 1423220
No longer blocks: 1397426
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
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
Priority: -- → P3
See Also: → 1423226
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?
Attachment #8940871 - Flags: review?(nika)
Attachment #8940872 - Flags: review?(nika)
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 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+
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.
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
https://hg.mozilla.org/mozilla-central/rev/4eeee702a4ef
https://hg.mozilla.org/mozilla-central/rev/24aa7ff25c3d
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 59
Shouldn't the fix be on Nightly by now? I still can reproduce the bug on Build ID 20180113100255.
Flags: needinfo?(mconley)
(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)
(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)
(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)
Is the same issue if you enable webrender, where you get the infinite wheel?
(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.

Attachment

General

Created:
Updated:
Size: