Currently, the OAuth2 process is only started after DOMContentLoaded event emitted for TabSaver's BrowserAction dialog box, which is completely not the proper optimization (architecture) approach, taking into consideration TabSaver's infrastructure and it's Life-Cycle.
Then, next to the Google Analytics [GA] code initialization, it is asynchronously(!) trying to request the Google API access_token for further retrieve the basic user info. Requesting the access_token causes the user to Sign in to his Chrome Account, which has a serious impact on the data extension is working with.
Currently, there is no interaction implemented between main TabSaver's functionality and OAuth2 process activities, which must be changed in order to make both modules properly handle the authentication flow and private data.
Since now it is required to coordinate any synced extension's data updates (like modifying any saved user Session or even storing current one) according to the authentication status, the best solution will be to move all initial OAuth2 functionality earlier by the extension's Life-Cycle, and the best place will be to put it into the BackgroundPage
See related issues:
#1 Add verification if user is currently logged in to his Google account
#2 Restructure the source code
Currently, the
OAuth2process is only started afterDOMContentLoadedevent emitted for TabSaver'sBrowserActiondialog box, which is completely not the proper optimization (architecture) approach, taking into consideration TabSaver's infrastructure and it's Life-Cycle.Then, next to the Google Analytics [GA] code initialization, it is asynchronously(!) trying to request the Google API
access_tokenfor further retrieve the basic user info. Requesting theaccess_tokencauses the user to Sign in to his Chrome Account, which has a serious impact on the data extension is working with.Currently, there is no interaction implemented between main TabSaver's functionality and OAuth2 process activities, which must be changed in order to make both modules properly handle the authentication flow and private data.
Since now it is required to coordinate any synced extension's data updates (like modifying any saved user
Sessionor even storing current one) according to the authentication status, the best solution will be to move all initial OAuth2 functionality earlier by the extension's Life-Cycle, and the best place will be to put it into theBackgroundPageOAuth2functionality from theidentity.jsalong with existingBackground Pagescriptstubidentity.jscode for requesting the access token from a not interactive mode immediatly afterBackgroundPagemodule have been loaded (theoretically on the browser start; //TODO: find it out!)tabsaver:OAuth2.client.getAccessToken( {interactive: false}, _see_next_steps__callback );access_tokenand correspondingUserDetailsin a secure place later accessible from the main TabSaver's dialog (BrowserAction)UserDetailsobject at the same place containing flag notifying that abackground,non-interactivesession getting access_token failed, so the extension will start this Authentication flow over, but usinginteractivemode this time.BackgroundPage's andBrowserAction'sidentity.jsinstances may easely exchangeaccess_tokenin realtime. Add this functionality, if NOT!See related issues:
#1 Add verification if user is currently logged in to his Google account
#2 Restructure the source code