TileMapServiceImageryProvider defaults can cause the browser to hang. #8448
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi all, we came across this exciting state a while back where the browser would just hang because of a bad imagery provider configuration.
Here's a sandcastle which will almost hang the browser. If you increase the
minimumDetail
to >=9 and run it again, you're in trouble.And here's the code from the sandcastle for reference:
Basically what's happening here is we've got a TMS layer configuration that's forcing the minimum detail level to 7 (for whatever reason), but not providing the rectangle. I understand that's probably not a good start, but I think the use case is still valid (as explained in the code comments).
Then what happens is the
tilemapresource.xml
request for the imagery provider fails, and the failure path currently uses some default values and continues on.So, if you have minimum detail set to something >= ~9, and the metadata request fails, then you end up with a config of:
bounding-box: the whole globe (cesium failure path default)
minimum-detail: 9 (static config passed by user which trumps the defaults)
This just causes way too many tiles to be requested, and the browser locks up for a very long time.
This PR fixes this issue by just rejecting the
readyPromise
if the metadata request fails, but there's obviously a bunch of other ways to fix it too, that's just the fix we're currently using ourselves and it's working fine.Other ways I could think of were:
The reason I've opted for this solution is that it brings the
TileMapServiceImageryProvider
inline with the otherImageryProviders
that also request some kind of metadata.ArcGisMapServer - fails
GoogleEarth - fails
BingMaps - fails
...plus some more
Apologies for the changing the tests so much, but it's really just removing some duplication since most of the tests were previously relying on this behaviour I've now changed, so there's nothing too exciting going on there.
Cheers! 👍 😄