Closed Bug 1409675 Opened 7 years ago Closed 7 years ago

browser.tabs.update: allow selecting the URL

Categories

(WebExtensions :: General, enhancement)

Product:
WebExtensions
Component:
General
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: soeren.hentzschel, Unassigned)

References

Details

Attachments

(1 file)

master.zip
470.21 KB, patch
Details | Diff | Splinter Review
At the moment add-ons like New Tab Override are useless for a lot of users because when opening a new tab the address bar is not empty and the URL is not selected. Users have to manually clear the address bar before they can enter an URL. This makes Firefox unusable because you *have to* clear the address bar *on every new tab*. There is still no agreement about allowing WebExtensions to clear the address bar. But could you please at least implement an option to select the URL so that users can immediately start typing the URL on new tabs? It's still not beautiful but it would make new tab add-ons useful again. Thank you.
The details in comment 0 don't seem to match the bug title, but going from the description, it sounds like you're describing bug 1372996. What Firefox version are you using?
Flags: needinfo?(cadeyrn)
> The details in comment 0 don't seem to match the bug title I think it matches. bug title: "browser.tabs.update: allow selecting the URL" from the description: "But could you please at least implement an option to select the URL so that users can immediately start typing the URL on new tabs?" => I want an option to select the URL when using browser.tabs.update(). > it sounds like you're describing bug 1372996 Unfortunately not. The title of this bug is "URLBar should be selected or clear while newtab opened with overriding" but this bug neither implemented an option to select the URL nor to clear the address bar for add-ons which use browser.tabs.update(), only for overrides via manifest. But that's useless for all add-ons which let the user decide about the new tab page, this is only useful for fixed overrides. So the current situation is still that New Tab Override and similar WebExtensions can't clear or select the URL. I would really like to clear the address bar but I don't see this happen and selecting the URL would at least make these kind of add-ons useful again because it will allow to immediately start typing the URL without the need to select / clear the URL manually. > What Firefox version are you using? Firefox 58 Nightly.
Flags: needinfo?(cadeyrn)
The distinction between the specific request (focusing the location bar from tabs.update) and the use case (immediately navigating newly opened tabs to some url) wasn't clear from the original description. But now it makes sense.
Whiteboard: design-decision-needed
status-firefox57: --- → wontfix
This is still relevant to some degree, and should probably be addressed, if not in FF57, perhaps in FF58.
(In reply to radwoodward from comment #4) > This is still relevant to some degree, and should probably be addressed, if > not in FF57, perhaps in FF58. Not only "to some degree", nothing has changed. And Firefox 57 was released a few weeks ago so it can't be addressed in Firefox 57. It's probably even too late for Firefox 58, too, because the half of the Nightly 59 cycle is already over and I don't think this is something that will be uplifted so late (especially since no patch exists and the whiteboard still says "design-decision-needed").
Whiteboard: design-decision-needed → [design-decision-needed]
Hi Sören, this has been added to the agenda for the February 6, 2018 WebExtensions APIs triage. Would you be able to join us? Here’s a quick overview of what to expect at the triage: * We normally spend 5 minutes per bug * The more information in the bug, the better * The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details Relevant Links: * Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting * Meeting agenda: https://docs.google.com/document/d/1731b2kkN1wndNzVvo--5gwUcagbOSKGNYv4769r68NM/edit# * Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision
An alternative solution to this problem is to allow the `chrome_url_overrides.newtab` property to be set dynamically, allow HTTPS URL values for it, and open the new tab with a blank address bar (as it does now for local extension pages) or with a highlighted URL. Google Chrome extensions currently have the same shortcoming. Here's a sibling issue: https://bugs.chromium.org/p/chromium/issues/detail?id=766331 I'm not Sören but will plan to attend next week's triage to share my perspective.
Flags: needinfo?(mconca)
Whiteboard: [design-decision-needed] → [design-decision-denied]
Hi Caitlin, is there more informatioon about why this went to design-decision-denied state? I'd like to upvote this as the bug is quite annoying in daily use.
(In reply to Anck from comment #12) > Hi Caitlin, is there more informatioon about why this went to > design-decision-denied state? I'd like to upvote this as the bug is quite > annoying in daily use. I came to ask the same.
Thanks, Anck and AC! I appreciate your concern. :) In today's meeting, some security concerns were raised about this proposal as it was listed. We want to find a more appropriate mechanism to provide this functionality. Mike Conca, who's currently needinfo'd, will be commenting on this soon with more information about the security concerns and proposals for next steps.
The reason this request was denied is primarily for security concerns. Allowing an extension to highlight or blank-out the URL creates various hijacking scenarios, where a malicious add-on could redirect the user to a different page without the user knowing it. Secondarily, it could allow extensions to steal the focus from the main web page content, which is counter to current UX expectations. The reason that various New Tab Override extensions are using tabs.update() is that it is really the only way to create dynamic new tabs. Rather than try and shoehorn a solution into tabs.update() that doesn't create issues, the feeling was that we should just do the right thing for new tabs. This is likely something similar to the proposal listed in comment 11, although no specific solutions were discussed in the meeting.
Flags: needinfo?(mconca)
> The reason this request was denied is primarily for security concerns. Allowing an extension to highlight or blank-out the URL creates various hijacking scenarios, where a malicious add-on could redirect the user to a different page without the user knowing it. I can't follow how selecting the full URL can be a hijacking scenario. This ticket is not about blank-out the URL. Could you please explain the risk in selecting the URL? > Secondarily, it could allow extensions to steal the focus from the main web page content, which is counter to current UX expectations. Same again, I can't follow. The focus on new tabs is already on the address bar! We (WebExtension developers) has to apply ugly hacks (create a new tab and close the last tab at the same time) to explicitly set the focus to the web page if we want the behaviour described by you (focus on the web page)! > Rather than try and shoehorn a solution into tabs.update() that doesn't create issues, the feeling was that we should just do the right thing for new tabs. This is likely something similar to the proposal listed in comment 11, although no specific solutions were discussed in the meeting. Then, please, could someone from you, Mozilla developers, make a concrete proposal for a solution? Most useful proposals for new tab extensions were denied and I don't have more ideas what I can suggest to make new tab extensions useful again. Please just try New Tab Override and you will see that it's useless with the focus to the address bar, if you have select and clear the URL on EVERY NEW TAB… Selecting the URL would allow to immediately start typing. I don't understand how this can be have such a low priority. Add-ons for the new tab are used by hundreds of thousands of users!
Comments like "if you don't do X or Y I won't use Firefox anymore" are not helpful at all…
Gary, I understand your frustration, but Bugzilla is a professional working environment and comments like this are inappropriate. Please read the etiquette guide before making another comment. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html The next time you leave a comment like this, your account will be suspended.
(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #15) > The reason this request was denied is primarily for security concerns. > Allowing an extension to highlight or blank-out the URL creates various > hijacking scenarios, where a malicious add-on could redirect the user to a > different page without the user knowing it. Secondarily, it could allow > extensions to steal the focus from the main web page content, which is > counter to current UX expectations. There seems to be a big misunderstanding what this ticket is about. There is actually a security whole in the current Firefox implementation which allows to rewrite the address bar while the user is typing in it! This should be prevented and this is what this ticket is partially about. (For details read the paragraph "Case 1 ...") But first, let me explain the problem and the significance in more detail: Over many years (up to Sep. 2015) Firefox had a configuration option to set a start page that is loaded in new tabs. Hundreds of thousands (maybe millions) of users got used to this feature, especially because it was widely used in companies. In Sep. 2015 Mozilla decided to remove this popular feature from Firefox. And I'm glad that several add-on developers fixed this regression by writing very useful add-ons (e.g. New Tab Override, New Tab Homepage, ...). One of the first was "New Tab Override" which got very famous with more than 150.000 users. According to the add-on description the add-on was also mentioned on the official Mozilla blog in Dec. 2016 and it got advertised in the add-on manager in Oct. 2017. Well, but that's history, since Mozilla broke it again in Firefox 57. Now let me explain the bug/regression in Firefox 57: The New Tab Override add-on offers two focus options for new tabs: either the page content or the address bar can get the focus. Case 1 (address bar gets the focus): The following screencast shows the effect of this bug: http://stefan.endrullis.de/downloads/firefox/mozilla_bug_1409675.apng In the screencast I open a new tab via Ctrl+T. The address bar gets immediately focused and I can immediately start typing (which is good, because I often just want to search for something on the web). While I'm typing the start page that I configured in "New Tab Override" gets loaded and Firefox just adds it to my search term "test", which is IMO a bug. As a result, when hitting enter, Firefox sends "test" + START_PAGE_URL to Google and now Google knows my start page. :( Suggestion for a solution: Instead of manipulating the URL one second after the tab creating I would rather suggest to immediately show the URL of the page that gets loaded and preselect this URL so that the user can immediately replace it. Case 2 (page content gets the focus): This is very similar to the one above. When I open a new tab Firefox behaves pretty much the same as in case 1, except that the page content is focused. However there is still a delay between the new tab creation and the appearance of the URL that is loaded in the tab. Thus when you press Ctrl+L and start typing you get into the same problem as in case 1. I hope this clarified some of the misunderstandings and I also hope that Mozilla reconsiders reopening this bug report again or reimplementing/readding the original feature that was removed in 2015.
(In reply to Sören Hentzschel from comment #16) > > The reason this request was denied is primarily for security concerns. Allowing an extension to highlight or blank-out the URL creates various hijacking scenarios, where a malicious add-on could redirect the user to a different page without the user knowing it. > > I can't follow how selecting the full URL can be a hijacking scenario. This > ticket is not about blank-out the URL. Could you please explain the risk in > selecting the URL? I think there may be some confusion here, I believe this comment was that just giving extensions the ability to focus the URL bar at any time could lead to hijacking, a clever extension could trick the user into typing some privileged location and switch the focus to the URL bar right before they start typing and then manage to open some location it wouldn't otherwise be able to open. It may sound remote, but attacks like these do really exist. And I realize this bug is about specific behavior for newtab pages, this was just an explanation for why we won't do the more general thing. > > Secondarily, it could allow extensions to steal the focus from the main web page content, which is counter to current UX expectations. > > Same again, I can't follow. The focus on new tabs is already on the address > bar! We (WebExtension developers) has to apply ugly hacks (create a new tab > and close the last tab at the same time) to explicitly set the focus to the > web page if we want the behaviour described by you (focus on the web page)! I think the main issue here is that when we load a remote web page, we display a bunch of information about the page in the location bar. Its also where notifications are displayed if the site requires any permissions. That information is hidden when focus moves to the location bar. That's not an issue for the built-in newtab page since its not loaded from the web, but there's a conflict between those two if we want to have a remotely loaded web page and put the focus immediately in the location bar. I don't know for sure but I suspect this was related to why the ability to have a remote page loaded in new tabs was removed as a built-in feature. I don't really have a solution for this conflict, but somebody will have to come up with one if we're going to make progress here.
A simple solution would be to not dismiss any of these elements until the first user input occurs when using this API. Nothing in the address bar will have changed at that point besides highlighting of the address bar text.
> I think there may be some confusion here, I believe this comment was that just giving extensions the ability to focus the URL bar at any time could lead to hijacking, a clever extension could trick the user into typing some privileged location and switch the focus to the URL bar right before they start typing and then manage to open some location it wouldn't otherwise be able to open. It may sound remote, but attacks like these do really exist. I fail to see how letting extensions focus the URL bar is a legitimate security concern when extensions literally have the ability to **inject javascript in webpages**. might as well remove this feature too while you're at it. all we're asking for is the ability to blank out the address bar when opening a new tab and focus to it. The justification that "a clever extension could trick the user into typing some privileged location" is just simply ludicrous. Keep in mind, we're not asking to be able to write to it, simply blanking it. if a user installed a malicious extension, his browsing would already be compromised by a multitude of other security holes provided by the extensions API. This is really an issue of security vs functionality. and in this case, the security reasons provided just don't hold up to the functionalities already provided by the extensions API. If someone can explain to me how this feature request is more dangerous then letting extensions inject javascript in web pages, or just simply, opening new tabs without a users authorization. I'll gladly fall behind those arguments. But in the meantime, the security justifications that have been provided just make absolutely no sense to me whatsoever. Cheers,
Flags: needinfo?(aswan)
> all we're asking for is the ability to blank out the address bar when opening a new tab and focus to it. No, I filed this bug *not* for blanking out the address bar! I filed this bug explicitly for selecting the URL because it has less security implications than blanking the URL and it's more realistic to be implemented. Blanking the address bar should be discussed in another bug. @Andrew Swan: Thank you for your answers. > I think there may be some confusion here, I believe this comment was that just giving extensions the ability to focus the URL bar at any time could lead to hijacking, a clever extension could trick the user into typing some privileged location and switch the focus to the URL bar right before they start typing and then manage to open some location it wouldn't otherwise be able to open. It may sound remote, but attacks like these do really exist. > > And I realize this bug is about specific behavior for newtab pages, this was just an explanation for why we won't do the more general thing. So what does it mean for my request? Do I have to file a new bug, will there be a new discussion in the next triaging meeting or what is the next step to move forward? My use case is really only make new tab extensions usable, I don't need a way to change the focus at a later point. > I think the main issue here is that when we load a remote web page, we display a bunch of information about the page in the location bar. Its also where notifications are displayed if the site requires any permissions. That information is hidden when focus moves to the location bar. As I already said: The focus to the address bar is already the default behaviour for WebExtensions! I don't want to change this behavior. All I want is to select the URL instead of setting the cursor to the begin of the address bar. > I don't know for sure but I suspect this was related to why the ability to have a remote page loaded in new tabs was removed as a built-in feature. bug 1118285 has context for the removal. > I don't really have a solution for this conflict, but somebody will have to come up with one if we're going to make progress here. Any idea who could come up with a proposal? ;-)
>I filed this bug explicitly for selecting the URL because it has less security implications than blanking the URL and it's more realistic to be implemented. Blanking the address bar should be discussed in another bug. My bad! I should have refreshed my memory about this issue more before posting! But like you said, selecting the URL is even Less of a security issue then blanking the URL bar. so my arguments still hold. I'm with you on this one. I fail to see how making this possible is even remotely a security issue considering all the other things you can already do with the Extensions API.
(In reply to Sören Hentzschel from comment #26) > So what does it mean for my request? Do I have to file a new bug, will there > be a new discussion in the next triaging meeting or what is the next step to > move forward? My use case is really only make new tab extensions usable, I > don't need a way to change the focus at a later point. I don't know, this bug keeps getting pulled in different directions which makes it difficult to follow. That's certainly not your fault, you've been consistent, lets try to just keep the focus on your specific request here, I think we're making some progress here. > > I think the main issue here is that when we load a remote web page, we display a bunch of information about the page in the location bar. Its also where notifications are displayed if the site requires any permissions. That information is hidden when focus moves to the location bar. > > As I already said: The focus to the address bar is already the default > behaviour for WebExtensions! I don't want to change this behavior. All I > want is to select the URL instead of setting the cursor to the begin of the > address bar. But there's still a subtle but important difference: we don't show the URL for an extension page so if you start typing, you don't lose anything. We do show the URL for every remote web page. For a regular web page you have to take the explicit action to focus the location bar and start typing to discard that URL. In your proposal (showing the URL but selecting it), it would be very easy to accidentally start typing and discard it. Let's get some perspective from the UX team. shorlander, if I've got the wrong person can you redirect?
Flags: needinfo?(shorlander)
Flags: needinfo?(aswan)
Closing all open bugs with the [design-decision-denied] whiteboard flag.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
And there you have it. Almost 3 weeks later, nothing happened but the thread gets closed as WONTFIX. I don't see how this is the right way to handle bugs reported by the community.
So, what can a user that needs this fixed do? Even if they can code they can't just go and send a patch, because "a design decision is needed". So what's the option, forking firefox? I don't want to sound unconstructive, I just feel a bit hopeless with this.
I agree. It's a pity that this ticket got closed, especially because the rejection decision was based on a misunderstanding of the Mozilla team of what this ticket is about. Well, we tried our best to clarify this misunderstanding, but I guess this ticket was already too confusing for uninvolved people and one of the TL;DR kind which nobody likes to deal with. Since the issue is still valid, I think it would have a chance to be discussed. But probably not here anymore. IMO the ticket needs a clean restart (as a new ticket) with a clean description and a clean distinction of what it is not about, so that security concerns cannot be used as bad excuse to reject the issue. So if someone is still willing to file a new ticket, let us know so we can vote for it. I'm personally not involved that much anymore, since I anyway switched to Chromium since Firefox 57 (not only because of this ticket but because of a lot regressions that came with Firefox 57).
Reopening since there was still an open discussion going on here. :mconca, can you pester :shorlander or find somebody to handle the needinfo from comment 29?
Status: RESOLVED → REOPENED
Flags: needinfo?(mconca)
Resolution: WONTFIX → ---
Whiteboard: [design-decision-denied]
Please note that using another URL than about:newtab seems to be the only way to bring back mouse gestures on the new tab page. (Mouse gestures not working on the new tab page since FF57 massively interrupts the workflow when using mouse gestures.) However this bug (URL not selected) prevents this workaround (because manually clearing the URL every time is no solution). I hope I didn't add more confusion about the aim of this ticket. I just want to give one more hint why this feature is so much wanted/needed.
As mentioned in comment 15, using tabs.update() didn't feel like the right solution to support a user-defined URL as the New Tab page, and finding a better solution was the right answer. That solution is now being tracked in bug 1460412.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Flags: needinfo?(shorlander)
Flags: needinfo?(mconca)
Resolution: --- → WONTFIX
Product: Toolkit → WebExtensions
status-firefox57: wontfix → ---

My english is very bad.
I have clicked in "Add-on" and "New Tab override" under "Option" "custom URL".
And under "URL" only one point >. < entered.
When calling up a new page (with Srg. T, or in the menu bar click on > + < ) it will appear empty.

The inability for the address bar to be selected on new tab creation is a significant usability issue for me switching from Chrome to Firefox. I have homepage that opens on new tabs, but I also want to be able to start typing a URL right away. When I open a new tab, the New Tab Override triggers, correctly setting my new tab page, but stealing focus from my URL-typing halfway through and inserting the page URL into what I was typing.

The best solution would just be to let me set a new tab homepage, instead of offering me a choose between the Mozilla new tab page and nothing. However, allowing the URL bar to be programmatically selected would also solve this problem, as it would enable plugins like New Tab Override to set the new tab page and also still highlight the URL properly so you can type a new URL immediately.

Is anything happening with this problem? I can't believe that it has been closed!

Still not possible for the address bar to be selected on new tab opening (or allowing an extension to do it) ?
Edge Chromium and Chrome do it by default. Vivaldi used to do it too but a bug introduced in version 3.4 still needs to be adressed.
I was thinking about switching to Firefox temporarily or, who knows, mabye longer, but this is really a deal breaker for me.
Anyone knows if there is any chance that this gets fixed in the near future ?

This URL will create a new tab with nothing populated
http://about:blank

i solved this problem with Better Touch Tool. I created a keyboard shortcut that will create a new tab ( mac: cmd T) , then highlight the address bar ( mac: CMD L) , then select all ( mac: CMD A). so when i create a new tab, presto, the addess is highlighted and ready for me to type into it.
I highly recommend Better Touch Tool btw, regardless, but it solved this for sure.

They seem to have managed this in the Custom New Tab Page plugin:

https://addons.mozilla.org/en-US/firefox/addon/custom-new-tab-page/

It does not appear to be a problem any more.

URL is selected and empty

@nlambert - That add-on is not a solution. It's putting sites in an iframe within the new tab page, which comes with practical limitations and potentially security concerns.

@kevin not saying it's a solution... just saying the developer managed to do the exact thing OP says cannot be done. Albeit 4 years ago.

just saying the developer managed to do the exact thing OP says cannot be done

No, it can not be done. As Kevin already explained this add-on just embeds the page in an iframe. This may work for some sites but not for many others at all.

See Also: → 1426058
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: