983545 - Hiding then showing sidebar causes content to be reloaded

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[Ben McCann]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.146 Safari/537.36

Steps to reproduce:

Call sidebar.show()
Wait a couple seconds
Call side.hide() followed by sidebar.show()


Actual results:

The content in the sidebar was reloaded


Expected results:

I would expect for the content in the sidebar to persist. Reloading the content results in a slower, inconsistent, and visually distracting user experience. Consider, for example, the case where you want to show a sidebar whenever a certain tab is being viewed. If you switch away from that tab and then switch back, the tab contents are not reloaded, but the sidebar contents are, which is inconsistent. This reloading of contents causes a perceptible delay in the content being available and the loading action causes distraction from the main contents of the browser.

Comment 1

[Matteo Ferretti [:zer0] [:matteo]]

As far as I recall, this works as intended: it's not a bug of SDK, it's how all the sidebars works in Firefox. Erik mentioned that during the development of the API, and me and Mossop agreed that until is consistent with the rest of the sidebars behavior, it would be OK. Can't find the conversation, however.

I think the only way to "fix it", would be in the same way we did for panels, but exactly as panel it could be troublesome – plus, it would "leak" memory, keep the HTML document alive even if the sidebar is never displayed, or displayed just once.

About your use case, the Sidebar is a UI component considered per window, not per tab, exactly like toolbars. 
I think what you're looking for is something similar to devtools panel, but I don't think there is anything like that as UI component currently in Firefox.

So far, I don't see more options to keep the document from reloading, except that the approach we did for panel.

Dave, Erik, what do you think?

Comment 2

[ryanhuff78]

We have the same need for Cirrus Insight. Currently, we inject an html panel into the page contents. We created a prototype that uses the new sidebar (in order to have a real panel), but the reloading of content stops us from being able to display it only on the GMail tab as the user context is lost when she switches away and then back. There are quite a few other extensions that display content in this manner on a per tab basis as well including Social360.me, Falcon.io, and Preact. Don't have a strong vote as to whether the existing sidebar is "fixed" or a new component is created as I'm not familiar with what you're referring to having done with panels. Creating a new component sounds like a large task that would be hard to get movement on though. Is that something people would be willing to work on? Just stopping the reload behavior seems like potentially a small fix.

Comment 3

[Dave Townsend [:mossop]]

Keeping Panels in memory at all times has been a nightmare to maintain and I wish it had never happened, but in that case we cache the document for all Firefox windows which is part of the problem. If we can remove that part of it then things get simpler.

I'd like to understand your needs more.

If I close your sidebar, open the bookmarks sidebar then reopen your sidebar would reloading be acceptable?

Would you expect that opening a new Firefox window and displaying your sidebar would reload it?

Changing either of those behaviours would be non-trivial. Making it so just closing then reopening your sidebar doesn't reload is probably simpler but I'm not sure doing it is a good idea because it sets that precedent that might then lead to people wanting the above.

Comment 4

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Dave Townsend (:Mossop) from comment #3)
> Keeping Panels in memory at all times has been a nightmare to maintain and I
> wish it had never happened, but in that case we cache the document for all
> Firefox windows which is part of the problem. If we can remove that part of
> it then things get simpler.
> 
> I'd like to understand your needs more.
> 
> If I close your sidebar, open the bookmarks sidebar then reopen your sidebar
> would reloading be acceptable?
> 
> Would you expect that opening a new Firefox window and displaying your
> sidebar would reload it?
> 
> Changing either of those behaviours would be non-trivial. Making it so just
> closing then reopening your sidebar doesn't reload is probably simpler but
> I'm not sure doing it is a good idea because it sets that precedent that
> might then lead to people wanting the above.

I agree with all of this.

If delay is the issue, then it would occur during the initial load anyhow.

Comment 5

[Ben McCann]

Hmmm, I'd like to understand the memory usage and technical implementation here before I make suggestions that wouldn't be feasible or we come to a decision. I'm displaying a webpage in a sidebar and would expect it to behave similarly to the tab contents. What happens with the tab contents when you switch from one tab and then back? I don't see the page contents reload in that case. Is there a reason why that's more complicated for a sidebar than for a tab? I don't understand the part you mention about caching the document for all Firefox windows. Isn't a sidebar per-window?

