Earlier quoted context omitted.
> ... We have a bad fame. HN is too orange.
I switched it to the same color gray as the background. HN actually provides a pref for this in your user settings.
A perk for gaining a certain amount of karma.
www.google.com – The page is blank when accessed
261–270 of 320 posts
Re: www.google.com – The page is blank when accessed
#262Earlier quoted context omitted.
This level of condescension isn’t helpful, especially as you’re wrong to make such an absolute assertion rather than describing the right or wrong reasons to use a tool. UA sniffing should be a last resort but there have been times where browsers have claimed to support something but had hard to detect bugs and the cleanest way to handle it was to pretend the feature detection failed on those older browsers. This is…
You proved my (overly condescending) point. You either support older TLS or you don't. Do not try to fine tune it to one known audience. You just locked everyone that is not in the sample you just whitelisted(!) out of your service. But you don't know about them, so no harm? If you think one use case for tls1.1 is OK for one use case, just accept you support it. Same for every thing else. Every time you use UA sniff,…
That not proving anything other than that you missed the point that the real world doesn’t always have simple solutions. Sometimes you have to do things which are a bit messy as part of a phased transition and it’s important to know what tools you have available to do so.
Re: www.google.com – The page is blank when accessed
#263Re: www.google.com – The page is blank when accessed
#264This reminds me of a blog post a former exec of Mozilla put out saying Google had been intentionally breaking things to get users to jump ship to Chrome. https://news.ycombinator.com/item?id=38349357
Is that what you think happened here? Google made the search page blank for Firefox users to get them on Chrome? Or perhaps it's the work of Hanlon's razor.
There isn't a good reason to UA sniff. I run Firefox serving a Chrome UA as my daily driver, and never run into any issues. The reason I started this nonsense was because of a few sites that completely falsely asserted they needed Chrome to run properly, aka the only issue was the fact that they looked at the user-agent string.
Not to mention the fact that this is google.com, not some wild feat of frontend engineering. They shouldn't be serving any JS that wouldn't run on IE, forget anything close to a modern browser.
Re: www.google.com – The page is blank when accessed
#265Earlier quoted context omitted.
I think bingchat is more likely to be what eventually supplants google. They funded the ai that created the garbage autogen pages, now they can use more ai to solve it for you in exchange for the low low price of your attention. Tesla will likely supplant google maps any day now when they release an offering. People pay tesla to drive cameras with computer vision around. Google has plenty of altitude and time to corr…
> Tesla will likely supplant google maps any day now when they release an offering. An offering of what?
Their own maps apparently?
Re: www.google.com – The page is blank when accessed
#266Earlier quoted context omitted.
I'm more interested in why ua sniffing is considered acceptable for this.
On the server-side, parsing the UA string is the best & fastest way to figure out which browser is on the other end or the connection. This can need to happen before you load any JS - this is commonly used to decide which JS bundles to load. When put under the microscope, browser have inconsistent behaviors and occasional regressions from version to version (e.g. performance with sparse arrays)
How much JavaScript is needed to accept my text input and provide auto complete options? Pretty wild we need to worry about browser compatibility to do this
Re: www.google.com – The page is blank when accessed
#267Earlier quoted context omitted.
(I work on WebCompat at Mozilla) There are various people whose job involves triaging issues filed on that repo, and communicating with the issue authors where necessary e.g. to figure out additional steps required to reproduce the reported problem. The point of that effort is exactly because we value reports of site breakage so highly, and want to ensure that people reporting them have a good experience. Unfortunate…
Nah, that's bullshit. If someone interacts with your team on whatever medium you go out of your way to be respectful and shouldn't act like stuck up, condescending neckbeards, whose presence is a gift to humanity. I run many open source repos myself and you can bet that when people take the trouble to interact with me I make it my mission to listen to what they say and treat them with respect. I don't expect them to…
> I run many open source repos myself and you can bet that when people take the trouble to interact with me I make it my mission to listen to what they say and treat them with respect.
You clearly look like a very polite person /s
Re: www.google.com – The page is blank when accessed
#268Earlier quoted context omitted.
What I don’t understand is why this isn’t just a rollback, or at worst a revert commit and redeploy. I can forgive an issue with a slightly obscure browser, but the fix should be trivial for Google engineers?
It appears that the problem is related to the version string transmitted by Firefox Mobile. If they were to send an older user agent string, the issue would likely be resolved. However, any rollback would need to be implemented by Firefox, and it seems they are not at fault here. From Google's standpoint, this issue may be considered a "new" bug, which means they need to conduct an investigation and address it. Conse…
Why would Firefox have to "rollback" their UA string back to version 64, released 6 years ago (2018)? That seems utterly ridiculous for a server side UA sniffing bug rolled out by the Google Search Team.
Re: www.google.com – The page is blank when accessed
#269Earlier quoted context omitted.
I'm more interested in why ua sniffing is considered acceptable for this.
On the server-side, parsing the UA string is the best & fastest way to figure out which browser is on the other end or the connection. This can need to happen before you load any JS - this is commonly used to decide which JS bundles to load. When put under the microscope, browser have inconsistent behaviors and occasional regressions from version to version (e.g. performance with sparse arrays)
2002 called and they want their terrible development practices back.
Re: www.google.com – The page is blank when accessed
#270Earlier quoted context omitted.
On the server-side, parsing the UA string is the best & fastest way to figure out which browser is on the other end or the connection. This can need to happen before you load any JS - this is commonly used to decide which JS bundles to load. When put under the microscope, browser have inconsistent behaviors and occasional regressions from version to version (e.g. performance with sparse arrays)
How much JavaScript is needed to accept my text input and provide auto complete options? Pretty wild we need to worry about browser compatibility to do this
> How much JavaScript is needed to accept my text input and provide auto complete options?
If you're talking about Google's homepage, the answer is "a lot". You can check for yourself - go to google.com, select "view source" and compare the amount of Closure-compiled JavaScript against HTML markup.