Focus on URL bar after opening tab

[ghost]

It would be very, very nice if the URL would get focused when the new tab is opened, this way I can type right away an omnibar search (like a google search, for example)

[jimschubert]

See #46

I am leaving this open so other people can find it more easily.

[ghost]

Ty for responding so promptly.
Is there something that can be done in the browser to get this done?
Suggesting a patch to chromium exposing an api that lets extensions have
control over the omnibar perhaps?

On Wed, Apr 2, 2014 at 11:55 AM, Jim Schubert [email protected]:

See #46 #46

I am leaving this open so other people can find it more easily.

Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-39340195
.

Marcio Ribeiro

[jimschubert]

Unfortunately, they consider exposing that functionality a security risk.

The browser randomly focuses or doesn't.

You can use CTRL+L to achieve the same thing... which probably puts this as
a low priority for them anyway.
On Apr 2, 2014 1:16 PM, "mmr775" [email protected] wrote:

Ty for responding so promptly.
Is there something that can be done in the browser to get this done?
Suggesting a patch to chromium exposing an api that lets extensions have
control over the omnibar perhaps?

On Wed, Apr 2, 2014 at 11:55 AM, Jim Schubert <[email protected]

wrote:

See #46 #46

I am leaving this open so other people can find it more easily.

Reply to this email directly or view it on GitHub<
#50 (comment)

.

Marcio Ribeiro

Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-39357492
.

[ghost]

Wow, that ctrl-l shortcut totally made my day. Thanks a lot :)

On Wed, Apr 2, 2014 at 2:51 PM, Jim Schubert [email protected]:

Unfortunately, they consider exposing that functionality a security risk.

The browser randomly focuses or doesn't.

You can use CTRL+L to achieve the same thing... which probably puts this as
a low priority for them anyway.

On Apr 2, 2014 1:16 PM, "mmr775" [email protected] wrote:

Ty for responding so promptly.
Is there something that can be done in the browser to get this done?
Suggesting a patch to chromium exposing an api that lets extensions have
control over the omnibar perhaps?

On Wed, Apr 2, 2014 at 11:55 AM, Jim Schubert <[email protected]

wrote:

See #46 #46

I am leaving this open so other people can find it more easily.

Reply to this email directly or view it on GitHub<

#50 (comment)

.

Marcio Ribeiro

Reply to this email directly or view it on GitHub<
#50 (comment)

.

Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-39361593
.

Marcio Ribeiro

[Anthirian]

Or if you prefer to do it with only your left hand: alt+d will do the same thing.

[ghost]

F6 works as well

On Sun, Apr 13, 2014 at 7:01 PM, Geert Smelt [email protected]:

Or if you prefer to do it with your left hand: alt+d will do the same
thing.

Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-40321360
.

Marcio Ribeiro

[Arvin109]

I'd prefer that the omnibar would not get focused on when opening a new tab. This should be optional.

[ajschmidt8]

agree with Arvin. i prefer to have the keyboard not focused in the address bar. my homepage is set to google and i prefer to have the focus in the search box upon opening a new tab. hopefully this can be adjusted

[markentingh]

How about removing the actual URL instead? every time I try typing in the URL bar after opening a new tab, it looks something like this: chrome://appsgoogle.com.... frustrating lol.

[jimschubert]

Extensions aren't able to interact with the address bar that way. You can
use CTRL+L to highlight the text and just type over it.

The new built in apps page (remove the URL in New Tab Redirect's options
and click save) doesn't have this problem because that's the default
functionality for new tab override pages. The functionality is lost by the
'redirect'.
On Apr 24, 2014 9:16 PM, "markentingh" [email protected] wrote:

How about removing the actual URL instead? every time I try typing in the
URL bar after opening a new tab, it looks something like this:
chrome://appsgoogle.com.... frustrating lol.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/50#issuecomment-41350658
.

[jimschubert]

