Google Maps just fucking SUCKS now

[dlsterner]

In Google Maps the scroll wheel used to zoom in or out.  Has anyone else noticed that it has stopped doing that?  I can still zoom in or out by clicking on the + or - buttons in the corner.

Yes, it happened to me as well.  It looks like it might be browser dependent.

I normally use Safari (15.3) and my mouse wheel quit working last night for zoom.  Quit Safari, loaded Firefox (98.0.2) and the mouse wheel seems to work fine.  Went back to Safari, mouse wheel worked for about a minute, then quit (the mouse wheel, not Safari itself).

What browser are you using?

[kkt]

In Google Maps the scroll wheel used to zoom in or out.  Has anyone else noticed that it has stopped doing that?  I can still zoom in or out by clicking on the + or - buttons in the corner.

Yes, it happened to me as well.  It looks like it might be browser dependent.

I normally use Safari (15.3) and my mouse wheel quit working last night for zoom.  Quit Safari, loaded Firefox (98.0.2) and the mouse wheel seems to work fine.  Went back to Safari, mouse wheel worked for about a minute, then quit (the mouse wheel, not Safari itself).

What browser are you using?

Safari.
Not too excited about having to install another browser just to make Google Maps work.

[hotdogPi]

Bugs like this (e.g. measure distance tool a few months ago) typically get fixed within 3 days or even earlier.

[dlsterner]

In Google Maps the scroll wheel used to zoom in or out.  Has anyone else noticed that it has stopped doing that?  I can still zoom in or out by clicking on the + or - buttons in the corner.

Yes, it happened to me as well.  It looks like it might be browser dependent.

I normally use Safari (15.3) and my mouse wheel quit working last night for zoom.  Quit Safari, loaded Firefox (98.0.2) and the mouse wheel seems to work fine.  Went back to Safari, mouse wheel worked for about a minute, then quit (the mouse wheel, not Safari itself).

What browser are you using?

Safari.
Not too excited about having to install another browser just to make Google Maps work.

I wouldn't be either, as I have my Safari configuration just right, as far as bookmarks and the like.

But as 1 suggested above, these are the kind of bugs that are usually fixed pretty quickly, so I will try to tough it out.

[dlsterner]

OK, here is an update on the Google Maps & scroll wheel problem when using Safari ...

It's not just us - there is a lot of chatter online about this not working for the past day or so.  The consensus seems to point to a Google issue where it isn't playing nice with Safari.

There is a workaround mentioned:

-   If your "Develop" menu in the menu bar is not visible, make it visible by going to "Preferences"->"Advanced".  There is a check box to turn on the "Develop" menu.
-   At the "User Agent" sub-menu (2nd one in the "Develop" menu) change the User Agent from Safari to Firefox or Chrome.  (You will still be running Safari, but it will lie to anyone who asks and say it is Firefox/Chrome)

The scroll wheel should now work.  Please note that this fix is a "Band-Aid" and that hopefully it will get fixed for real (presumably by Google).  In the long term, you will want to keep it at Safari.

[Scott5114]

Why the fuck would you check the browser string to see if you can take away a feature?

[J N Winkler]

Why the fuck would you check the browser string to see if you can take away a feature?

In some cases I've seen it used seemingly to deny resources to tools like wget and curl that are designed to support unattended downloading.

[Scott5114]

Why the fuck would you check the browser string to see if you can take away a feature?

In some cases I've seen it used seemingly to deny resources to tools like wget and curl that are designed to support unattended downloading.

That's even sillier, because it presupposes there's a broad base of potential users out there that know enough about the command line to successfully compose and execute a curl command, but have never been exposed to documentation of the --user-agent flag.

[kkt]

OK, here is an update on the Google Maps & scroll wheel problem when using Safari ...

It's not just us - there is a lot of chatter online about this not working for the past day or so.  The consensus seems to point to a Google issue where it isn't playing nice with Safari.

There is a workaround mentioned:

