dart-pad
dart-pad copied to clipboard
dart-lang
`Error loading AssetManifest.json` when trying to load google_fonts
What happened?
The google fonts aren't being loaded, most likely due to WidgetsFlutterBinding.ensureInitialized() not properly running from runApp.
Steps to reproduce problem
The simplest way to reproduce it is to just open the Padracing sample that can be found here: https://dartpad.dev/?id=ecabed4a17a3aad8bee7c6327e472fc8
Additional info
Browser
Browser: Firefox - 101.0b9 (64-bit) Chromium - 101.0.4951.64 (Official Build) Arch Linux (64-bit)
Are you using any extensions/plugins that affect website behavior (particularly those that affect iframes, such as ad blockers)?
Are there any warnings or errors in your browser's JavaScript console? If so, paste them below:
[paste warnings or errors here]
Machine
Running the current DartPad version in the browser (tried with Firefox and Chromium) with dev, beta and stable.
DartPad's output
In the DartPad concole:
Error loading AssetManifest.json. Please file an issue at https://github.com/material-foundation/google-fonts-flutter/issues/new/choose.
Error: google_fonts was unable to load font VT323-Regular because the following exception occured:
Binding has not yet been initialized.
The "instance" getter on the ServicesBinding binding mixin is only available once that binding has been initialized.
Typically, this is done by calling "WidgetsFlutterBinding.ensureInitialized()" or "runApp()" (the latter calls the former). Typically this call is done in the "void main()" method. The "ensureInitialized" method is idempotent; calling it multiple times is not harmful. After calling that method, the "instance" getter will return the binding.
In a test, one can call "TestWidgetsFlutterBinding.ensureInitialized()" as the first line in the test's "main()" method to initialize the binding.
If ServicesBinding is a custom binding mixin, there must also be a custom binding class, like WidgetsFlutterBinding, but that mixes in the selected binding, and that is the class that must be constructed before using the "instance" getter.
If you were running Flutter code, you can also paste an image of the Flutter output directly into this bug report.
It seems to be some problem with the theme declaration, I tried to put the theme declaration straight into the MaterialApp and I also tried to have it as late final, but none of those solutions worked. I found a workaround that works though, and that is to put WidgetsFlutterBinding.ensureInitialized(); as the first thing in main.
It's strange though, because Padracing worked correctly during Google I/O, and I can't see any commit to DartPad that should have changed this behaviour.
Can you update the gist that is referenced from the sample menu to include WidgetsFlutterBinding.ensureInitialized(); meanwhile? (Or if that is somewhere in a public repo I can put up a PR for it).
I was able to reproduce this for the Google Fonts demo by moving the MaterialApp declaration directly into runApp and defining the headline1 and headline2 themes directly, like this:
https://dartpad.dev/?id=ca65097d19cc31f06431e7c6df24d4e0
This is starting to feel like a bug in Flutter's web compiler, not DartPad. I'm also guessing we can work around the issue by moving the code out of main.
Do you want to try reproducing with Flutter web directly, I.e. outside of DartPad?
This is starting to feel like a bug in Flutter's web compiler, not DartPad. I'm also guessing we can work around the issue by moving the code out of main.
True, making it its own widget wrapping MaterialApp also works.
Do you want to try reproducing with Flutter web directly, I.e. outside of DartPad?
I can reproduce it on master (3.1.0-0.0.pre.984) and stable, but it behaves a bit differently, it gives the same error messages, but the fonts still load.
I guess this issue can be closed then since it's not fully related to DartPad?
I can’t see in the chrome tooling where it is attempting to load the AssetManifest.json. We actually have a fake manifest baked into the DartPad front end that may need to be updated.
I've updated the gist behind https://dartpad.dev/?id=ecabed4a17a3aad8bee7c6327e472fc8 with a top level widget and we now have the font rendering. But the code showing in my browser differs to the content of the gist. And the updated gist name hasn't flowed through. I suspect there is a cache somewhere that I can't flush.
It seems like the cache has been updated now, it works perfectly for me at least! :raised_hands:
From testing it looks like we have a long lived in browser cache for gists. @johnpryan can you confirm?
@domesticmouse the localstorage is used to store a single gist object - the key is always 'gist'. This saved gist object has it's ID (as you see in dartpad url also) and all of the associated files. If the ID being requested by the ID parameter in the URL matches the ID of the (one an only) gist stored in localstorage then the contents of the localstorage are always used - regardless if they are older or newer than the source gist.
The easiest way to clear the local storage is to click 'New Pad', another way to clear the localstorage is to click 'Reset'. The additional away to 'clear' your localstorage gist cache is to load a different gist ID and edit it.
#2227 adds a new indicator at the top of the editor which shows if you are looking at an edited version of the original gist. With the ability to create, update and fork gist with #2227 this indicator can useful - for example you can edit a gist such as padracer, and then create your own fork or create a new gist. (or if you are the owner you could update the original gist) - you can then easily return to the original Gist ID and get the up to date contents without any localstorage interference. (Because even with #2227 the localstorage always only contains the last edited gist).
I think this issue is out of date - the padracing sample is working now. Feel free to leave comment if you are still seeing an issue with fonts.