@Arvin109 and @ajschmidt8 The comment about cursor focus should be fixed in version 3.1.1 (related to issues #56 and #59).

This issue is about keyboard "focus" to highlight the contents of the address bar, which isn't possible. I realized just now that the label I applied used the same 'focus' terminology as when the issue was reported. I'll change that to 'highlight'.

The 3.1.1 fix should be available within a few hours.

[markentingh]

Thank you for such a quick response, Jim! Ctrl+L is a good alternative, and I found that Ctrl+A also works to highlight the text since the address bar already has focus when opening a new tab.

[jimschubert]

@markentingh no problem. I've released version 3.1.1 that reverts the default cursor location back to in-page. If you want it to remain in the address bar (as it does in the bug), I added an option to the options page to use update only... just check and save. I use CTRL+L almost all the time. It's really helpful when you're done with a page to just CTRL+L and type to change the page.

[chenzz]

I'd prefer that the omnibar would not get focused on when opening a new tab. This should be optional.

[jimschubert]

Again, this is functionality of the browser. I can't change it one way or
the other.
On Jun 14, 2014 1:12 AM, "greywolf272" [email protected] wrote:

I'd prefer that the omnibar would not get focused on when opening a new
tab. This should be optional.

—
Reply to this email directly or view it on GitHub
#50 (comment)
.

[b-d-m-p]

Another way to get the url selected after opening a new tab (or not have it show at all depending on how fast you do it) is to hit escape. It is quicker that ctrl + l and can have the desired effect of not showing the url at all if timed right.

Is there a way that you could have the extension send and esc after the tab opens?

Thanks for making this in the first place. It really helps me.

[shshaw]

I, too, am frustrated by having to overwrite "chrome://apps" whenever I need to navigate to a new page.

Another idea that may help: the extension opens its own custom page with a large text box near the top auto-focused that you can type a URL or search term into, hit enter and very simple Javascript would redirect the tab to that URL.

Your custom new tab page setting would be in an iframe below, taking up the majority of the screen. I'm not sure if chrome://apps will open in an iframe like that under an extension's permissions, but seems like a pretty simple solution.

Of course all this should be behind an option for those that just want a simple new tab redirect :-)

[Walkman100]

Sounds like an interesting idea, have an option to put the URL into an iframe and a blank default page (other than the iframe) instead of redirecting the tab to the URL

you could have the iframe replace the apps?

[abass]

Are there any updates on this? Or is it still not allowed? It's frustrating to do CTRL+T then CTRL+A or CTRL+L 😞

UPDATE: Wait, this seems to be working fine in regular Chrome, just not Chrome Canary?

[jimschubert]

This is still a limitation of the browser. Sometimes it's different between versions or operating systems. There's nothing that can be done from this extension. The issue is left open for visibility, not because it's a pending fix. Sorry

[abass]

@jimschubert very interesting how it could change between versions of the same browser. I'll just use the extension on regular Chrome because it seems to be working beautifully and selecting the URL as requested.

Thanks!

[jimschubert]

Yeah it has to do with the two threading contexts in Chrome. The browser related tasks (which open new tabs) run on one thread while page related tasks (like this extension's redirect mechanism) run on another thread. The issue is that new tab override pages (this extension's context) are loaded in the browser-level threads, and given URL focus when technically loaded. This extension then redirects to your defined URL on the second thread, which has no access to focus the URL.

The reason it differs across versions, from what I could tell, is related to changes made in either of those threads. But it's also affected by how many extensions or so you have loaded, which need resources from the chrome-related thread pool.

[abass]

Thanks so much for the reply, that's really interesting.

On Fri, Jul 14, 2017, 5:38 PM Jim Schubert ***@***.***> wrote: Yeah it has to do with the two threading contexts in Chrome. The browser related tasks (which open new tabs) run on one thread while page related tasks (like this extension's redirect mechanism) run on another thread. The issue is that new tab override pages (this extension's context) are loaded in the browser-level threads, and given URL focus when technically loaded. This extension then redirects to your defined URL on the second thread, which has no access to focus the URL. The reason it differs across versions, from what I could tell, is related to changes made in either of those threads. But it's also affected by how many extensions or so you have loaded, which need resources from the chrome-related thread pool. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#50 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFQDyk4VrfG-RzbDIc_neyJOsxiHRw7Wks5sN9_KgaJpZM4BvBJF> .

