Issue metadata
Sign in to add a comment
|
Omnibox is not highlighted on new tab (when using an extension to override the NTP)
Reported by
ke...@tabforacause.org,
Sep 17 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36 Steps to reproduce the problem: 1. Install a new tab redirect extension (for example, New Tab Redirect: https://chrome.google.com/webstore/detail/new-tab-redirect/icpgjfneehieebagbmdbhnlpiopdcmna) 2. Go to the options page in New Tab Redirect. Enter a redirect URL and click "Save". Check the box "Always update tab, not redirect. (Enable for cursor in the address bar)" 3. Open a tab. Note that the omnibox URL is not highlighted; instead, the cursor is at the beginning of the URL. What is the expected behavior? I expect the omnibox URL to be highlighted when opening a new tab, even if the new tab is a webpage instead of a local extension page. What went wrong? The omnibox is not highlighted when overriding the new tab page. Instead, the user must manually highlight the omnibox. Did this work before? Yes 60 Does this work in other browsers? Yes Chrome version: 61.0.3163.79 Channel: stable OS Version: OS X 10.12.6 Flash Version: The core problem: there's no way for Chrome extensions to set the new tab page to an HTTP webpage and also keep omnibox clear or highlighted. Extensions (such as New Tab Redirect) have worked around this by calling `chrome.tabs.update` after a new tab is created. Prior to Chrome 61, this would have the effect of highlighting the omnibox, so users could then search or enter a new URL without manually highlighting the omnibox. Since Chrome 61, this workaround is broken, and the cursor appears at the front of the new URL and the omnibox is not highlighted. I've confirmed that this broke on both Mac and Windows. This regression previously happened in Chrome 34: https://bugs.chromium.org/p/chromium/issues/detail?id=362322 To set a webpage as the new tab page, extension developers currently have a few options, none of which is ideal: 1) iframe the webpage in the local extension page. Many websites won't work properly when iframed (for example, if they disallow iframes for security reasons). 2) Redirect the local extension new tab page to the webpage. As discussed above, the omnibox is not cleared or highlighted, which is a bad user experience. Potential fixes: * As a short term fix, revert to Chrome 60 behavior that highlights the omnibox when calling `chrome.tabs.update`. * Allow setting the manifest chrome_url_overrides.newtab value to an HTTP or HTTPS page. Clear or highlight the omnibox when opening a new tab. * Add a new property to chrome.tabs.create and chrome.tabs.update that sets the omnibox to be highlighted (e.g. an omniboxHighlighted boolean).
,
Sep 18 2017
I'm not seeing this (on Linux v62). I've tried with 2 extensions that take over the NTP, one as reported in issue 752794 . In any case, could this be a duplicate of that?
,
Sep 18 2017
I just noticed that the bug is reported against M61, but it has the label M62. If ths is the case, yes, this is an issue in M61. See the mentioned bug for the history, but essentially it was decided not to merge the fix to M61 since it was such a minor issue.
,
Sep 18 2017
Can we discuss these feature requests for Chrome extensions? * Allow setting the manifest chrome_url_overrides.newtab value to an HTTP or HTTPS page. Clear or highlight the omnibox when opening a new tab. * Add a new property to chrome.tabs.create and chrome.tabs.update that sets the omnibox to be highlighted (e.g. an omniboxHighlighted boolean). (Or, if this isn't the appropriate place to discuss, please advise on where I can post it. I didn't see a way to set a Chrome extension feature label when creating a new issue. Thanks!)
,
Sep 18 2017
Those should be in probably two new feature request issues. You can specify feature request under 'Type:'.
,
Sep 18 2017
The "New Issue" button in the top left doesn't show a "Type" field, at least for me (I looked in both the "End user" and "Web developer" sections). The only place to provide extension-related requests is End user > Extensions / Themes, but that seems specific to a particular extension, not extension development as a whole. Sorry if I'm missing something. I'll post there for now, but let me know if there's a better place.
,
Sep 19 2017
If you choose "Others" instead of "Extensions", you can choose Type=Feature.
But it is not necessary. Just file two new bugs under "Extensions" and mention in each of them that it is a feature request and someone will change the type later.
It is not very important. The right component ("Extensions") is more important.
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jmukthavaram@chromium.org
, Sep 18 2017Components: UI
Labels: -Pri-2 hasbisect-per-revision M-62 Needs-Triage-M61 OS-Linux OS-Windows Pri-1
Owner: k...@chromium.org
Status: Assigned (was: Unconfirmed)