fix(core, web): load firebase-app.js before component bundles to avoid WebKit import race

[Yusufihsangorgel]

Description

Fixes #18436.

On Flutter web, Firebase.initializeApp() intermittently throws ReferenceError: Cannot access 'SDK_VERSION' before initialization in WebKit-based browsers (Safari, WKWebView, and every iOS browser), leaving apps that await it before runApp() on a blank page. The linked issue includes production Sentry data: 968 events across 941 users in ~2 months, 100% of them WebKit.

Root cause

_initializeCore() injects one script per registered service and awaits them all in parallel with Future.wait. Each injection performs a dynamic import(), and every component bundle (firebase-auth.js, firebase-messaging.js, …) statically imports from the shared firebase-app.js. With N services registered, N concurrent dynamic imports converge on that shared module, and WebKit has a long-standing module-evaluation defect in exactly this situation: it can hand back a namespace whose top-level bindings are still in the temporal dead zone. Reading firebase.SDK_VERSION right afterwards then throws. V8 and SpiderMonkey evaluate the shared dependency correctly, which matches the zero non-WebKit events in the report.

Fix

Load firebase-app.js (the core service) first and only then fan out to the component bundles in parallel — option 3 from the issue. This keeps the parallel loading of component bundles (no measurable startup cost) while guaranteeing the shared dependency has fully evaluated before any dependent bundle's import starts, which removes the race entirely.

The per-service injection logic is unchanged — it is only extracted into a local injectService closure so the core service and the remaining services go through the identical path.

Testing

• dart analyze and dart format clean.
• flutter test --platform chrome passes (existing Trusted Types + exception suites).
• The race itself is probabilistic WebKit-only startup behavior and isn't reproducible in the unit harness; the fix makes the ordering deterministic by construction (a dependent bundle's import can no longer start before firebase-app.js has evaluated).

Related Issues

Fixes #18436 (likely also the root cause behind the older WebKit reports #13107 / #11243).

Checklist

• I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
• My PR includes a description of the change / issue fixed.
• All existing and new tests are passing.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

[SelaseKay]

Hi @Yusufihsangorgel, thanks for the contribution and detailed description. LGTM!