-- Alex Bass President & CEO CyberBytes Inc. cyberbytesinc.com // @alexhbass Sent from Google Pixel

[DezinoGraphist]

I'm using this extension from quite some time now and is very important in my daily routine working on Chrome browser. Recently after version 61 update the cursor in the address bar don't autoselect the text as it used to do earlier. It's bit annoying as I have to manually select the text in the address bar before typing any new text. Request you to kindly look into the bug and rectify at your earliest.

Look forward to your prompt support

[ElectricImpossible]

Same here.
Updated Chrome today and I'm on V61.

When I start a new tab the cursor is sent to the left of the address bar with my URL to the right. When i start typing my URL its followed by the original URL instead of its previous behaviour of being cleared.

Anything you can do to resolve?

[Untitled-Document-1]

I noticed the Chrome 61 issue, but in connection with my own (unpublished) new tab redirect extension. I agree it is annoying. My use case is where I load a file:/// page which contains my frequently accessed URLs (essentially a bookmarks page), but I sometimes just use it as a means to do a Google search in a new tab, hence having the address bar auto focus AND highlight the text so anything typed overwrites the URL is pretty helpful. There are a few keyboard shortcuts that'll highlight what's in the address bar (e.g. F6), but that's one extra keypress to slow the workflow down.

The problem in my extension seems to be connected with the use of chrome.tabs.update to perform the redirect. My workaround is to use document.location.replace(theUrl) instead to perform the redirect, and add "file:///" to the manifest to allow file:/// URLs. As an added bonus the workaround removes the back button history item, so it no longer appears as if the redirected page is the second page opened. The disadvantage is that the highlighting behaviour isn't exactly restored to its pre- Chrome 61 state; instead, the address bar isn't highlighted and the cursor is nowhere to be seen, just like you'd see after you typed the URL into the address bar manually and hit return.

For me this is an improvement on the cursor going to the left-most position in the address bar. What I found myself doing was googling for my search terms concatenated with the full file:/// path (obviously undesirable!). As a workaround for this I ended up embedding a Google search box in my file:/// page, and with some JS, auto-focussing on the input.

Of course without a redirect extension installed Chrome 61 behaves as before; the default new tab page's address bar is empty so having the cursor in the left-most position ready for input is not a problem.

I'd be interested to see the extension author's comments on this issue.

[jimschubert]

I don't have any additional comments other than what I've already made. This is an issue with how the browser decides to focus the address bar. All "solutions" I've made have only been hacks which don't work in every case or across platforms.

If you have a local HTML file which you'd like to be your new tab page, you can very easily create your own extension. The problem with address bar focus comes from redirecting to an http or https address.

I have an example extension which redirects to duckduckgo here: https://github.com/jimschubert/duckduckgo-newtab. Rather than modify override.html to point to some location, just replace override.html's contents with your redirect file's contents. Because the browser no longer needs to switch from the thread managing chrome (browser parts) to web parts, your address bar should automatically focus.

[Untitled-Document-1]

Perhaps it should have been a new post, but the issue I and the previous two posters are referring to is a specific change that came in just-released Chrome 61. I think this is distinct from discussions before it.

Anyway, thanks for the info regarding your duckduckgo extension, which I've adapted as you suggested. As before, the cursor is still focussed in the address bar. However with this method the address bar is empty, which avoids the undesirable situation I describe above where you end up doing a search of search terms + the full file path. As an added bonus, because no redirect occurs I reach my HTML page noticeable more quickly.

One disadvantage though, is that I keep the HTML file in my Dropbox folder so that I can load it as the new tab redirect page from another PC. Because this file content resides in override.html in the extension folder — %AppData%\Local\Google\Chrome\User Data\Default\Extensions\kgmhedbfjedjmnhpjolijbhghoaehdmk\1.0_0 — any edits to the HTML that I make are not synced across PCs. However, I've worked around this by removing override.html and creating a hard link called override.html, linking to the HTML file in my Dropbox folder.

