When you visit an ms-windows-store link it tries to open it with an application on Desktop and Metro Firefox. This is pretty bad because the application name displays as TWINUI. If you go ahead and select that application it opens up the windows store. If you don't then nothing happens. We should auto open up these links like Google Chrome and IE do.
Example site, click on view in store: http://apps.microsoft.com/windows/en-US/app/google-search/308dc145-6851-487d-b83b-1223a3b52dc2
Point Estimate from Brian=2.
Created attachment 748983 [details] [diff] [review] Patch v1. uriloader prefs to enable ms-windows-store:// links for desktop and metro browser
Comment on attachment 748983 [details] [diff] [review] Patch v1. +#ifdef XP_WIN +pref("network.protocol-handler.expose.ms-windows-store", false); +#endif don't add this one, it's only needed for protocol handlers that gecko implements (applies to both pref files) r=biesi with that removed
Created attachment 749017 [details] [diff] [review] Patch v2 - w/ review comments
For testing and verification.
Mozilla/5.0 (Windows NT 6.2; rv:24.0) Gecko/20130515 Firefox/24.0 Trying to verify with the build from the 15th - in desktop Nightly I can still see the TWINUI prompt when attempting to open the link. In Metro, the Store is opened directly. I'll re-try tomorrow in case this didn't land in the 15th (though it should judging by the date).
Ya it should be in that build, it works for me but maybe I have some other setting saved on my machine as default handler. I'll take a look.
Hey Virgil I just tried creating a new user account. I installed a release build and the latest nightly build. The release build prompted me for TWINUI an the nightly build just launched the store. Could you try again with today's nightly once it is ready? It sounds like something was fixed but not everything base on the info you gave for the build you tried last. I'll retry on a completely different computer after you check too.
I'm testing by typing ms-windows-store://hi in the URLbar by the way.
Can still reproduce on the build from the 16th, but works with a new profile. Double checked on 2 other computers (default/non-default Nightly, updated, new install) - so this is ok. Not exactly sure what was wrong with the profile, but this can be set to verified.
We don't have a story for this. Specialty link handling seems like a small enough surface area to not warrant a full story.
Went through the following "Defect" for iteration #12 without any issues. Used the following build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-08-20-03-02-06-mozilla-central/ - Went through the original test case outlined in comment #0 with an older version of Firefox Metro and reproduced the issue - Installed the above linked build and went through the same test case once again, everything worked without any issues - Clicked on the link in comment #1 and ensured that Firefox Metro opened a new tab correctly. Selected "View in Windows Store" and the store launched without any issues or prompting the user a module message indicating another application wants to run - Went through all of the above test cases in filled view without issues