Bing Streetside shows white box

[boothym]

Recently Bing Streetside has been showing a white box when you click on one of the blue dots. The following error is in the console (the second error only appeared when I ticked the high resolution box). If I click on the "view on bing maps" then I can see it on bing.com without any problems.

[dobatovkin]

I'm having the same problem. Noticed that it affects mainly new (2019-2021) pictures and doesn't affect old ones (2014-2015).

[DujaOSM]

It might be caused by a different Firefox extension, check out #9211.

[boothym]

@DujaOSM I'm using Chrome so...

[AnonymousAlligatorOSM]

I'm getting this error in the console:

Which looks like it's referring to this line of code:

iD/modules/services/streetside.js

Line 285 in e66edcb

let canvas = document.getElementById('ideditor-canvas' + data[0].imgInfo.face);

[1ec5]

Which looks like it's referring to this line of code:

Thanks for pinpointing the error. This is the callback for a request to https://dev.virtualearth.net/mapcontrol/HumanScaleServices/GetBubbles.ashx . All the items in data look like this:

{
  "data": {
    "face": "01",
    "url": "https://t.ssl.ak.tiles.virtualearth.net/tiles/hs1003022022233211010.jpg?g=6338&n=z",
    "x": 0,
    "y": 0
  },
  "status": "error"
}

Each of these image URLs returns HTTP 200 with an empty response body.

As microsoft/MicrosoftStreetsidePlugin#8 shows, this issue is not specific to any extension or browser, but it is limited to the newer images that Microsoft has sourced from TomTom.

This article from the other day documents an official API for getting Streetside images and metadata. This support answer confirms that the “bubble” API endpoint we’re hitting is unsupported:

iD/modules/services/streetside.js

Line 20 in cb12028

const bubbleApi = 'https://dev.virtualearth.net/mapcontrol/HumanScaleServices/GetBubbles.ashx?';

[boothym]

There's been changes made in RapiD by @bhousel to apparently fix this issue: facebook/Rapid@602cb77 - can the same be done for iD?

[tyrasd]

I've applied the workaround used in RapiD… It's not really a good solution, because we should actually replace the undocumented API calls with Bing streetview's v8 API (see #8747 (comment)). But it seems to do the job for now.

[1ec5]

406c1a0 works, but it does no good without a release (#9729). Over the past several months, I’ve had to show scores of new mappers how to work around this bug (or switch to Rapid) just to be able to contribute productively in an urban area where Mapillary and KartaView have insufficient side-facing coverage.