[jimschubert]

The issue showing in Chrome 61 is just coincidence. It has randomly reappeared for users across different versions. Some users report newer versions of Chrome introducing the behavior while others report it being "fixed". In actuality, it has to do with sandbox logic and running the Redirect in a threadpool separate from that where browser events (new tab + rendering that page) occur. It seems like any additional logic of any kind may change the behavior. Although, users on the same OS and same Chrome version may consistently experience different behaviors.

Trust me, I understand it's frustrating. But I have no control over it, and I've combed through Chrome's source to see if there's a solution, which there's not.

[godey4me]

@jimschubert You understand and know more than I. But is there no way of sending "ALT+D" or "CTRL+L" to the browser after opening a new tab a new tab through execute_browser_action or execute_page_action in the manifest after "chrome_url_overrides": { "newtab": "override.html" }? Both execute_browser_action or execute_page_action seems to be for custom shortcuts but I guess there must be a command for sending chrome built shortcut. I am just brainstorming here. Thanks

Edit: I am referring to chrome_url_overrides in your code https://github.com/jimschubert/duckduckgo-newtab

[kmjennison]

FWIW, even though the address bar highlighting behavior is unstable, it looks like Chromium is trying to keep it working for new tab redirect extensions:
https://bugs.chromium.org/p/chromium/issues/detail?id=752794

This should be fixed in version 62.

[jimschubert]

@kmjennison Thanks for that link. Was your extension using http redirect or chrome.tabs.update after the new tab page loaded? The issue with this extension is that I don't have a hard coded URL as the new tab page. After my custom tab page loads, it checks chrome storage for a user defined URL and directs to that. Will the linked bug also fix this?

[kmjennison]

@jimschubert We were using chrome.tabs.update. Yes, this should fix your extension highlighting problem, too. I just tried New Tab Redirect on Chrome v62 beta, and it highlighted the url when "Always update tab, not redirect" is checked.

I'm going to make a feature request for Chrome extensions to better support this. I'll share it here when I do.

[jimschubert]

@kmjennison Thanks, I appreciate it. I had seen a bug previously that said this wasn't behavior that could be fixed (v51, I believe), and I combed through the Chrome source to see if it could be done. I last did this on v57 I believe, and it looked like it would require a significant amount of rework architecturally. It's awesome if they've naturally moved toward a fix.

If it makes the always update option work more consistently, that's good enough for me. When I implemented it, only about half the people that gave me feedback said it worked.

[kmjennison]

@jimschubert I posted a feature request here:
https://bugs.chromium.org/p/chromium/issues/detail?id=766331

[mezod]

Hey @jimschubert I'm not sure my comment will help you at all but since yours helped me when I stumbled upon this issue I feel I owe you.

I created a web extension for my little productivity app so that the app showed up when users clicked "new tab". Obviously I stumbled upon this issue, since users wanted to cmd+t and search. After a lot of searching I have found a solution. Instead of redirecting the users to my app, I created an iframe that displays my app.

Basically:

"chrome_url_overrides": {
    "newtab": "background.html"
  },

and

<iframe src="https://app.everydaycheck.com"></iframe>

with the proper styling of course.

This works like a charm for Google Chrome. However, even though it doesn't work for the current Firefox 56.0 version, it is already fixed for Firefox 57.0 (https://bugzilla.mozilla.org/show_bug.cgi?id=1372996) which is going to be released on 14/11/2017.

Thanks again

[jimschubert]

@mezod thanks for offering the suggestion. The issue with this approach for New Tab Redirect is that many sites either won't load or won't display correctly when put into an iframe. This is because iframes open sites up to potential security risks.

Also, many users of NTR use Google or other search engines as override URLs. Clicking links in the iframe would continue browsing through the iframe, making it so URLs wouldn't be apparent to users. This opens users to phishing and other exploits that I'm not willing to expose my users to.

