4 ms·

I work for Google Search. Apologies for this! It’s been fixed now and posted to our search status dashboard https://status.search.google.com/incidents/hySMmncED

I work for Google Search. Apologies for this! It’s been fixed now and posted to our search status dashboard https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i32C https://status.search.google.com/incidents/hySMmncEDZ7Xpaf9i...

jedahan 3y ago
Would love to hear what the bug and/or fix was
- stephenr 3y ago
  I'm more interested in why ua sniffing is considered acceptable for this.
  - deleted 3y ago
    [deleted]
  - sangnoir 3y ago
    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)
    - 93po 3y ago
      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
      - sangnoir 3y ago
        > 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.
        junon 3y ago
        I think you've missed the point. Google's primary web search feature could, in theory, be implemented without a line of JavaScript. That's how it was years and years ago anyway.
        sangnoir 3y ago
        I did not miss the point, I gave an answer based on the ground-truth rather than theory. > Google's primary web search feature could, in theory, be implemented without a line of JavaScript ...and yet, in practice, Google defaults to a JavaScript-heavy implementation. Search is Google's raison d'être and primary revenue driver, I posit it therefore is optimized up the wazoo. I wouldn't hastily assume incompence given those priors.
        zugi 3y ago
        I use Firefox with the NoScript addon and google.com still works just fine.
        stephenr 3y ago
        The important word in the question you quoted is needed. Google homepage is 2MB. Two fucking megabytes. Without JS, it's 200K. I can't be the only person who remembers when Google was known for even omitting technically optional html tags on their homepage, to make it load fast - they even documented this as a formal suggestion: https://google.github.io/styleguide/htmlcssguide.html#Optional_Tags https://google.github.io/styleguide/htmlcssguide.html#Option...
        Kharacternyk 3y ago
        Thank you for the link. I had no idea about most of the optional tags. It looks ugly when taken to extremes, though.
      - j5155 3y ago
        Google is an advertising company. I’m sure they’re collecting quite a bit more then just your text input
        93po 3y ago
        Of course, that's why there's 1.8MB of compressed JavaScript for a text box and an image. My point being that's it's silly and I'm exasperated with the state of the internet
    - stephenr 3y ago
      2002 called and they want their terrible development practices back.
    - stephenr 3y ago
      It's wild to think that everything we've collectively learned as an industry is being forgotten, just 20 years later. - We're on the verge of another browser monopoly, cheered on by developers embracing the single controlling vendor; - We already have sites declaring that they "work best in Chrome" when what they really mean is "we only bothered to test in Chrome". - People are not only using UA sniffing with inevitable disastrous results, they're proclaiming loudly that it's both necessary and "the best" solution. - The amount of unnecessary JavaScript is truly gargantuan, because how else are you going to pad your resume? I mean really what's next? Are we going to start adopting image slice layouts again because browsers gained machine vision capabilities?
      - cuddlyogre 3y ago
        We're also back to table layouts with grid, albeit a lot more usable this time around.
        kedean 3y ago
        I don't recall that there was ever anything inherently wrong with using tables for layout, except that it was a misuse of tables so we were told it wasn't "semantic". Thus you had years of people asking on forums how to emulate tables using a mess of floating divs until flexbox/grid came around. In retrospect, tables are also clearly incompatible with phone screens, but that wasn't really a problem at the time.
        nolok 3y ago
        One, it made the code unreadable and impossible to maintain properly, especially since most of those table where generated straight out of photoshop or whatever. Two, it was an accessibility nightmare. At least modern grid design fix those
      - sangnoir 3y ago
        > People are not only using UA sniffing with inevitable disastrous results, they're proclaiming loudly that it's both necessary and "the best" solution. Since you're replying to my comment and paraphrasing a sentence of mine, I'm guessing I'm "people". I'm curious to hear from you on what - if any - is a better alternative that can be used to determine the browser identity or characteristics (implied by name and version) on the server side? "Do not detect the browser on the server side" is not a valid answer; and suggests to me the person proffering it as an answer isn't familiar with large-scale development of performant web-apps or websites for heterogenous browsers. A lot of browser inconsistencies have to be papered over (e.g. with polyfills or alternative algorithms implementations), without shipping unnecessary code to browsers that don't need the additional code. If you have a technique faster and/or better that UA sniffing on the server side, I'll be happy to learn from you. "Do feature JavaScript feature detection on the client" is terrible for performance if you're using it to dynamically load scripts on the critical path.
Uptrenda 3y ago
It's ok, sure it's stressful when something like this happens. Software is a hard field and the amount of things that can go wrong is immense. When I think about how few errors and downtime some of the larger services have I realize how much work must be involved.
- code_biologist 3y ago
  I'd divide "things going wrong" into forced and unforced errors. Your upstream service providers sending subtly malformed data is a forced error. It happens. Doing user agent sniffing for presentation, poorly, is an unforced error. It's not amateurish to have problems. It is amateurish (or malicious) to have problems caused by this specific class of issue.
QuinnyPig 3y ago
Fortunately, the issue was reported in the proper / only place to get support from Google: the front page of Hacker News.
- lovelyviking 3y ago
  And what approach would be effective to get any buttons work on login page of ChatGPT? In IOS 14 ‘ login’ button simply does nothing regardless of the browser. It’s been reported and yet last time I’ve checked it doesn’t work. It’s more than two months already and as it seems simply no body give a sh….
