What a bizarre response from Google, a couple hours after this was posted:
> @Reporter: As we are not very clear about the issue being faced by you, could you please elaborate on the same by providing detailed manual repro steps to reproduce the issue from our end.
> Also requesting you to share the expected, actual behaviours along with screen-cast for better understanding of the issue.
> *Note: Requesting you to copy-paste the entire content of "chrome://version/?show-variations-cmd" details to a .txt file format and attach it.
> Thanks..!
What could possibly be unclear about this bug report?
This kind of reply is why I can’t be bothered to report bugs anymore in general - between you and the people who know how to solve the problem there are five layers of bureaucrats who want to waste your time by bouncing the ball back into your court and asking for completely irrelevant details.
I think of them in terms of the adapter pattern. It would be great if I could talk directly to the SME on the other end of my problem, but the interface I'm going through is the interface for everything so the first layer you hit is the facade with a bunch of adapters that don't know much about the implementation behind the interfaces they're trying to get your message to.
I provided a click-by-click instruction with only 3 steps.
The triager created screen recordings twice, each time skipping an aspect of step 2; I wrote:
> "You did not follow step (2) of my repro steps: Loading a 1 GB file form a Windows file share (network folder)."
>
> ...
>
> This time you made the file 1 GB, but still do not load it from a Windows file share (network folder). Instead, you are again using your local Downloads folder.
I'd tend towards the latter, AI would have been more wordy and polite (it would have written "Also, please share" instead of " Also requesting you to share").
Sounds like someone just had a desire to make this pesky bug report go away, requesting detailed version information, detailed steps to reproduce, expected behaviour and a screencast (!), hoping the reporter wouldn't provide them so they have an excuse to close the ticket?
You'll need to explicitly navigate to the input box _designated_ for using a search engine.
If I'm accidentally pasting what I thought was a URL but actually is some other text in the paste buffer in the combined input box, that text is already sent to the search engine (provided suggestions are enabled, which they are by default).
If I do the same in the split URL/search box situation, and paste it in the URL box, it would at most look into the browser's history, keeping the input local.
Personally I like them separate. But I’ve been working with folks who are not very computer literate at all and I think I agree with you. If one doesn’t know what a URL is in the first place, how would one distinguish which box to type in?
Having them be the same can make tech support a nightmare trying to figure out whether someone actually successfully entered a URL or if they just googled it :(
(I personally love the URL bar & search bar being the same bar)
I get the luxury of working with folks in person. In 99% of cases the search produces the right website as the first result. But yeah idk maybe AOL had something going with keywords in some sense in terms of accessibility ¯\_(ツ)_/¯
You have it backwards: The omnibox (or whatever you want to call it) came about because people don't know what the hell a Universal Resource Locator is.
Most people don't know how to navigate their local file system, let alone the internet.
Yes. To dig a bit, they don't know because platform providers have pushed the net in that direction for decades.
AOL keywords were thing. Then fancy domain names that don't sound like domain names. Then search keywords. Then hashtags etc. The goal has always been to not ask the customer to think about it and just get to businesses.
>The publication of IETF RFC 2396 in August 1998 saw the URI syntax become a separate specification and most of the parts of RFCs 1630 and 1738 relating to URIs and URLs in general were revised and expanded by the IETF. The new RFC changed the meaning of U in URI from "Universal" to "Uniform."
I think that’s part of it. I love URLs (and URIs). Another big part is the predominance of closed social media platforms where the concept of a URL is mostly irrelevant
It should not need to be, if designed well. For example, the operating system facilities could make it that UI sizes will be specified by character size instead of by pixels, and then the operating system facilities can allow the user to adjust the UI fonts, so that any programs could use them.
Agreed. When I go to modify my searches after clicking through a few pages and realizing I'm not getting what I need, I don't have to hit back n times until I get back to the search.
The alternative would be always opening search results in a new tab until I find what I'm looking for, but I don't need more tab clutter.
I think that it does not need a separate area of the screen reserved for searching, but that there should be an explicit way to indicate that you want to search. For example, this could be a popup window. Unlike the URL, which it is useful to be displayed even if you are not entering a new URL, this is not necessary for entering search queries, so using a popup window for this purpose may be helpful.
I had managed to make a old version of Firefox to treat URLs entered in the location bar as relative. In my opinion, this is the reasonable way to work. The computer doesn't have to guess what you mean, and does not have to guess if the TLD is valid. It will do what you typed into the computer; and if it is an error, will display the error message.
For searching, I had done that if you put a colon at first and then the name of the search engine, then it will search.
No, everyone loves it. By everyone I mean the vast majority of the world.
The fact of the matter is most people do not grok addresses, so a dedicated address bar is useless to them. It's bad user interface design that defies what most people can do.
Here's how most people actually use a web browser if they want to go somewhere, say Amazon:
1. Type "amazon".
2. Enter.
3. First result is (probably) amazon.com.
4. Click.
5. ????
6. PROFIT!
In the dark ages this was facilitated by setting the home page to a search engine like Google, changing the address bar to a search bar removes that additional step making it that much easier for the common man.
Is it horrible for security and privacy? Yeah. But you write a web browser for users, not security and privacy nazis.
Could we please not use such a term for privacy/security conscious people?
Maybe it’s because I am German but I feel very uncomfortable being called such.
Resolved (2024.07.29.06), the Board [ICANN] reserves .INTERNAL from delegation in the DNS root zone permanently to provide for its use in private-use applications. The Board recommends that efforts be undertaken to raise awareness of its reservation for this purpose through the organization's technical outreach
Can’t you usually force it to skip the search by prefixing with the schema? Certainly if I type in http://example.internal and press enter, I would be very displeased to have that turn into a Google search regardless of whether the part after the // fits some regex or whatever else internal to the browser.
Right, considering that single-label names (indistinguishable from search queries) have been a thing since WINS/NetBIOS, DHCP suffixing, etc. -- expecting a dot (let alone a dot followed by a public suffix) is bogus.
Well, that wouldn't work with most search queries then. Do you really want to (fail to) load http://facebook/ when somebody types "facebook" into the address bar?
I agree most people wouldn't want that. We're talking about typing the scheme in this particular comment thread, however. Most people who type a scheme followed by a single-label name (e.g., "http://facebook") are not intending to submit a query to a search engine, so it's good that browsers don't use the lack of dot as a search heuristic in such cases.
Actually, entering _anything_ that looks like a FQDN should automatically bypass search in any browser. It’s been a long-standing pain of mine that when browsers merged the URL and search fields it became impossible to type “home.lan” (or .local, or .internal) and have it just work without stomping out http:// in front.
Also one of the reasons I seriously appreciate Firefox, because you can still have a dedicated search box to the right side of the URL entry field/address bar, and easily reach it by hotkey by command-K on MacOS or other similar shortcuts on Linux, Windows.
The number of times I've typed some internal-only thing or raw IP address into a browser and had it go to a search page instead of the thing I want to talk to, I've lost track of in the past 15 years, and it's too damn high.
The other thing I do is disable history. I forget the flag in Firefox (might be places.history.enabled or something). Forward and backward navigation still work per tab, but nothing gets recorded in the history menu. Every once in a while I wished I could go back into my history, but overall I prefer not to leave a log of what pages I've been to.
afaik you can use prefix to explicitly do search. for example no direct search but you can use "g paris" to search for paris on google or "w paris" to search paris on wikipedia
to keep different projects apart during development only to realize that you can't make that work with OAuth, because you can't use http://subdomain.localhost as a Oauth callback host. But you also can't share cookies between subdomain.localhost and localhost to redirect back without losing the session.
I don't think there's an oauth requirement where those don't work and your issue is more likely to be with the provider itself and restrictions they make on http or local domains. I'd either run an nginx proxy to get around http or choose some domains that don't conflict with their local restrictions. You can add whatever domain you want to a hosts file that resolves to your local IP. I leverage this a lot.
Any competent provider should give you some method for local testing and you should work with them given the provider you've chosen.
Also a good argument for, if you run internal-network only resources, to purchase and use an actual domain for it (such as companyname.us or whatever).
Publish a zone file for the domain as authoritative master and secondary on an internet facing DNS server, but have basically no records in the zone (no useful A or CNAME or anything else).
Host the actual DNS for your internal services on your internally-accessible-only DNS server.
> As of October 18, 2024, the domain has not been standardized by the Internet Engineering Task Force (IETF), though an Internet-Draft describing the TLD has been submitted.
Isn't .local specific to 'rendezvous' tech anyway? I forget the generic name but it was Apple that put it on the map under this name. But I mean that serverless broadcast protocol.
What I do is I just bought a domain and use that together with DNS-based SSL. It's a bit hard to set up with every different SSL server but it's doable.
The non Apple name is multicast DNS or mDNS. mDNS is exclusive to .local, but not necessarily the other way around. From its Wikipedia entry:
"By default, mDNS exclusively resolves hostnames ending with the .local top-level domain. This can cause problems if .local includes hosts that do not implement mDNS but that can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that mDNS was designed to avoid."
Hanlon's razor is malicious. Assuming malice is the trivial right choice. Assuming stupidity just bc it rhymes, or bc you can feel smart about yourself is stupid.
What a bizarre response from Google, a couple hours after this was posted:
> @Reporter: As we are not very clear about the issue being faced by you, could you please elaborate on the same by providing detailed manual repro steps to reproduce the issue from our end.
> Also requesting you to share the expected, actual behaviours along with screen-cast for better understanding of the issue.
> *Note: Requesting you to copy-paste the entire content of "chrome://version/?show-variations-cmd" details to a .txt file format and attach it.
> Thanks..!
What could possibly be unclear about this bug report?
This kind of reply is why I can’t be bothered to report bugs anymore in general - between you and the people who know how to solve the problem there are five layers of bureaucrats who want to waste your time by bouncing the ball back into your court and asking for completely irrelevant details.
I think of them in terms of the adapter pattern. It would be great if I could talk directly to the SME on the other end of my problem, but the interface I'm going through is the interface for everything so the first layer you hit is the facade with a bunch of adapters that don't know much about the implementation behind the interfaces they're trying to get your message to.
This has happened to me a couple times in the Chromium bugtracker.
Another issue I filed:
https://issues.chromium.org/issues/40900126
I provided a click-by-click instruction with only 3 steps.
The triager created screen recordings twice, each time skipping an aspect of step 2; I wrote:
Lol. "Thanks..!!"
probably just an ai or unskilled triage tech responding?
I'd tend towards the latter, AI would have been more wordy and polite (it would have written "Also, please share" instead of " Also requesting you to share").
Sounds like someone just had a desire to make this pesky bug report go away, requesting detailed version information, detailed steps to reproduce, expected behaviour and a screencast (!), hoping the reporter wouldn't provide them so they have an excuse to close the ticket?
The “also requesting you to share” clearly reads as an expression from a certain part of the world with a lot of outsourced tech.
Maybe outsourced?
Nah, it’s “AI”.
[dead]
One of the worst security bugs of browsers is the combined url/search bar. But Google loves it!
What about .corp subdomains?
I think it's the autocomplete in particular that leaks a lot of private data. I've rarely had the combined bar do a search when I didn't want it to.
But I use firefox and I turned off autocomplete. And I use my own search instance (SearXNG)
> I think it's the autocomplete in particular that leaks a lot of private data.
That’s the beauty. The whole unified input can be presented as a UX simplicity gain, while this quote points at the actual business value. ;)
Innovation!
IIRC there is no setting in Firefox to keep the content of the URL bar local.
How could searchengines provide suggestions without your browser sending the url-bar content?
If you want the content of your URL bar to stay local you should disable suggestions
They can do it like they previously did it: provide suggestions by sending the search box content.
How is that different in the case of a combined search&url bar?
You'll need to explicitly navigate to the input box _designated_ for using a search engine.
If I'm accidentally pasting what I thought was a URL but actually is some other text in the paste buffer in the combined input box, that text is already sent to the search engine (provided suggestions are enabled, which they are by default).
If I do the same in the split URL/search box situation, and paste it in the URL box, it would at most look into the browser's history, keeping the input local.
We had them separated once upon a time. UX was arguably worse.
Personally I like them separate. But I’ve been working with folks who are not very computer literate at all and I think I agree with you. If one doesn’t know what a URL is in the first place, how would one distinguish which box to type in?
Having them be the same can make tech support a nightmare trying to figure out whether someone actually successfully entered a URL or if they just googled it :(
(I personally love the URL bar & search bar being the same bar)
I get the luxury of working with folks in person. In 99% of cases the search produces the right website as the first result. But yeah idk maybe AOL had something going with keywords in some sense in terms of accessibility ¯\_(ツ)_/¯
It's because of the omnibox that people no longer know what an URL is.
You have it backwards: The omnibox (or whatever you want to call it) came about because people don't know what the hell a Universal Resource Locator is.
Most people don't know how to navigate their local file system, let alone the internet.
Yes. To dig a bit, they don't know because platform providers have pushed the net in that direction for decades.
AOL keywords were thing. Then fancy domain names that don't sound like domain names. Then search keywords. Then hashtags etc. The goal has always been to not ask the customer to think about it and just get to businesses.
> Universal Resource Locator
The U stands for "uniform". Which kinda supports your point, actually.
I guess that's showing my age, URI used to stand for Universal Resource Identifier which URL derives from.
https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Re...
>The publication of IETF RFC 2396 in August 1998 saw the URI syntax become a separate specification and most of the parts of RFCs 1630 and 1738 relating to URIs and URLs in general were revised and expanded by the IETF. The new RFC changed the meaning of U in URI from "Universal" to "Uniform."
I think that’s part of it. I love URLs (and URIs). Another big part is the predominance of closed social media platforms where the concept of a URL is mostly irrelevant
The one that says "Search" in it?
You’d be surprised how many folks don’t turn up their font size when they have bad vision
You'd be surprised how hard adjusting font sizes in UI elements can be.
It should not need to be, if designed well. For example, the operating system facilities could make it that UI sizes will be specified by character size instead of by pixels, and then the operating system facilities can allow the user to adjust the UI fonts, so that any programs could use them.
I have them separated in firefox because i find it superior.
Me too. I search through both URL bar and search bar, and sometimes I use the search bar as a scratchpad of sorts – very convenient IMO.
Agreed. When I go to modify my searches after clicking through a few pages and realizing I'm not getting what I need, I don't have to hit back n times until I get back to the search.
The alternative would be always opening search results in a new tab until I find what I'm looking for, but I don't need more tab clutter.
I have it too, but unfortunately this only gives you two search boxes, behavior of the url bar doesn't change.
I'm pretty sure that you can fully disable search in the URL bar by changing 'browser.fixup.alternate.enabled' to false
I think that it does not need a separate area of the screen reserved for searching, but that there should be an explicit way to indicate that you want to search. For example, this could be a popup window. Unlike the URL, which it is useful to be displayed even if you are not entering a new URL, this is not necessary for entering search queries, so using a popup window for this purpose may be helpful.
I had managed to make a old version of Firefox to treat URLs entered in the location bar as relative. In my opinion, this is the reasonable way to work. The computer doesn't have to guess what you mean, and does not have to guess if the TLD is valid. It will do what you typed into the computer; and if it is an error, will display the error message.
For searching, I had done that if you put a colon at first and then the name of the search engine, then it will search.
No, everyone loves it. By everyone I mean the vast majority of the world.
The fact of the matter is most people do not grok addresses, so a dedicated address bar is useless to them. It's bad user interface design that defies what most people can do.
Here's how most people actually use a web browser if they want to go somewhere, say Amazon:
1. Type "amazon".
2. Enter.
3. First result is (probably) amazon.com.
4. Click.
5. ????
6. PROFIT!
In the dark ages this was facilitated by setting the home page to a search engine like Google, changing the address bar to a search bar removes that additional step making it that much easier for the common man.
Is it horrible for security and privacy? Yeah. But you write a web browser for users, not security and privacy nazis.
> nazis
Could we please not use such a term for privacy/security conscious people? Maybe it’s because I am German but I feel very uncomfortable being called such.
[flagged]
It does break user expectation.
1. Type "mycompany-internal-gitlab".
2. Enter.
3. The expected thing should happen.
From TFA:
Can’t you usually force it to skip the search by prefixing with the schema? Certainly if I type in http://example.internal and press enter, I would be very displeased to have that turn into a Google search regardless of whether the part after the // fits some regex or whatever else internal to the browser.
Right, considering that single-label names (indistinguishable from search queries) have been a thing since WINS/NetBIOS, DHCP suffixing, etc. -- expecting a dot (let alone a dot followed by a public suffix) is bogus.
Well, that wouldn't work with most search queries then. Do you really want to (fail to) load http://facebook/ when somebody types "facebook" into the address bar?
I agree most people wouldn't want that. We're talking about typing the scheme in this particular comment thread, however. Most people who type a scheme followed by a single-label name (e.g., "http://facebook") are not intending to submit a query to a search engine, so it's good that browsers don't use the lack of dot as a search heuristic in such cases.
Adding a trailing / does it as well.
But if it's url, e.g. cia.internal/spies/008/johndoe, it's sent to search again.
Actually, entering _anything_ that looks like a FQDN should automatically bypass search in any browser. It’s been a long-standing pain of mine that when browsers merged the URL and search fields it became impossible to type “home.lan” (or .local, or .internal) and have it just work without stomping out http:// in front.
Also one of the reasons I seriously appreciate Firefox, because you can still have a dedicated search box to the right side of the URL entry field/address bar, and easily reach it by hotkey by command-K on MacOS or other similar shortcuts on Linux, Windows.
The number of times I've typed some internal-only thing or raw IP address into a browser and had it go to a search page instead of the thing I want to talk to, I've lost track of in the past 15 years, and it's too damn high.
I find auto-complete adding to this annoying behavior. It's (nearly) broken the 'view-source:' functionality in Chrome on Android
it's the deliberate dumbing down of the computer to the ordinary user, in the name of ease of use.
Whether intentional malice, or unintentional incompetence is moot by now. The effect has already been done.
As a workaround you can type a trailing slash: example.internal/
example.internal. should also work.
In the comments.
>Firefox does this correctly
Perfect.
For me it needs additional setting keyword.enabled=false
The first thing I do after installing a web browser is disable search for the URL bar.
The other thing I do is disable history. I forget the flag in Firefox (might be places.history.enabled or something). Forward and backward navigation still work per tab, but nothing gets recorded in the history menu. Every once in a while I wished I could go back into my history, but overall I prefer not to leave a log of what pages I've been to.
How?
Is that even possible? I agree that it should be the default behavior.
..maybe I can set up an own mock search service on localhost. Hmph, I will think about it
afaik you can use prefix to explicitly do search. for example no direct search but you can use "g paris" to search for paris on google or "w paris" to search paris on wikipedia
The whole local development is still a big mess. I recently starting using
http://subdomain.localhost
to keep different projects apart during development only to realize that you can't make that work with OAuth, because you can't use http://subdomain.localhost as a Oauth callback host. But you also can't share cookies between subdomain.localhost and localhost to redirect back without losing the session.
Nothing stopping you from redirecting a code response redirect from the authorization server. Have a shim server return 302 from `http://localhost/subdomain/oauth?code=...` to `http://subdomain.localhost/oauth?code=...` for example.
Need to try this.
I don't think there's an oauth requirement where those don't work and your issue is more likely to be with the provider itself and restrictions they make on http or local domains. I'd either run an nginx proxy to get around http or choose some domains that don't conflict with their local restrictions. You can add whatever domain you want to a hosts file that resolves to your local IP. I leverage this a lot.
Any competent provider should give you some method for local testing and you should work with them given the provider you've chosen.
Azure/Microsoft certainly do not support anything but http://localhost/...
Also a good argument for, if you run internal-network only resources, to purchase and use an actual domain for it (such as companyname.us or whatever).
Publish a zone file for the domain as authoritative master and secondary on an internet facing DNS server, but have basically no records in the zone (no useful A or CNAME or anything else).
Host the actual DNS for your internal services on your internally-accessible-only DNS server.
Also can use DNS validation with Let’s Encrypt this way!
Per Wikipedia:
> As of October 18, 2024, the domain has not been standardized by the Internet Engineering Task Force (IETF), though an Internet-Draft describing the TLD has been submitted.
I gotta say, I didn't like when Google grabbed .dev, but now I like having a .dev domain =)
Dev is HSTS preloaded and thus can't be used for internal http services as .internal can.
Having trouble not attributing to malice that which is adequately explained by stupidity here...
For Home Assistant for instance, the only reasonable option is .internal - its default .local is not the right TLD to use. [1]
[1]: https://serverfault.com/a/937808
Isn't .local specific to 'rendezvous' tech anyway? I forget the generic name but it was Apple that put it on the map under this name. But I mean that serverless broadcast protocol.
What I do is I just bought a domain and use that together with DNS-based SSL. It's a bit hard to set up with every different SSL server but it's doable.
The non Apple name is multicast DNS or mDNS. mDNS is exclusive to .local, but not necessarily the other way around. From its Wikipedia entry:
"By default, mDNS exclusively resolves hostnames ending with the .local top-level domain. This can cause problems if .local includes hosts that do not implement mDNS but that can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes that mDNS was designed to avoid."
Per https://www.iana.org/assignments/special-use-domain-names/sp... and https://www.rfc-editor.org/rfc/rfc6761.html .local. is only for mDNS, but as with any other name you can always misuse it (see .corp. .dev. etc.).
I notice .alt. now exists.
There’s mDNS, zeroconf, and Bonjour.
https://en.wikipedia.org/wiki/.local
Rendezvous = Bonjour = Multicast DNS Service Discovery
> its default .local is not the right TLD to use
What if you advertise it on mDNS?
Hanlon's razor is malicious. Assuming malice is the trivial right choice. Assuming stupidity just bc it rhymes, or bc you can feel smart about yourself is stupid.
Is the motivation known for this change? Any clue from commit history?
There has not been a change, it's always worked like this. ICANN only reserved *.internal for use in internal networks a few months ago.
This. I suppose they use a list of TLDs to check if something looks like a domain, and .internal is not on the list and needs to be hardcoded.
safari also does the same thing
[dead]