801506 - Hiding the social API sidebar apparently does not unload any compartments

Status: RESOLVED DUPLICATE of bug 802435

(Firefox Graveyard :: SocialAPI, defect)

Description

[Justin Lebar (not reading bugmail)]

STR:

1. Load Facebook in your social API sidebar.
2. Open about:compartments.  Record all the facebook.com compartments shown [1].
3. Hide the social sidebar (Click the Facebook "F", uncheck "show sidebar".)
4. Refresh about:compartments and again record all the facebook.com compartments shown.

Compare these and observe that the results from (2) and (4) are the same.

Refreshing about:compartments forces a gc/cc, so if we're actually releasing these compartments, they should not appear in (4).

The compartments also don't go away if I unselect "show desktop notifications".

It seems to me that this should block shipping of the social sidebar to users in the release channel.  There's no obvious way to log out of Facebook aside from hiding the sidebar, so this is both a major MemShrink issue and a user-sovereignty issue, in my view.

[1] With access tokens stripped out:

> https://www.facebook.com/desktop/client/page.php?socialfox=true
> https://www.facebook.com/desktop/client/socialfox/contentpanel.php?socialfox=true&jewelName=friends-jewel
> https://www.facebook.com/desktop/client/socialfox/contentpanel.php?socialfox=true&jewelName=messages-jewel
> https://www.facebook.com/desktop/client/socialfox/contentpanel.php?socialfox=true&jewelName=notifications-jewel
> https://www.facebook.com/desktop/client/tickerflyout.php?socialfox=true
> https://www.facebook.com/desktop/fbdesktop2/socialfox/fbworker.js.php
> https://www.facebook.com/desktop/fbdesktop2/socialfox/fbworker.js.php, [anonymous sandbox] (from: resource://gre/modules/Fr

Comment 1

[Justin Lebar (not reading bugmail)]

See also bug 801505, which related but not quite the same thing.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

See my comment in bug 801505 comment 2.  "show desktop notifications" doesn't equate to "disable this feature" and neither does unchecking "show sidebar".  However, I agree that hiding the sidebar should unload it rather than just hide it as happens now.

Comment 3

[Justin Lebar (not reading bugmail)]

(In reply to Mark Hammond (:markh) from comment #2)
> See my comment in bug 801505 comment 2.  "show desktop notifications"
> doesn't equate to "disable this feature" and neither does unchecking "show
> sidebar".  However, I agree that hiding the sidebar should unload it rather
> than just hide it as happens now.

Sure -- I'd expect /some/ compartments to hang around (unless I actually sign out, assuming we're going to add that).  But if nothing goes away when we hide the sidebar, that's not OK.

Comment 4

[Shane Caraveo (:mixedpuppy)]

All content is persistent once loaded, in part to avoid issues like bug 801495 happening every time you look at a ui component.  Hiding the sidebar is not turning off the socialapi.

Comment 5

[Mark Hammond [:markh] [:mhammond]]

If I pretended I was a UX person, I'd say something like:

* I suspect it might be fairly common for people to assume that closing the sidebar is disabling the feature, especially without UI elements specifically for disabling it next to the UI elements that hide the sidebar.  Thus, it might make sense to display a door-hanger or something similar when the sidebar is hidden to clarify this.

* I doubt people will regularly open and close the sidebar, so it probably isn't hard to make a case for unloading it when it is hidden.

* Issues like bug 801495 could be mitigated in other ways - eg, somehow loading flyout content as the sidebar is shown so when it finally becomes visible things are faster.

Just food for thought...

Comment 6

[Justin Lebar (not reading bugmail)]

+1 to comment 5.

> All content is persistent once loaded, in part to avoid issues like bug 801495 happening every 
> time you look at a ui component.

But bug 801495 does happen every time I mouse into the sidebar, so this clearly isn't doing us a lot of good.

But more importantly, it should be totally fine from a UX perspective if content takes a few seconds to load when I enabled the sidebar.  What is not acceptable from a MemShrink perspective is that we permanently hold on to windows that we're not showing.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

I think bug 802435 addresses these concerns.