Obsolete
Status Update
No update yet.
Comments
ph...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
You're likely seeing two problems:
(1) if you manually disable NaCl in about:plugins, it won't work in any case
(2) until the next release, your users may be running intohttps://crbug.com/chromium/93984 . This caused about:plugins to get into a bad state for a large number of users without them necessarily having to have manually disabled anything in about:plugins
If you want to test whether or not your app will work, start chrome with --user-data-dir= some empty directory. This will start with an empty profile and all of the stock settings. If it still doesn't work for you when you install from the CWS, then please reply to this bug.
(1) if you manually disable NaCl in about:plugins, it won't work in any case
(2) until the next release, your users may be running into
If you want to test whether or not your app will work, start chrome with --user-data-dir= some empty directory. This will start with an empty profile and all of the stock settings. If it still doesn't work for you when you install from the CWS, then please reply to this bug.
al...@gmail.com
Just tested on the same two rigs (Mac OS X and Linux) using --user-data-dir with clean profiles. Logged into CWS, installed the hosted app, and we have the same problem again. NaCl app doesn't load, no errors in JavaScript console.
Thanks for your attention to this matter! (especially on a Sunday) :)
Albert
Thanks for your attention to this matter! (especially on a Sunday) :)
Albert
bb...@google.com
Another thing to try is to uninstall the app and reinstall it. If the app was first installed before we started saving 'from CWS' state (August), it might not be recognized as a CWS app.
bb...@google.com
Didn't see your last post. If you are doing fresh installs, reinstalling won't help.
When you start up Chrome with a new profile, with your newly installed CWS app, does about:plugins show NaCl disabled? That would imply that somehow profile data is getting loaded with 'disabled' state in it.
When you start up Chrome with a new profile, with your newly installed CWS app, does about:plugins show NaCl disabled? That would imply that somehow profile data is getting loaded with 'disabled' state in it.
al...@gmail.com
With a clean profile, about:plugins shows Native Client as enabled on both my Linux and Mac OS X test systems.
bb...@google.com
And yet the NaCl module won't load? There is a known issue with 32-bit Windows / Linux systems that was very recently fixed, but that wouldn't explain the failure on Mac.
al...@gmail.com
Correct, we're not seeing the NaCl module load.
I just ran Chrome with:
export PPAPI_BROWSER_DEBUG=1
export NACLVERBOSITY=3
export NACL_PPAPI_PROXY_DEBUG=1
export NACL_PLUGIN_DEBUG=1
and this is all I see on both test systems:
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
... but nothing actually works...
Thanks!
Albert
I just ran Chrome with:
export PPAPI_BROWSER_DEBUG=1
export NACLVERBOSITY=3
export NACL_PPAPI_PROXY_DEBUG=1
export NACL_PLUGIN_DEBUG=1
and this is all I see on both test systems:
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
b30ce870: CreateModule ()
b30ce870: ModulePpapi::ModulePpapi (this=0xb8cb55a0)
... but nothing actually works...
Thanks!
Albert
al...@gmail.com
I should mention that this can't be the 32-bit issue because if we enable the NaCl flag manually, the NaCl app runs fine on both systems.
bb...@google.com
Do you see any output that looks like it comes from the NaCl plugin? If you observe any output from the NaCl plugin, then something else is wrong, since the CWS-restriction (about:flags enabled, or CWS app) blocks the plugin from even being created.
al...@gmail.com
On a hunch, here's part of my manifest.json from the Chrome app:
"app": {
"urls": [
"http://www.foobar.com/my-nacl-app/ ",
"http://beta.foobar.com/my-nacl-app/ "
],
"launch": {
"web_url": "http://www.foobar.com/my-nacl-app/ "
}
=====
I currently have the launch URL redirecting to the beta subdomain though, so in Chrome, clicking on the app icon takes you here:
http://www.foobar.com/my-nacl-app/
which then redirects to:
http://beta.foobar.com/my-nacl-app/
If the NaCl is only enabled for the "launch" URL and not the "app" URLs, then this could be the problem. I can try uploading a version of the app that has the launch URL set to the beta site...
"app": {
"urls": [
"
"
],
"launch": {
"web_url": "
}
=====
I currently have the launch URL redirecting to the beta subdomain though, so in Chrome, clicking on the app icon takes you here:
which then redirects to:
If the NaCl is only enabled for the "launch" URL and not the "app" URLs, then this could be the problem. I can try uploading a version of the app that has the launch URL set to the beta site...
bb...@google.com
That sounds like it could be the problem. The code that enforces the CWS-restriction looks at the NaCl URL and tries to associate it with an extension. This implies that the NaCl manifest (.nmf) and all .nexes must be packaged into the extension (uploaded as part of the .crx file).
al...@gmail.com
Hmm.... My app isn't packaged as an extension, it's a "hosted app" with the .nexes hosted on my site, and I've only been uploading a .zip with the manifest and icons to the Chrome Web Store. It was my understanding this was supported, as the documentation says:
"Native Client modules and manifest files are stored with the rest of your application on a web server. You can use the Chrome Web Store to publish your app where Google Chrome users can easily find it."
http://code.google.com/chrome/nativeclient/docs/technical_overview.html#distribute
The documentation doesn't address extension-vs-hosted for Native Client apps directly, but I inferred from David's previous comments that this would work:
"Other people may have to chime in if you're making an extension. But for most apps, just build and deploy your NaCl app using the NaCl SDK and associated instructions..."
http://groups.google.com/group/native-client-discuss/browse_thread/thread/ac50ba0063742d59
"Native Client modules and manifest files are stored with the rest of your application on a web server. You can use the Chrome Web Store to publish your app where Google Chrome users can easily find it."
The documentation doesn't address extension-vs-hosted for Native Client apps directly, but I inferred from David's previous comments that this would work:
"Other people may have to chime in if you're making an extension. But for most apps, just build and deploy your NaCl app using the NaCl SDK and associated instructions..."
bb...@google.com
My understanding is that this is a temporary restriction, intended to prevent widespread deployment of Instruction-Set-Architecture dependent apps before PNaCl is released.
http://blog.chromium.org/2011/08/native-client-brings-sandboxed-native.html
In the meantime, the easiest way to check whether a request to instantiate NaCl on a web page is if the manifest can be associated easily with an extension. That means the .nmf must be of the form chrome-extension:<id>/foo.nmf. The .nexe files should also be part of the extension, since the plugin normally won't load across domains.
In the meantime, the easiest way to check whether a request to instantiate NaCl on a web page is if the manifest can be associated easily with an extension. That means the .nmf must be of the form chrome-extension:<id>/foo.nmf. The .nexe files should also be part of the extension, since the plugin normally won't load across domains.
bb...@google.com
Correction to last paragraph of my last post:
In the meantime, the easiest way to check whether a request to instantiate NaCl on a web page is from a CWS app is if NaCl manifests can be associated easily with an extension. That means the .nmf must be of the form chrome-extension:<id>/foo.nmf. The .nexe files should also be part of the extension, since the plugin normally won't load across domains.
In the meantime, the easiest way to check whether a request to instantiate NaCl on a web page is from a CWS app is if NaCl manifests can be associated easily with an extension. That means the .nmf must be of the form chrome-extension:<id>/foo.nmf. The .nexe files should also be part of the extension, since the plugin normally won't load across domains.
al...@gmail.com
I uploaded a new version of my app with the launch web_url pointing straight to the NaCl app URL and my Linux tester reports the same "not loading" issue. There was no additional output in the terminal compared to before. Unfortunately, I can't continue OS X testing until tomorrow because my power adapter just melted.
I'll try to experiment with packaging my app as an extension this week, unless we get some more details from someone else about how to make this work.
Though, I think it'd be a bit of a shame to lock out hosted NaCl apps. One of the beauties of NaCl is that there's "no download" for users, and forcing them to install an extension kills that. I was looking forward to deploying my NaCl application and being able to update it without any user intervention.
In the big picture, I don't see why hosted NaCl apps should be excluded from the Chrome Web Store. Forcing hosted NaCl apps to only run through the CWS will serve the exact same purpose as only allowing them to be extensions. The CWS still gets to be a gatekeeper to ensure apps are safe and, when the time comes, ensure they get ported to PNaCl to ensure they run on ARM. Does this sound reasonable?
In the meantime though, perhaps all my bug reporting shows that the danger of "widespread deployment of Instruction-Set-Architecture dependent apps" is not very high, otherwise more people would be running into the same issues as me. :)
What do you guys think?
Thanks,
Albert
I'll try to experiment with packaging my app as an extension this week, unless we get some more details from someone else about how to make this work.
Though, I think it'd be a bit of a shame to lock out hosted NaCl apps. One of the beauties of NaCl is that there's "no download" for users, and forcing them to install an extension kills that. I was looking forward to deploying my NaCl application and being able to update it without any user intervention.
In the big picture, I don't see why hosted NaCl apps should be excluded from the Chrome Web Store. Forcing hosted NaCl apps to only run through the CWS will serve the exact same purpose as only allowing them to be extensions. The CWS still gets to be a gatekeeper to ensure apps are safe and, when the time comes, ensure they get ported to PNaCl to ensure they run on ARM. Does this sound reasonable?
In the meantime though, perhaps all my bug reporting shows that the danger of "widespread deployment of Instruction-Set-Architecture dependent apps" is not very high, otherwise more people would be running into the same issues as me. :)
What do you guys think?
Thanks,
Albert
bb...@google.com
After discussing with Erik, it looks like I misunderstood how Chrome checks the manifest URL. Hosted web apps should work, as long as your manifest registers the necessary web extents.
Can you try your app again with the fix to the redirects?
Can you try your app again with the fix to the redirects?
[Deleted User] <[Deleted User]>
Also, if you give us a pointer to your app entry in the store, we can take a look at it and debug it from here.
al...@gmail.com
Hi guys, thanks for the quick replies and continuing to troubleshoot this with me.
I tried the redirect fix (putting my beta domain as the launch_url in my manifest) but it doesn't seem to have solved the problem. I'll email you both with a link to the CWS app shortly...
Thanks again,
Albert
I tried the redirect fix (putting my beta domain as the launch_url in my manifest) but it doesn't seem to have solved the problem. I'll email you both with a link to the CWS app shortly...
Thanks again,
Albert
cs...@google.com
[Empty comment from Monorail migration]
bb...@google.com
[Comment Deleted]
bb...@google.com
The URL for the .nmf file that the page tries to load is:
"http://beta.foo.com/bar.nmf "
The web domain that the extension has specified is:
"http://beta.foo.com/bar-for-chrome/ "
The .nmf URL doesn't match the domain, which is why the CWS-restriction test fails in this case.
"
The web domain that the extension has specified is:
"
The .nmf URL doesn't match the domain, which is why the CWS-restriction test fails in this case.
al...@gmail.com
By web domain, you mean the full URL?
I've just made the following changes:
- Moved the .nmf to:
http://beta.foo.com/bar-for-chrome/bar.nmf
- Updated my .html page to directly load the absolute URL:
http://beta.foo.com/bar-for-chrome/bar.nmf
- Updated the relevant part of my manifest to include the direct URL to bar.nmf:
"app": {
"urls": [
"http://www.foo.com/bar-for-chrome/ ",
"http://beta.foo.com/bar-for-chrome/ ",
"http://beta.foo.com/bar-for-chrome/soda.nmf "
],
"launch": {
"web_url": "http://beta.foo.com/bar-for-chrome/ "
}
Both my tester and I uninstalled the Chrome app, reinstalled it, disabled NaCl in about:plugins, and it's not loading again.
Did I misunderstand your suggestion?
Thanks,
Albert
I've just made the following changes:
- Moved the .nmf to:
- Updated my .html page to directly load the absolute URL:
- Updated the relevant part of my manifest to include the direct URL to bar.nmf:
"app": {
"urls": [
"
"
"
],
"launch": {
"web_url": "
}
Both my tester and I uninstalled the Chrome app, reinstalled it, disabled NaCl in about:plugins, and it's not loading again.
Did I misunderstand your suggestion?
Thanks,
Albert
bb...@google.com
I just relaunched from CWS and your app loads successfully on my machine, so your URLs are correct now. I don't think you need the .nmf URL in your manifest.
bb...@google.com
To clarify, your app now works for me on dev channel (Chrome 15.x) Mac and Windows. I have Native Client disabled in about:flags on both. I don't think anything has changed since Chrome 14, but can try those versions if you can't get it to work.
al...@gmail.com
You're right - it is working now! Awesome, thanks for debugging this Bill!
I've confirmed that it's working on Chrome 14.0.835.157 on Mac OS X 10.6 and on some Chrome 14 version on 32-bit Vista. I should hear back to verify that it's working on Linux as well within the next 12 hours, and I'll let you know if we find any problems.
Thanks again, and I'll continue to move forward with wider beta testing.
Albert
I've confirmed that it's working on Chrome 14.0.835.157 on Mac OS X 10.6 and on some Chrome 14 version on 32-bit Vista. I should hear back to verify that it's working on Linux as well within the next 12 hours, and I'll let you know if we find any problems.
Thanks again, and I'll continue to move forward with wider beta testing.
Albert
[Deleted User] <[Deleted User]>
[Empty comment from Monorail migration]
bu...@chromium.org
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
bu...@chromium.org
[Empty comment from Monorail migration]
bu...@chromium.org
[Empty comment from Monorail migration]
is...@google.com
This issue was migrated from crbug.com/chromium/95379?no_tracker_redirect=1
[Auto-CCs applied]
[Multiple monorail components: Internals, Platform>NaCl]
[Monorail mergedwith:crbug.com/chromium/95380 ]
[Monorail components added to Component Tags custom field.]
[Auto-CCs applied]
[Multiple monorail components: Internals, Platform>NaCl]
[Monorail mergedwith:
[Monorail components added to Component Tags custom field.]
Description
Chrome/Chromium version:
Tested with:
Mac OS X 10.6.8, Chrome 14.0.835.126
Ubuntu 11.04, Chrome 15.0.865.0 dev
Related URL(s):
Email me and I'd be happy to put you on the beta list for my CWS/NaCl app.
Background from chromium-apps Google Group:
http://groups.google.com/a/chromium.org/group/chromium-apps/browse_thread/thread/9bfb88f90e3ba672/ffb5c021a54ae35b?hl=en#ffb5c021a54ae35b
Steps to reproduce the issue:
What did you expect?
My NaCl app should have loaded.
What happened?
I get no errors in the JavaScript console, but my app just does not load. This is the same behaviour that I observe when NaCl is explicitly turned off.
Long version:
I have a hosted NaCl app that is published to beta testers in the Chrome Web Store. David Michael and Erik Kay said that with Chrome 14, NaCl should be automatically enabled for CWS apps, but this does not seem to be currently working.
On Mac OS X 10.6.8 with Chrome 14.0.835.126, I was unable to get my app to load through CWS with NaCl disabled in about:plugins (but enabled in about:flags). I also checked the inverse case where NaCl is enabled in about:flags but disabled in about:plugins, and it also didn't load.
If I enable it in both about:flags and about:plugins, no problems, everything loads fine.
On Ubuntu 11.04 with Chrome 15.0.865.0 dev, a beta tester just reported the exact same thing - With NaCl enabled in both about:flags/plugins, no problems. But if NaCl is disabled in either, then my app won't load through CWS.
Thanks!
Albert