- rtsil 3y ago
  Thank god for procrastination!
- emeril 3y ago
  LOL

jedahan 3y ago

Would love to hear what the bug and/or fix was

stephenr 3y ago
I'm more interested in why ua sniffing is considered acceptable for this.
- deleted 3y ago
  [deleted]
- sangnoir 3y ago
  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)
  - 93po 3y ago
    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
    - sangnoir 3y ago
      > 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.
      - junon 3y ago
        I think you've missed the point. Google's primary web search feature could, in theory, be implemented without a line of JavaScript. That's how it was years and years ago anyway.
        sangnoir 3y ago
        I did not miss the point, I gave an answer based on the ground-truth rather than theory. > Google's primary web search feature could, in theory, be implemented without a line of JavaScript ...and yet, in practice, Google defaults to a JavaScript-heavy implementation. Search is Google's raison d'être and primary revenue driver, I posit it therefore is optimized up the wazoo. I wouldn't hastily assume incompence given those priors.
        zugi 3y ago
        I use Firefox with the NoScript addon and google.com still works just fine.
      - stephenr 3y ago
        The important word in the question you quoted is needed. Google homepage is 2MB. Two fucking megabytes. Without JS, it's 200K. I can't be the only person who remembers when Google was known for even omitting technically optional html tags on their homepage, to make it load fast - they even documented this as a formal suggestion: https://google.github.io/styleguide/htmlcssguide.html#Optional_Tags https://google.github.io/styleguide/htmlcssguide.html#Option...
        Kharacternyk 3y ago
        Thank you for the link. I had no idea about most of the optional tags. It looks ugly when taken to extremes, though.
    - j5155 3y ago
      Google is an advertising company. I’m sure they’re collecting quite a bit more then just your text input
      - 93po 3y ago
        Of course, that's why there's 1.8MB of compressed JavaScript for a text box and an image. My point being that's it's silly and I'm exasperated with the state of the internet
  - stephenr 3y ago
    2002 called and they want their terrible development practices back.
  - stephenr 3y ago
    It's wild to think that everything we've collectively learned as an industry is being forgotten, just 20 years later. - We're on the verge of another browser monopoly, cheered on by developers embracing the single controlling vendor; - We already have sites declaring that they "work best in Chrome" when what they really mean is "we only bothered to test in Chrome". - People are not only using UA sniffing with inevitable disastrous results, they're proclaiming loudly that it's both necessary and "the best" solution. - The amount of unnecessary JavaScript is truly gargantuan, because how else are you going to pad your resume? I mean really what's next? Are we going to start adopting image slice layouts again because browsers gained machine vision capabilities?
    - cuddlyogre 3y ago
      We're also back to table layouts with grid, albeit a lot more usable this time around.
      - kedean 3y ago
        I don't recall that there was ever anything inherently wrong with using tables for layout, except that it was a misuse of tables so we were told it wasn't "semantic". Thus you had years of people asking on forums how to emulate tables using a mess of floating divs until flexbox/grid came around. In retrospect, tables are also clearly incompatible with phone screens, but that wasn't really a problem at the time.
        nolok 3y ago
        One, it made the code unreadable and impossible to maintain properly, especially since most of those table where generated straight out of photoshop or whatever. Two, it was an accessibility nightmare. At least modern grid design fix those
    - sangnoir 3y ago
      > People are not only using UA sniffing with inevitable disastrous results, they're proclaiming loudly that it's both necessary and "the best" solution. Since you're replying to my comment and paraphrasing a sentence of mine, I'm guessing I'm "people". I'm curious to hear from you on what - if any - is a better alternative that can be used to determine the browser identity or characteristics (implied by name and version) on the server side? "Do not detect the browser on the server side" is not a valid answer; and suggests to me the person proffering it as an answer isn't familiar with large-scale development of performant web-apps or websites for heterogenous browsers. A lot of browser inconsistencies have to be papered over (e.g. with polyfills or alternative algorithms implementations), without shipping unnecessary code to browsers that don't need the additional code. If you have a technique faster and/or better that UA sniffing on the server side, I'll be happy to learn from you. "Do feature JavaScript feature detection on the client" is terrible for performance if you're using it to dynamically load scripts on the critical path.

Uptrenda 3y ago

It's ok, sure it's stressful when something like this happens. Software is a hard field and the amount of things that can go wrong is immense. When I think about how few errors and downtime some of the larger services have I realize how much work must be involved.

code_biologist 3y ago
I'd divide "things going wrong" into forced and unforced errors. Your upstream service providers sending subtly malformed data is a forced error. It happens. Doing user agent sniffing for presentation, poorly, is an unforced error. It's not amateurish to have problems. It is amateurish (or malicious) to have problems caused by this specific class of issue.

QuinnyPig 3y ago

Fortunately, the issue was reported in the proper / only place to get support from Google: the front page of Hacker News.

lovelyviking 3y ago
And what approach would be effective to get any buttons work on login page of ChatGPT? In IOS 14 ‘ login’ button simply does nothing regardless of the browser. It’s been reported and yet last time I’ve checked it doesn’t work. It’s more than two months already and as it seems simply no body give a sh….
rtsil 3y ago
Thank god for procrastination!
emeril 3y ago
LOL