-   If your "Develop" menu in the menu bar is not visible, make it visible by going to "Preferences"->"Advanced".  There is a check box to turn on the "Develop" menu.
-   At the "User Agent" sub-menu (2nd one in the "Develop" menu) change the User Agent from Safari to Firefox or Chrome.  (You will still be running Safari, but it will lie to anyone who asks and say it is Firefox/Chrome)

The scroll wheel should now work.  Please note that this fix is a "Band-Aid" and that hopefully it will get fixed for real (presumably by Google).  In the long term, you will want to keep it at Safari.

Hey, what do you know, it works!  I changed it to advertise I'm using Firefox, and quit and restarted Safari, and now my zoom wheel is back.  Thank you!

Yes, for tech companies sabatoging each other for no obvious reason is part of the game.

[CoreySamson]

I'm noticing that freeways and major arterials have a new, more opaque yellow color on satellite views at certain zoom levels:



Thoughts?

[MATraveler128]

I noticed a glitch when it comes to Street View on iOS. When I go to drop a pin on a road, the Street View image won't appear. But it will appear sometimes. In this case I have to press Street View in the map details menu. Anyone else having this problem?

[jakeroot]

I'm noticing that freeways and major arterials have a new, more opaque yellow color on satellite views at certain zoom levels:



Thoughts?

I was waiting to see if someone would notice this too (if it was just me or what). So far, I like it.

I noticed a glitch when it comes to Street View on iOS. When I go to drop a pin on a road, the Street View image won't appear. But it will appear sometimes. In this case I have to press Street View in the map details menu. Anyone else having this problem?

I usually notice this after I've had a Google Maps tab open for a while.

[kurumi]

This has been happening for a while:

* search for a certain city or location
* go exploring on street view, often several miles distant
* press Escape to open map or satellite view in the spot you are now
* Google Maps moves you back to the original search spot instead

[LilianaUwU]

In Street View, I've noticed that the black square in the top left corner where the address and historical imagery slider is will sometimes not display the address at all, instead showing a default "Google" as the address. Not a big deal, but still an odd bug.

[CtrlAltDel]

This has been happening for a while:

* search for a certain city or location
* go exploring on street view, often several miles distant
* press Escape to open map or satellite view in the spot you are now
* Google Maps moves you back to the original search spot instead

This has been happening to me too, and I hate it.

[kphoger]

Oh yeah, I've been hating both of those issues lately.

[J N Winkler]

This has been happening for a while:

* search for a certain city or location

* go exploring on street view, often several miles distant

* press Escape to open map or satellite view in the spot you are now

* Google Maps moves you back to the original search spot instead

+1 for me on this issue, too.  X'ing out the search result avoids this problem, but that extra step is a hassle.

[CNGL-Leudimin]

In Street View, I've noticed that the black square in the top left corner where the address and historical imagery slider is will sometimes not display the address at all, instead showing a default "Google" as the address. Not a big deal, but still an odd bug.

And it will display the name of a business if in front of it. Odd.

[J N Winkler]

Why the fuck would you check the browser string to see if you can take away a feature?

In some cases I've seen it used seemingly to deny resources to tools like wget and curl that are designed to support unattended downloading.

That's even sillier, because it presupposes there's a broad base of potential users out there that know enough about the command line to successfully compose and execute a curl command, but have never been exposed to documentation of the --user-agent flag.

I've been thinking about this a little, and I suspect there is no one single motivation for resorting to user-agent checking.  I've observed the following:

*  Server responds to a request with a HTTP 400- or 500-series error (some variant of "You're not getting what you're asking for") if there is no user-agent header, but supplies actual content when such a header is present.  (This is common but by no means universal for the contracting platforms and EDMSes highway agencies use for distributing construction plans.)

*  Request hangs when sent with a user-agent header corresponding to an obsolete browser version, but returns actual content when the header references a current browser version or no user-agent header is used.  (I often see this with newspaper websites.)

In many cases, particularly the ones involving news sites, I think the user-agent header is used as a tool to avoid legal liability for providing content that is not accessible.

