Skip to content

Other Questions

Jump to bottom
jimschubert edited this page Nov 21, 2011 · 6 revisions

Nick writes:

Are you using JavaScript for redirection? I'm not 100% sure, but you might get a fraction of a second faster redirects by using the HTTP REFRESH method. I turned off the "Hide text" and it seems like you're using JavaScript. Could you try using the HTTP method? Oh, just set the content refresh to zero by the way. My second most favorite extension so far, excellent work.

Response:

The short answer: no.

New Tab Redirect doesn't work only on HTTP and HTTPS protocols. You can enter anything you want into the new tab url on the options page. For instance:

The possibilities are limitless. However, there are two reasons why a meta refresh tag will not work:

  1. meta tags can not be set with JavaScript
  2. meta tags do not support the browser-specific protocols such as chrome:// and about:

Point 1 is important because the way to persist options from the options page to the new tab page is done through HTML 5's localStorage, and is orchestrated through the background.html which acts as a long-running service for Chrome extensions. The only way to do this is through JavaScript. If I remove JavaScript from the equation, there is no way to persist your page option.

...well, I could probably use the FileReader and FileWriter APIs which are also HTML5. However, this API is not standardized and would most likely be a maintenance nightmare. I already get 10-20 complaints a month about how my extension is harmful because it changes how Google Chrome acts. Unfortunately (or fortunately, since that's what it's meant to do), it is an extension and users shouldn't be randomly installing extensions that they don't trust, don't understand, and don't know how to remove. That's why I've made everything open source, provided how-to guides, and even provided a walk-through explaining all the code and development process...

Point 2 is important because I personally like to switch between about:version and chrome://history. I know most users only link to web sites and local files, but there are a lot who prefer the about: pages.

Excellent suggestion, though!

This method (your suggestion) is exactly how example New Tab override pages are shown in the Developer's Guide for Google Chrome Extensions. If you're interested in "packing" your own extension, you can download the source code to the iGoogle New Tab Page here, change the link's location in the html file, then navigate to chrome://extensions, click developer mode then "Load unpacked extension" and browse to your file. BAM! you have your own, instant-loading New Tab override page!!

Keith writes:

[the extension] is not focusing in the address bar. I think this could be achieved by loading the target page in a border-less fullsize iframe, and having the onload event set focus to the omnibox using the extension API.

Here's a quick example:

<!DOCTYPE html> 
<html>
  <body style="padding: 0; margin: 0;">
  <iframe frameborder="0" width="100%" height="100%" 
          onload="chrome.omnibox.focus();" 
          src="chrome://insertURLhere">
  </iframe>
  </body>
</html>

Response:

Excellent question! I toyed with this idea when I was trying to figure out the best way to do the redirection. There are a few reasons I decided not to go this route.

  1. I hate iframes
  2. chrome.omnibox.focus() doesn't exist (read on for explanation)
  3. JavaScript in sites would inevitably break
  4. History would break (I'm only guessing here)
  5. The ability to bookmark would break
  6. The omnibox would always be empty

Why I hate iframes An application I maintain at work was written by developers who apparently loved iframes. I kid you not, one page is designed as a simple tree navigation on the left with a target on the right. The content of that page (tree + target) is within an iframe. I could live with that. However, the tree is within a second iframe and the target of the tree's navigation is within a third iframe. JavaScript is used as a very vulgar form of message passing between iframes. It is a maintenance nightmare.

I haven't ever seen the chrome.omnibar.focus() function. Currently, I am on a Chrome 13.0 developer branch. Here is how chrome.omnibar is defined for me (copy/pasted from inspector):

dir(chrome.omnibox)Object
onInputCancelled: chrome.Event
onInputChanged: chrome.Event
onInputEntered: chrome.Event
onInputStarted: chrome.Event
sendSuggestions: function () {
setDefaultSuggestion: function () {
__proto__: Object

As you can see, the above directly corresponds to the API definition.

JavaScript, History, and Bookmarks would break in the New Tab page if an iframe was used because many developers assume the page's parent is always window and write code similar to window.document.getElementById("you-old-so-and-so"). This isn't technically wrong, but breaks when nested in an iframe, whereas document.getElementById("you-old-so-and-so") works.

All that aside, I would guess that History would break at the browser level. Sure, you could use ALT+LEFT or ALT+RIGHT when the iframe is focussed, but I believe the back and forward buttons on the browser wouldn't work. Also, you couldn't use the star in the omnibar to bookmark a page. It would bookmark chrome://newtab instead of whatever site you're viewing, completely degrading my experience because I bookmark a LOT .

Now, I'm sure you understood all of my points. Imagine explaining this altered browser experience to an average or below-average internet user? YIKES!

Again, excellent question!

Clone this wiki locally