[mezod]

Hey @jimschubert I don't fully understand your answer but I imagine where your concerns arise from and I think it totally makes sense for you to take that decision. Just to make sure I make the right decision too, since the iframe of my web extension redirects to my website (and thus I control the links from my site), I am not exposing my users to any exploits right? Thanks and sorry that the solution doesn't work for you.

[jimschubert]

@mezod Being that you maintain the two, you'd have to evaluate whether or not you are comfortable with the security of the solution.

It used to be that the concern was with sites being embedded by a hostile site. I don't recall the details because I haven't personally used iframes for a very long time, but it was something like cookies from the embedded site could be considered set on the domain of the hostile site.

There's an additional concern with how sites embedded in an iframe can interact with the "host" page. Chrome has done a pretty good job of locking this down via default Content Security Policy of script-src 'self'; object-src 'self'. This basically prevents scripts or plugins not loaded by the extension from running within the extension. I've never needed to evaluate how this would work from within an iframe, because my extension is unloaded once it has redirected the user to their desired URL. As I said, my concern would be more about users navigating away from an embedded iframe's src and not knowing they've ended up at like faecbook instead of facebook (don't try that misspelled site, it's an actual site that delivers malware); it's an easy way to lose passwords or get infected by accident. You could look into increasing your CSP policy to include child-src with your site's URL. As I understand it, this will allow only content from your site to display. You can read more about that here: https://www.html5rocks.com/en/tutorials/security/content-security-policy/.

You could also take it a step further and lock down the capabilities of the iframe (see https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/).

Like I said, I've stayed away from iframes for a long time. They seem like too much of a headache.

With your app, if you're doing a progressive web app, you should be able to set the URL directly in the override page setting in manifest.json and get rid of the iframe altogether. I believe that setting in manifest.json supports both http:// and https://, but no other schemes.

[mezod]

Thanks Jim.

I'll definitely look into CSP. I'm not sure I understood your last bit though, how exactly can you set an URL directly to the override page? I understood that the newtab had to link to an html that is aprt of the extension itself. Right now my manifest.json looks like:

  "chrome_url_overrides": {
    "newtab": "background.html"
  },

where background.html contains the iframe.

My app is a web application (not progressive). So I basically redirect there from the newtab and it fetches data from the localStorage. I'll look into progressive apps and see how they can help me. Thanks again for your help and I hope you can find a nice solution for your users at some point!

[ryancwalsh]

I came here from https://stackoverflow.com/q/46269675/ after trying to code my own basic Chrome extension that allows a New Tab to open a page of mine and still leave the cursor in the URL field to allow for a Google search.

I haven't been able to figure it out. I assume it's still impossible?

[jimschubert]

@ryancwalsh as far as I know, it's only possible with a new tab override and a hard-coded HTML location. This is because Chrome essentially has two processor threads, one for the browser and one for pages. New tab override pages load via the "browser pool" and anything that transfers to a non-local URL switches to the "page pool". If you only override using an HTML file local to the extension, you won't invoke that context switch.

The reason New Tab Redirect can't reliably focus the address bar is because extensions don't have control over anything related to the browser (the "browser pool") or any API to manage scheduling (the "context switch"). So, whether the address bar gains focus is reliant on many things like CPU, Memory, the number of extensions installed, the number of tabs open, etc. It's basically a race within the internals of the browser, unfortunately.

[ryancwalsh]

@jimschubert Thanks for your answer. Unfortunately I couldn't even get

 "chrome_url_overrides": {
        "newtab": "newTabOverride.html"
    }

to keep the cursor focused in the URL bar. https://superuser.com/a/1504546/74576

So maybe it's not possible. Or maybe I misunderstood you.

[Ck-a]

ok, i want to know what this does and why wont it let me????!!!! @jimschubert

[Ck-a]

need help please

[Ck-a]

this is a picture of me

[Ck-a]

#198 help!