-
Notifications
You must be signed in to change notification settings - Fork 11
Possible Uplift Issues
These are issues that may be issues for Firefox uplift. Discussion of possible solutions should be included.
The UI inside the panel uses HTML content served from a web server. This allows easier transparent updates to the UI without needing the user to confirm or take action to upgrade. Some possible issues with this approach:
The UI should show up very quickly. It has been said that there should be a 50ms response time for anything in the UI.
Solutions
The current panel UI is only created once per browser session, per browser window, then reused on subsequent panel opens. The end result is that it appears very quickly. Each time the panel is updated with information about the page being shared, the UI checks a timer and if it has been a day, then it will reload the UI, to make sure to get updates.
The only hit then is the first time load of the UI. This could be mitigated by the use of Application Cache (appcache) and triggering a behind-the scenes call to the app on first install that will prime the appcache, similar to how the F1 extension's "first run" logic works. It would also allow some UI to show up when Firefox is in offline mode. Some resources:
- Offline resources in Firefox
- [A beginner's Guide to Using the Application Cache](A Beginner's Guide to Using the Application Cache)
There is a feature/appcache branch that explores the use of appcache. Right now it just generates the application manifest on a "make web" call, no need for any developer changes, just a deployment option. More testing of appcache updates needs to be done to make sure new server deploys do the right thing. Instead of doing a page reload every 24 hours, instead trigger an appcache update check every X hours.
OAuth and user profile information is kept in localStorage. This helps keep the server lightweight, more session-less and a better protected security target by not keeping a cache of everyone's OAuth info on the server.
However, there is at least one extension, BetterPrivacy, that disables localStorage.
** Solutions **
The web/dev/scripts/accounts.js module has an implementation branch for an in-memory storage. This can be used instead of localStorage when it is not available. Before the latest Panel update, it was hard to use that in-memory only implementation because many more browser elements were created (one for each tab) and it was hard to communicate account changes. However, now that only one panel is created per window, it is easier to communicate changes between the settings page and the UI in the panel.
It does mean that there is a separate memory storage per window though, and each time the browser is closed, the oauth info is lost.
It may be good to communicate the oauth/profile info up to the extension and have it save the contents in the Password Manager or somewhere where FF keeps accounts/passwords. This might have the added benefit of tying in better with Firefox Sync. So maybe the web page can ask the extension for the info, and keep a local cache as needed, for faster UI display.