Remote Hosted Code causing extension review rejection

[teacoat]

Description

Some third party code is causing google to reject any extensions using model-viewer, exact message:

Thank you for reaching out to us. As conveyed in the previous mail, your item was rejected for not being compliant with the “Remote Hosted Code” policy. We could see remote hosted code in the dist/521.58e8cce0df2779ab.js file where it is fetching code from an external domain (https://cdn.jsdelivr.net/npm/three@0.149.0/examples/jsm/loaders/LottieLoader.js )

Inlining this code would be better, thanks.

Live Demo

N/A

Version

• model-viewer: v3.3.0

Browser Affected

• [ x] Chrome
• Edge
• Firefox
• IE
• Safari

OS

• [x ] Android
• [ x] iOS
• [ x] Linux
• [ x] MacOS
• [ x] Windows

[elalish]

We allow you to set the Lottie loader location - do they still have a problem if you point it to a local copy?

[teacoat]

@elalish yeah they dont like the URL being in there at all

[elalish]

Interesting, thanks for reporting! I need to find someone internally to see if we can work around this somehow.

[teacoat]

I got around it by building it locally and just bundling this lottieloader with it, but I would prefer not having to do that each time it updates lol

[elalish]

Ah, glad that worked! Not sure if you already did this, but if you're not using Lottie animations (they're a pretty rare feature, and not part of glTF), then you don't need to pack the rather large LottieLoader file. I would just package an empty file with that name, since it'll never get called at runtime anyway.

[teacoat]

Is this really the final solution? Having to build it myself for each update?

[elalish]

Well, I didn't really have much detail on what you tried that worked or how you would have rather it worked. I was busy asking the extensions team to comment when you said you had a work-around, so we stopped. Can you show some examples of what you tried that should have worked but didn't?

[teacoat]

I removed the reference to the remote hosted code and bundled it with it, the issue is the default link to the remote hosted code

[elalish]

I added this FAQ based on your issue. I'm curious if that works? Depends on the nature of their automated checker. If you can link to a simple extension project using this technique that's still getting rejected by Chrome's store, then I know who to bother to try and get their check fixed, or they can recommend a way to improve MV.

[teacoat]

Here is my extension

And here is the response I got from support:

[elalish]

Thanks, but what I'm trying to get to is a minimal repro. Did you try just following the FAQ above to set our static property LottieLoaderLocation to a local file? I want to know if that works, or if their static checker can't understand that.

[teacoat]

I believe I tried that yes, its all minified and obfuscated and just having that external URL in there was a red flag

[elalish]

Great, thanks for confirming. I'm going to ask the Chrome extension folks how to make this easier.