added CTRL+Click and SHIFT+Click handler for context menu, Back and Forward.

content/browser/tab_contents/tab_contents_delegate.h

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_BROWSER_TAB_CONTENTS_TAB_CONTENTS_DELEGATE_H_
 #define CONTENT_BROWSER_TAB_CONTENTS_TAB_CONTENTS_DELEGATE_H_
 #pragma once
 
 #include <string>
 
@@ skipping 43 matching lines @@
   // in the current front-most tab), unless |disposition| indicates the url
   // should be opened in a new tab or window.
   //
   // A NULL source indicates the current tab (callers should probably use
   // OpenURL() for these cases which does it for you).
   virtual void OpenURLFromTab(TabContents* source,
                               const GURL& url, const GURL& referrer,
                               WindowOpenDisposition disposition,
                               PageTransition::Type transition) = 0;
 
+  // Opens a previous page.
+  virtual void GoBack(WindowOpenDisposition disposition);

[Ben Goodger (Google), 2011/06/09 16:21:50]

Where is this implemented? I don't see deltas to browser.h making it implement
this method.

Oh wait, now I see, the file already has locally defined GoBack/GoForward
methods that match these signatures.

This is very bad, and very dangerous practice.

There are some things that we do in Chrome code to make it clear where an object
is implementing a method from:

When we have a class (like Browser) that implements an interface (like
TabContentsDelegate), we ensure that all the interface overrides appear next to
each other in the Browser header (and in the .cc). This makes it clear where the
method is coming from.

We also add OVERRIDE to the end of the decl so the compiler can catch mistakes
for us should the method ever get renamed.

With all that said, I think this addition misses the point I was making in my
earlier comments. I don't believe these methods should be on the
TabContentsDelegate. The only method that should be added is
"ExecuteContextMenuCommand" or some such. This gives the delegate a chance to
handle a context menu command. It could return bool true if handled, false if
not handled (and the code in src/content should keep trying to handle it). The
code in Browser would be responsible for calling GoBack/GoForward on itself in
its implementation of this method.

I'm suggesting this because TabContentsDelegate has become far too fat, with a
huge number of methods on it for seemingly random features. In general types
work best when they are more focused rather than an unmaintainable grab-bag of
functionality.

+
+  // Opens a next page.
+  virtual void GoForward(WindowOpenDisposition disposition);
+
   // Called to inform the delegate that the tab content's navigation state
   // changed. The |changed_flags| indicates the parts of the navigation state
   // that have been updated, and is any combination of the
   // |TabContents::InvalidateTypes| bits.
   virtual void NavigationStateChanged(const TabContents* source,
                                       unsigned changed_flags) = 0;
 
   // Returns the set of headers to add to the navigation request. Use
   // net::HttpUtil::AppendHeaderIfMissing to build the set of headers.
   virtual std::string GetNavigationHeaders(const GURL& url);
@@ skipping 235 matching lines @@
   virtual content::JavaScriptDialogCreator* GetJavaScriptDialogCreator();
 
   // Invoked when a new renderer is created.
   virtual void RenderViewCreated(TabContents* source, RenderViewHost* host);
 
  protected:
   virtual ~TabContentsDelegate();
 };
 
 #endif  // CONTENT_BROWSER_TAB_CONTENTS_TAB_CONTENTS_DELEGATE_H_