1245204 - warn users that desktop web runtime will be disabled

Status: RESOLVED FIXED

(Firefox Graveyard :: Webapp Runtime, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

It might be worth warning users that the desktop web runtime will be disabled, and giving them a link to a document that describes the change in more detail and suggests alternatives, before we actually disable the runtime, to mitigate the impact of the change.

For example, we might display a warning dialog with a link to a page when the user runs an Open Web App in some release of the browser, then remove the runtime in the next release, so users see the warning when they upgrade Firefox to the first release and can follow the link for more information before they upgrade Firefox to the next release.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Attachment: warn user that runtime will be disabled

Something like this might work, given a URL that we know won't change (or can be redirected).

Marco, what do you think?

Comment 2

[Marco Castelluccio [:marco]]

Comment on attachment 8723241 [details] [diff] [review]
warn user that runtime will be disabled

Review of attachment 8723241 [details] [diff] [review]:
-----------------------------------------------------------------

Maybe we could also offer the option to uninstall the app.

Comment 3

[Joni Chan]

Here's a link you can use in-product: https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/runtime

Just change the Version/OS/Locale tuple.

What's the timeline for the SUMO page?

Comment 4

[Myk Melez [:myk] [@mykmelez]]

(In reply to Joni Savage ("need info" me) from comment #3)
> Here's a link you can use in-product:
> https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/runtime

Thanks!


> Just change the Version/OS/Locale tuple.

The URL may vary by locale, as localizers localize it.  But it shouldn't vary by Firefox version/OS.  The content of the page won't be version-specific, and while there may be some OS-specific bits, most of the content will be OS-agnostic, so it'd be better to have a single doc with OS-specific notes as appropriate.

Is it possible to direct users to a URL that isn't version/OS-specific?


> What's the timeline for the SUMO page?

In order to ship the warning in Firefox 47, we need to land the patch within the next week, so I'd need to know the URL by then.  The content of the SUMO page itself doesn't have to be ready by then, however.  Nevertheless, I plan to write at least an initial draft within the next week.


How do I go about editing the page at the URL?

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Joni: I drafted an initial version of the document and requested review on it.  It looks like SUMO has assigned it the URL <https://support.mozilla.org/en-US/kb/runtime>.  Can we use that URL for this document?

(Note: I told SUMO that the document applies to "Windows 10," because I didn't see a way to apply it to all desktop operating systems.  But it should apply to all of them.)

Comment 6

[Myk Melez [:myk] [@mykmelez]]

Attachment: warn user that runtime will be disabled

This is a slightly updated patch.  I've tested it on Windows, Mac, and Linux, and it works on all three OSes.  I may need to update the URL, depending on Joni's response to my needinfo request, but otherwise this is ready to go.

However, there are two issues with the patch:

1. Pressing Esc acts as if Button #1 was pressed.  This appears to be inherent to CommonDialog, as the ondialogcancel handler in commonDialog.xul invokes Dialog.onButton1() regardless of whether Button #1 is a standard "Cancel" button or a custom button.

2. The default (OK) button is blank until you mouse over it on Mac.  This doesn't happen on Windows nor Linux, and I haven't been able to figure out what causes it on Mac.

Despite these two issues, I'm inclined to keep using CommonDialog, as it's much simpler than reimplementing a dialog from scratch, and we're less than a week from the 47 merge.


(In reply to Marco Castelluccio [:marco] from comment #2)
> Maybe we could also offer the option to uninstall the app.

That might be nice to have, but users have a straightforward method of doing this (the OS-default uninstall method), and we have constrained resources, so I don't think we should consider it at this point.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #5)
> Joni: I drafted an initial version of the document and requested review on
> it.  It looks like SUMO has assigned it the URL
> <https://support.mozilla.org/en-US/kb/runtime>.  Can we use that URL for
> this document?

I caught up with Joni on IRC, and she confirmed that we can use this URL for the document!

Since the URL is in a .properties file, localizers could localize the document on SUMO and then change the URL in their locale's equivalent .properties file.  I'll let localizers know about that option after this lands.

Comment 8

[Marco Castelluccio [:marco]]

Maybe add a l10n note before disable-warning.info.url?

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Attachment: warn user that runtime will be disabled

(In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> Since the URL is in a .properties file, localizers could localize the
> document on SUMO and then change the URL in their locale's equivalent
> .properties file.  I'll let localizers know about that option after this
> lands.

(In reply to Marco Castelluccio [:marco] from comment #8)
> Maybe add a l10n note before disable-warning.info.url?

Noah on #sumo had a better idea: since SUMO will auto-redirect a user to a locale-specific version (falling back to the en-US version if SUMO doesn't have a version in the user's locale), we can omit the locale string from the URL, and SUMO will handle directing users to the best version for them.

Here's a version of the patch with that change.  This is the version I'll commit.

Comment 10

[Marco Castelluccio [:marco]]

So, can we directly omit it from the properties file?

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/c1b18e68fdb5

Comment 12

[Myk Melez [:myk] [@mykmelez]]

(In reply to Marco Castelluccio [:marco] from comment #10)
> So, can we directly omit it from the properties file?

Yes, we could do that.  Should I do it in a followup?

Comment 13

[Marco Castelluccio [:marco]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #12)
> (In reply to Marco Castelluccio [:marco] from comment #10)
> > So, can we directly omit it from the properties file?
> 
> Yes, we could do that.  Should I do it in a followup?

Yes, let's do it in a follow-up!

Comment 14

[Myk Melez [:myk] [@mykmelez]]

(In reply to Marco Castelluccio [:marco] from comment #13)
> (In reply to Myk Melez [:myk] [@mykmelez] from comment #12)
> > (In reply to Marco Castelluccio [:marco] from comment #10)
> > > So, can we directly omit it from the properties file?
> > 
> > Yes, we could do that.  Should I do it in a followup?
> 
> Yes, let's do it in a follow-up!

Done in bug 1252670.

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c1b18e68fdb5

Comment 16

[Chris Ilias [:cilias]]

There was a placeholder article created for this at https://support.mozilla.org/en-US/kb/runtime-disabled
It looks like a different article was used for this bug. If no-one objects, I'm going to delete the placeholder article.

Comment 17

[Myk Melez [:myk] [@mykmelez]]

(In reply to Chris Ilias [:cilias] from comment #16)
> There was a placeholder article created for this at
> https://support.mozilla.org/en-US/kb/runtime-disabled
> It looks like a different article was used for this bug. If no-one objects,
> I'm going to delete the placeholder article.

No objections here, thanks Chris!

Comment 18

[Chris Ilias [:cilias]]

In my previous comment, status-firefox47: fixed was removed. I don't know how that happened; it was unintentional.  I don't see a way to put it back.

Comment 19

[Myk Melez [:myk] [@mykmelez]]

(In reply to Chris Ilias [:cilias] from comment #18)
> In my previous comment, status-firefox47: fixed was removed. I don't know
> how that happened; it was unintentional.  I don't see a way to put it back.

Presumably it isn't possible to put it back because this bug is in the Firefox Graveyard product, which doesn't have that flag.  We could move the bug to Firefox, re-add the flag, and then move it back, but I don't think it's worth it.

Comment 20

[Chris Ilias [:cilias]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #17)
> (In reply to Chris Ilias [:cilias] from comment #16)
> > There was a placeholder article created for this at
> > https://support.mozilla.org/en-US/kb/runtime-disabled
> > It looks like a different article was used for this bug. If no-one objects,
> > I'm going to delete the placeholder article.
> 
> No objections here, thanks Chris!

Okay, I've deleted it.