Updating from 2.9.7 -> 2.10.0 is breaking in Firefox

[cdcasey]

Is this a support request?
No

Describe the bug
When updating the library from 2.9.7 to 2.10.0, the features that were set to true no longer worked in Firefox. They still worked in Chrome & Safari.

To reproduce
Create an app with feature flags. Use version 2.10.0 of the SDK. In the LD dashboard, set the flagged features to true so that a user should see them when they visit the site.

Expected behavior
Features set to true should have been visible in Firefox. They were not.

Logs
There were warnings about default exports being deprecated in favor of named exports. I'm not sure if these warnings were relevant or not.

SDK version
2.10.0

Language version, developer tools
The app in question is a react app using react 16.8.6.

Additional Info
Reverting the library to 2.9.7 resolves the issue.

[eli-darkly]

Thanks for letting us know and sorry you've having this problem.

Am I right that you did not see any other log messages besides the "deprecated default exports" thing (which I can safely say is not related to this problem)?

Also, if you open the network tab in developer tools, do you see any successful or unsuccessful requests going to app.launchdarkly.com?

[cdcasey]

There is one error log message:
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”)

That's as detailed as it gets, though. Also, that message is still there even when using 2.9.7.

There are three requests: one OPTIONS and two GET, all 200s. None have response bodies.

[eli-darkly]

The GET does not have a response body? It's normal for an OPTIONS request not to have one, but it'd be quite odd if a successful GET did not. How about response headers for the GET? I'm grasping at straws because so far we have not been able to reproduce any kind of unexpected behavior in Firefox.

Also, what are the request URLs? (You can omit the part that is your environment ID)

[eli-darkly]

Oh, also, what version of Firefox?

[cdcasey]

I have been able to reproduce this behavior on Firefox versions 66.0b12 and 66.0.3.

More specifically, the response bodies for the GET requests are empty lists: [].

Note: the headers for below are for a local dev env, but I first noticed this behavior in an online staging environment.

The urls and response headers are identical for the two GETs:
https://app.launchdarkly.com/sdk/goals/<id>

HTTP/2.0 200 OK
content-type: application/json
access-control-allow-credentials: true
access-control-allow-headers: Accept,Content-Type,Content-Length,Accept-Encoding,Authorization,X-Requested-With,X-LD-Private,X-LD-AccountId,X-LD-EnvId,X-LD-PrjId,X-LaunchDarkly-Event-Schema,X-LaunchDarkly-User-Agent,LD-API-Version
access-control-allow-methods: OPTIONS, HEAD, GET
access-control-allow-origin: http://0.0.0.0:3000
access-control-max-age: 300
cache-control: max-age=0
content-encoding: gzip
accept-ranges: bytes
date: Mon, 22 Apr 2019 19:11:12 GMT
via: 1.1 varnish
x-served-by: cache-iah17249-IAH
x-cache: HIT
x-cache-hits: 1
x-timer: S1555960273.711368,VS0,VE0
vary: Accept-Encoding, Origin, Accept-Encoding
age: 0
content-length: 26
X-Firefox-Spdy: h2

[cdcasey]

It looks like on 2.9.7, there are still two GETs, but one is to https://app.launchdarkly.com/sdk/evalx/<same id as above>/users/<some other id>

[eli-darkly]

Thanks. Just to be clear, you said you are seeing two GET requests with the same URL, /sdk/goals, and a single OPTIONS request—for that same URL?

[eli-darkly]

Also, what if any custom configuration properties have you set?

[eli-darkly]

There isn't any chance that you have more than one client instance, is there? I'm having trouble seeing any code path that would allow the /sdk/goals request to be made more than once per client.

[cdcasey]

Correct on the one OPTIONS and two GET requests. I don't think we have any custom configuration properties set. There is definitely only one client instance.

[eli-darkly]

I'm sorry I haven't managed to reproduce this yet or come up with any theories, but I do have another question. Are you using the React wrapper that we provide, or just calling the regular JS SDK methods from React code?

[cdcasey]

The regular JS SDK. Thanks for keeping with this.

[eli-darkly]

I don't expect that this would make a difference, but if you have a chance, could you retest with the 2.10.1 release? It fixes a different browser compatibility issue, and I have already tested to verify that Firefox 66.0.3 did not suffer from that particular problem, but I'd like to be able to rule everything out since right now nothing is making sense.

[cdcasey]

Initial local testing indicates that the new version does, in fact fix the issue. I'll circle back after we've done more testing in our staging environment.

[cdcasey]

2.10.1 seems to have fixed the issue. Thank you.