From 96c74e4aa7e39a99bf5511440ba7a4155f1e2db8 Mon Sep 17 00:00:00 2001
From: Stephen Blott
Date: Sat, 2 Apr 2016 16:54:11 +0100
Subject: Simplify UI component initialisation.

There's no need for the previous complicated approach to UI component
initialialisation, in particular for the Vomnibar.

We only initialise the Vomnibar in the top frame.  However, if for some
reason it hasn't been initialised by the time it's needed, then we can
just initialise it then.  We are only initialising it early to avoid
flicker, so it's not a correctness issue.  And the only reason it
wouldn't be initialised is if Vimium is disabled in the top frame, but
enabled in some other frame -- which is not a common case.
---
 background_scripts/main.coffee | 5 -----
 1 file changed, 5 deletions(-)

(limited to 'background_scripts')

diff --git a/background_scripts/main.coffee b/background_scripts/main.coffee
index dea436ef..2a5b738e 100644
--- a/background_scripts/main.coffee
+++ b/background_scripts/main.coffee
@@ -291,8 +291,6 @@ Frames =
   onConnect: (sender, port) ->
     [tabId, frameId] = [sender.tab.id, sender.frameId]
     port.postMessage handler: "registerFrameId", chromeFrameId: frameId
-    # We only register the top frame automatically; other frames request registration via "registerFrame".
-    @registerFrame {tabId, frameId, port} if frameId == 0
 
     port.onDisconnect.addListener listener = ->
       # Unregister the frame.  However, we never unregister the main/top frame.  If the tab is navigating to
@@ -334,9 +332,6 @@ Frames =
       tabLoadedHandlers[tabId]?()
       delete tabLoadedHandlers[tabId]
 
-  initializeTopFrameUIComponents: ({tabId}) ->
-    portsForTab[tabId][0]?.postMessage handler: "initializeTopFrameUIComponents"
-
   linkHintsMessage: ({request, tabId, frameId}) ->
     HintCoordinator.onMessage tabId, frameId, request
 
-- 
cgit v1.2.3