Recent versions of browsers like Firefox and Chrome have network listeners that track page loads and allow individual requests to be copied as curl invocations that include all headers.  When I use this functionality to write code for unattended downloading using either curl or wget, I try to keep things simple by pruning wget and curl invocations back to just the headers that are actually necessary for the request to go through.  In several cases I've found that it's actually the Accept-Language header that makes the difference (not, surprisingly, Accept or Accept-Encoding).  I've had one script break when, after several months of smooth runs, the server started demanding a different capitalization pattern for XMLHttpRequest headers.  In at least one case, a server wouldn't accept wget --post-data={postdata} or wget --post-file={path to file with postdata}, but would accept wget --method=POST --data={postdata} (method had to be explicitly specified).  In another, the server demanded use of the HTTP DELETE method (which I had never heard of!).

[vdeane]

Just curious, is there any knowledge on how the range of drive times for the "depart at" feature with directions is calculated?  I'm wondering if the long one, or at least the "arrive at" time (often but not always matching the long one) is the one where you don't drive faster than the speed limit, because the one it quotes for the "leave now" feature definitely isn't.

[Scott5114]

Just curious, is there any knowledge on how the range of drive times for the "depart at" feature with directions is calculated?  I'm wondering if the long one, or at least the "arrive at" time (often but not always matching the long one) is the one where you don't drive faster than the speed limit, because the one it quotes for the "leave now" feature definitely isn't.

I think it uses historical Waze data to calculate the approximate drive time depending on past traffic patterns for the specified time of day.

[jakeroot]

Just curious, is there any knowledge on how the range of drive times for the "depart at" feature with directions is calculated?  I'm wondering if the long one, or at least the "arrive at" time (often but not always matching the long one) is the one where you don't drive faster than the speed limit, because the one it quotes for the "leave now" feature definitely isn't.

I think it uses historical Waze data to calculate the approximate drive time depending on past traffic patterns for the specified time of day.

Mine seems to assume I go at least 15 mph over the limit at all times. I assume this because, after doing so, I arrive at exactly the ETA.

[Rothman]

Just curious, is there any knowledge on how the range of drive times for the "depart at" feature with directions is calculated?  I'm wondering if the long one, or at least the "arrive at" time (often but not always matching the long one) is the one where you don't drive faster than the speed limit, because the one it quotes for the "leave now" feature definitely isn't.

I think it uses historical Waze data to calculate the approximate drive time depending on past traffic patterns for the specified time of day.

Mine seems to assume I go at least 15 mph over the limit at all times. I assume this because, after doing so, I arrive at exactly the ETA.

The ETA adjusts as you travel.

[kphoger]

I've actually found that the Google Maps estimate doesn't like speed limits higher than about 70 mph.

For example, I can plot a trip on the Kansas Turnpike–speed limit 75 mph–that shows 100% green in the Traffic overlay, yet the math invariably works out to about 71 or 72 mph average.

[vdeane]

Just curious, is there any knowledge on how the range of drive times for the "depart at" feature with directions is calculated?  I'm wondering if the long one, or at least the "arrive at" time (often but not always matching the long one) is the one where you don't drive faster than the speed limit, because the one it quotes for the "leave now" feature definitely isn't.

I think it uses historical Waze data to calculate the approximate drive time depending on past traffic patterns for the specified time of day.

Yeah, I think so too.  What I'm wondering is if one of those times is the time for where it assumes you don't exceed the speed limit at any point - ie, not assuming you're going to go 65 in a 55 because that's what the Waze data has for the historical data for that section of road for that time/day.  The time Google quotes for "leave now" assumes that you're going to be going the speed of the historical traffic data, regardless of whether it goes faster or slower than the limit (I'm usually right on with my 5-7 over, but there are places where it seems to be too optimistic for my driving patterns, and obviously all the times would be wrong if I ever were to start adhering exactly to the limit, which I probably would if NY ever adopted 70 mph limits on rural freeways, especially if NJ, MA, VT, and the rest of NH did too).

This is all for planning future roadtrips on the desktop version, of course.  I only use the directions for trip planning travel time estimation and not turn by turn directions, so I have no idea what it would do for that.