Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map constructor should fail if WebGL init fails. #6744

Merged
merged 1 commit into from
Jun 1, 2018

Conversation

uforic
Copy link
Contributor

@uforic uforic commented May 25, 2018

Description

Currently, it's possible for the constructor to complete successfully but the painter not be defined.

This is because setupPainter doesn't throw an exception, but instead emits an ErrorEvent. The problem is that in the constructor() call, no listeners have been set up yet, so the user wouldn't be able to listen to this error and respond appropriately.

Later on, resize events cause the map to error, because painter.resize doesn't exist.

I'm open to suggestions, like:

  • it's possible this is desired behavior
  • right now, this would throw an error, and _setupPainter would emit an error event. we may want to dedupe this.
  • this could actually be a bug in mapboxgl.isSupported(). We are checking this before instantiating the map, however, the _setupPainter call is still failing. Perhaps there are additional checks mapboxgl.isSupported should be making.

Keep me posted,
Thanks!

Error logs

Error seen on Sentry:
Cannot read property 'resize' of undefined

This is occurring in the constructor.

@uforic
Copy link
Contributor Author

uforic commented May 29, 2018

Update - the inability to create a painter causes an error later on in construction, it's just the wrong error; the error it later creates is:

Cannot read property 'resize' of undefined

From this code (in Sentry):

      const attemptedMap = new mapboxgl.Map({
        container: this.mapRef.current,
        style: this.getMapStyle(),
        center: initialCenter,
        zoom: initialZoom,
      });

Regardless, I'd argue we want to return the right error here (thrown from the right spot), not the wrong one.

Copy link
Contributor

@jfirebaugh jfirebaugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Fixes #2945.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants