Defect - ms-windows-store:// links should not need to be opened with an application

VERIFIED FIXED in Firefox 24

Status

Firefox for Metro
File Handling
P1
normal
VERIFIED FIXED
5 years ago
3 years ago

People

(Reporter: bbondy, Assigned: bbondy)

Tracking

Trunk
Firefox 24
x86_64
Windows 8.1

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: feature=defect c=operations u=operations p=2)

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

5 years ago
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.
(Assignee)

Comment 1

5 years ago
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.
Summary: ms-windows-store:// links should not need to be opened with an application → Defect - ms-windows-store:// links should not need to be opened with an application
Whiteboard: p=2 → feature=defect c=tbd u=tbd p=0

Updated

5 years ago
Component: General → File Handling
(Assignee)

Updated

5 years ago
Assignee: nobody → netzen
Blocks: 862352
No longer blocks: 859003

Updated

5 years ago
Priority: -- → P1
QA Contact: jbecerra
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=operations u=operations p=2

Updated

5 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

5 years ago
Created attachment 748983 [details] [diff] [review]
Patch v1.

uriloader prefs to enable ms-windows-store:// links for desktop and metro browser
Attachment #748983 - Flags: review?(jmathies)
(Assignee)

Updated

5 years ago
Attachment #748983 - Flags: review?(jmathies) → review?(cbiesinger)
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
Attachment #748983 - Flags: review?(cbiesinger) → review+
(Assignee)

Comment 5

5 years ago
Created attachment 749017 [details] [diff] [review]
Patch v2 - w/ review comments
Attachment #749017 - Flags: review+
(Assignee)

Updated

5 years ago
Attachment #748983 - Attachment is obsolete: true
(Assignee)

Comment 6

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/3a56d9a0b092
Target Milestone: --- → Firefox 24

Comment 7

5 years ago
https://hg.mozilla.org/mozilla-central/rev/3a56d9a0b092
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
For testing and verification.
Flags: needinfo?(virgil.dicu)
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).
Flags: needinfo?(virgil.dicu)
(Assignee)

Comment 10

5 years ago
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 11

5 years ago
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.
Flags: needinfo?(virgil.dicu)
(Assignee)

Comment 12

5 years ago
I'm testing by typing ms-windows-store://hi in the URLbar by the way.
Flags: needinfo?(virgil.dicu)
(Assignee)

Updated

5 years ago
Flags: needinfo?(virgil.dicu)
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.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Flags: needinfo?(virgil.dicu)
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED

Comment 14

4 years ago
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
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.