Vimium on new-tab page

[smblott-github]

When creating a new tab with Ctrl-T, Vimium is not active and the focus is locked in the address bar. The whole Vimium UX is broken.

• Does anyone know how to fix this?

Absent a Vimium fix, I've been using New Tab Redirect to redirect chrome://newtab to a blank page with a very-long TTL (on which Vimium is active). Unfortunately, we can't do the same trick in Vimium. First, it completely disables chrome://newtab (and it wouldn't be possible to have an option to re-enable it). Second, redirecting to pages/blank.html still leaves the focus in the address bar.

As a super lightweight alternative to New Tab Redirect, I implemented this:

• https://chrome.google.com/webstore/detail/new-tab-url/njigpponciklokfkoddampoienefegcl
• https://github.com/smblott-github/chrome-new-tab-url

(which might be of interest to some Vimium users, absent a Vimium solution).

[nikess]

Anyone know any way to make it work with Momentum? (https://chrome.google.com/webstore/detail/momentum/laookkfknpbbblfpciffpaejjkokdgca?utm_source=chrome-app-launcher-info-dialog)

[smblott-github]

It'll Vimium will never work with Momentum, I think, because the new-tab URL is:

chrome-extension://laookkfknpbbblfpciffpaejjkokdgca

... and Chrome doesn't run other extensions on such pages.

[leoj3n]

My experience is different than yours.

Setting the new tab page to pages/blank.html in Vimium Options and pressing t opens a new tab but does not leave focus on address bar. I can immediately press o, shift+j or any other Vimium shortcut.

Is your plugin really necessary? Doesn't Chrome's native new tab setting suffice?

[smblott-github]

Setting the new tab page to pages/blank.html in Vimium Options and pressing t opens a new tab but does not leave focus on address bar

@leoj3n. You're right, for tabs opened with t. My extension then gives the same effect for tabs opened with Ctrl-T.

[leoj3n]

Ohhh got ya.

[wadkar]

I think I might need to open a new issue - but it appears that only I am facing it.
If I put pages/blank.html in the vimium settings, it opens a search result with pages/blank.html as query. I need to use chrome-extension://aaklmmoijnlnbeogmilbplamkggababp/pages/blank.html to actually get the blank.html page from vimium's extension source.
Any suggestions/hints on looking for solution/bugfix?

[mrmr1993]

The docs for chrome.tabs.create say (of the url parameter, which we pass as the contents of this setting):

Relative URLs will be relative to the current page within the extension.

If this isn't working properly, it sounds like a Chrome bug. Have you tried restarting the browser/reloading Vimium, to see if that makes a difference?

[smblott-github]

@mrmr1993. We can wait to see what @wadkar reports. But we could also just convert pages/blank.html to an absolute URL, and not worry about it.

[mrmr1993]

I don't think this is something we need to consider unless this is an issue for multiple people. But it would be tidier UX to just resolve relative urls manually (like chrome says it should), if this is an issue. A chrome-extension url looks kinda scary for people who aren't familiar with them.

[wadkar]

Test Report
Methodology: Open chrome, load the extension, ensure appropriate settings, run tests, remove the extension

• Test 1 with Vimium from chrome store (v1.49): Happy Path 1
  1. Chrome home page set to about:blank and vimium new tab URL set to pages/blank.html
  2. Open google.com in normal window, press t, a new tab with chrome-extension://.../pages/blank.html opens
  3. Open an incognito window, press t, a new tab with chrome-extension://.../pages/blank.html opens in the non-incognito window
     (Issue Open new tab in incognito mode should open new tab in same window #1507 reported , patch submitted PR Fix #1507 Open new tab in incognito mode #1508 and accepted)
• Test 2 with Vimium from local with PR#1508 applied: Happy Path 2
  1. Chrome home page set to about:blank and vimium new tab URL set to chrome://newtab
  2. Open google.com, press t, a new tab with chrome://newtab opens
  3. Open an incognito window, press t, a new tab with about:blank opens in the incognito window
• Test 3 with Vimium from local with PR Fix #1507 Open new tab in incognito mode #1508 applied: Happy Path 3
  1. Chrome home page set to about:blank and vimium new tab URL set to chrome-extension://.../pages/blank.html
  2. Open google.com, press t, a new tab with chrome-extension://.../pages/blank.html opens
  3. Open an incognito window, press t, a new tab with chrome-extension://.../pages/blank.html opens in the incognito window
• Test 4 with Vimium from local with PR Fix #1507 Open new tab in incognito mode #1508 applied: Failure Path
  1. Chrome home page set to about:blank and vimium new tab URL set to pages/blank.html
  2. Open google.com in normal window, press t, a new tab with pages/blank.html does not open
     Instead, I see search result for the query pages/blank.html
  3. Open an incognito window, press t, a new tab with search result for query pages/blank.html opens in the incognito window

Any other testing suggestions? My js-foo is a bit rusty, so I didn't attempt full debugging of PR #1508 . If you have any suggestions/hints I will be happy to give it another shot to PR #1508 . Till then, I think we should block PR #1508.

Cheers,
-S

[wadkar]

After little bit of digging around, it appears that createNewUrlInTab calls Utils.convertToUrl
A simple fix is to test for pages/blank.html in the convertToUrl function as follows:

  convertToUrl: (string) ->
    string = string.trim()

    # Special-case about:[url], view-source:[url] and the like
    if Utils.hasChromePrefix string
      string
    else if Utils.isUrl string
      Utils.createFullUrl string
    else if string is "pages/blank.html"
      string
    else
      Utils.createSearchUrl string

This may or may not be the right way to go. Note that the fix introduces an extension specific string literal "pages/blank.html" in the middle of Utils library.

If this is acceptable then let me know and I will create another issue/PR with the fix.

Cheers,
-S

[smblott-github]

Thanks for detective work, @wadkar. With the fix you propose, typing pages/blank.html into the vomnibar would take you to the blank page. That seems wrong.

A better alternative would be to find where the new tab setting is used (here), and replace it with the full URL directly. This is the only place where pages/blank.html has a special meaning.

[mrmr1993]

Changing

createTab: (callback) -> openUrlInNewTab { url: Settings.get("newTabUrl") }, callback

to

createTab: (callback) -> openUrlInNewTab {
  url: Settings.get("newTabUrl")
  rawUrl: true
}, callback

and

openUrlInNewTab = (request, callback) ->
  chrome.tabs.getSelected null, (tab) ->
    tabConfig =
      url: Utils.convertToUrl request.url
      index: tab.index + 1
      selected: true
      windowId: tab.windowId
    # FIXME(smblott). openUrlInNewTab is being called in two different ways with different arguments.  We
    # should refactor it such that this check on callback isn't necessary.
    callback = (->) unless typeof callback == "function"
    chrome.tabs.create tabConfig, callback

to

openUrlInNewTab = (request, callback) ->
  chrome.tabs.getSelected null, (tab) ->
    chrome.tabs.create {
      url: if request.rawUrl then request.url else Utils.convertToUrl request.url
      index: tab.index + 1
      selected: true
      windowId: tab.windowId
    # FIXME(smblott). openUrlInNewTab is being called in two different ways with different arguments.  We
    # should refactor it such that this check on callback isn't necessary.
    }, -> callback?()

should achieve exactly what we want (and IMO makes openUrlInNewTab easier to understand as a chrome.tabs.create call). We could also change openOptionsPageInNewTab to use openUrlInNewTab {url: "pages/options.html", rawUrl: true} too, to avoid any chrome.tabs.create duplicated logic. I can't make a PR for this at the moment, unfortunately.

[wadkar]

Yep, I agree Utils isn't the right way to go. Interestingly, the fix passes Test 2 completely (new tab opens in incognito window) but fails Test 3 by opening chrome-extension://.../pages/blank.html in the non-incognito window . I thought about fixing it some other way and arrived at a solution quite very much like @mrmr1993 . Note this doesn't fix #1507 in fact it breaks it by design.

I think we should create a separate issue/PR for this and link #1507 #1508 against it. I am making a separate branch for this and testing @mrmr1993 's suggestion - stay tuned.

Cheers,
-S