>If I close your sidebar, open the bookmarks sidebar then reopen your sidebar would reloading be acceptable?
Yes, in this case it seems reasonable to reload. I think it should behave inline with the expectations that a user has with the main browser contents. When a tab is opened you have to load the page contents. When you switch tabs the page is already loaded and does not reload. So loading the contents when opening a sidebar is fine, but reloading the contents when switching away from it and switching back is jarring.

>Would you expect that opening a new Firefox window and displaying your sidebar would reload it?
Yes, I would want and expect the sidebar to load new content in that case. My sidebar displays content relevant to the page the user is viewing on certain domains (e.g. github, stackoverflow, linkedin, angellist). So when you open a new tab/window/page, then we need to load new content relevant for that page. Also, since sidebars are per-window, I'm not sure what it would even mean to share the content across windows such that it doesn't reload. That would seem like entirely changing the way sidebars work to make them global instead of per-window.

Ryan's product is extremely popular, so I'm familiar with it (in fact our entire sales team is using and pays for it as a Salesforce add-on) and would imagine the same answers hold true for him is as well. Ditto for a couple of the others he mentions that I have a passing familiarity with.

Comment 6

[ryanhuff78]

Yes, agree with what Ben said. To add to that and address Erik's point, it's not just the delay, but it's also that you would lose page state by reloading. If you're familiar with Rapportive, our extension is very similar in that it displays only on GMail. Using a sidebar instead of replacing GMail's contents is appealing because we don't have to worry about GMail changing their HTML layout and the user has more control over whether our widget is being displayed. When you switch away from the GMail tab, we want to hide the side. When you switch back to the GMail tab, we'd like to display it again, but we don't want to lose the state that was in the sidebar. If the user enters a bunch of text into an input box, they shouldn't lose that just because they switched to another tab and back.

Comment 7

[Dave Townsend [:mossop]]

(In reply to Ben McCann from comment #5)
> Hmmm, I'd like to understand the memory usage and technical implementation
> here before I make suggestions that wouldn't be feasible or we come to a
> decision. I'm displaying a webpage in a sidebar and would expect it to
> behave similarly to the tab contents. What happens with the tab contents
> when you switch from one tab and then back? I don't see the page contents
> reload in that case. Is there a reason why that's more complicated for a
> sidebar than for a tab? I don't understand the part you mention about
> caching the document for all Firefox windows. Isn't a sidebar per-window?

It is, but I didn't know if you expected it to be cached per window or not. It sounds like not which is good. The problem is exactly that the sidebar frame that displays the sidebar content is per-window and not per-tab and the norm has been to unload the document when closing it to free up memory that may never be used again. We don't free up tabs when switching away from them because they are still open to be switched back to. When you close a tab we do free them up though.

What is it exactly that makes the sidebar so slow to display in the first place? The document should be local so near instant load. Are you loading data from other sources to add in? Is it not possible to cache that sort of data in your extension?

Comment 8

[Ben McCann]

Part of the problem is that I don't want to close/reopen the sidebar. I actually want to show/hide it. Right now it's really doing more of a destroy/create despite the method names.

The sidebar content that we're showing actually isn't local. The sidebar API only allows us to use a local document, but we get around that by messaging the local document the URL we want to display and then it loads it in an iframe that takes up the whole sidebar. Even if it were local and instant to reload, you still have the problem Ryan mentioned which is that the user enters form input, manipulates the UI, or has other state in the sidebar that right now is being lost when you hide it, which is a frustrating experience.

Comment 9

[Ben McCann]

I wanted to check in and make sure you guys think this request makes sense and see if there's anything else I can answer regarding our use case or why this is causing problems for us. I'd be overjoyed to get this confirmed and assigned. Thanks!

Comment 10

[Dave Townsend [:mossop]]

(In reply to Ben McCann from comment #9)
> I wanted to check in and make sure you guys think this request makes sense
> and see if there's anything else I can answer regarding our use case or why
> this is causing problems for us. I'd be overjoyed to get this confirmed and
> assigned. Thanks!

I think we have the information we need but our product manager was out last week. We'll cover it in triage this week

Comment 11

[Jeff Griffiths (:canuckistani) (:⚡︎)]

For what it's worth, I *am* ambivalent about this:

a) on the one hand, our behaviour is exactly consistent with other sidebars. Re-opening the history sidebar resets state as well. This is how we should implement core UI integrations, with consistency. 

but, b) I see the use case as being valid, if a bit niche. I think implementing site-specific sidebars is an interesting idea, and I wonder if the right place for something like this could be npm once native jetpacks and npm support land

So this is a wontfix for what we ship in Firefox.