882186 - [System] Replace blue offline error page with new UX

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Sergi]

Attachment: Offline State :: mockups

When there're no available networks or there's no connection to the internet and the user tries to open an app without cached content, we're showing a 404 screen similar to the one used in the browser.

We may improve the experience by showing a screen which better matches the style of the UI, a most meaningful iconography for the user to better understand the problem, and offer some alternatives to the user besides "Try again" if possible. 

Find attached some proposals to start the discussion.

Thanks!

Comment 1

[Jason Smith [:jsmith]]

I like the fact that we're exploring better offline error pages. Some feedback on this:

I think we should consider trying to build a fallback offline error page that tries to customize itself in the context of the app. That would mean that we implement a fallback offline error page that does such customizations as:

- Background page in alignment with the app
- Utilize the app icon on the offline error page
- Buttons in alignment with the app for the options available on the offline error page

The reasoning for this was that the general feedback I received during preinstalled app testing from various folks was that many people did not like when apps did a fallback to the browser error page and wanted the app to have it's own custom app error page. On that regard, if we can at least have a fallback that strives to generate a fallback offline app error page that tries to fall in alignment with the app if no custom app error page is provided, then we'll likely reduce the complaints around this area of UX.

Comment 2

[Rafael Rebolleda]

Good points, Jason :)

For starters, and to clear things a little bit, I don't think these "errors" or information pages should be 404s altogether. That's somehow what's technically happening, but I think we should distinguish both cases.

Going back to your suggestions, which are definitely worth exploring, I think we'll come across potential issues with icon sizing in different screen resolutions. I'm not sure there's even an option to handle this in the homescreen or in the app manifest at this point. That said, I think it's worth exploring whether we can use the icon (maybe apply some filter to harmonize, in a similar fashion as we've proposed for the homescreen) to further customise this screen and relate it to the app itself.

I wouldn't allow the app to customise just the background, because we may run into different legibility issues, but I agree that allowing devs to specify their offline page in the manifest might be interesting. That way it's either a system one or a fully customised one by the devs, but nothing in between. However, we should evaluate whether that creates too much inconsistency between apps that declare it and those that don't, in case users get confused about two potentially very different messages for the same "error".

Comment 3

[Francisco Jordano [:arcturus] [:francisco]]

Hi,

I've just recently seen the captive portal detection actived in master, which means we could implement perfectly all of the use case where connection is apparently there but we are effectively offline.

Cheers,
F.

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

Captive portal is implemented long time ago. It's on v1-train as well.
Technically what you mentioned doesn't work.
Captive portal only fires event when "current AP acquires login", not anytime you want to check.
Read captive_portal.js if you're interested.

Also why does this blocks 870362? This bug is talking about refining app Error in system.

Comment 5

[Francis Djabri [:djabber]]

Attachment: offline v0.2.pdf

Please find attached a UX proposal that builds on Sergi's earlier work. It would be very useful to know if this proposal is covering the full range of use cases involved.

Comment 6

[Karen Rudnitski [:kar]]

Brad - as we have a UX spec attached now, can you please check to see if this bug is now sprint-ready?

Comment 7

[Brad Lassey [:blassey] (use needinfo?)]

Karen, I think this bug is for making a system-wide change. Do you want to splinter this off to do something special for the browser? or talk to the system team about prioritizing this in their backlog?

Comment 8

[Karen Rudnitski [:kar]]

As discussed in the fxos browser weekly meeting, this is a job for the system team. Francis to flag it up with that team again.

Comment 9

[Francis Djabri [:djabber]]

Attachment: offline 1.2 MVP.pdf

Attached is an MVP proposal for offline error handling. This proposal is significantly reduced in scope in the hope of getting these important changes in the 1.2 timeline.

Comment 10

[Peter Dolanjski [:pdol]]

User story for this bug:

As a user, I want all app launches and page loads which would normally result in the blue offline error screen to be replaced with a message that explains my offline status, allows me to check my WiFi settings and to try the load again so that it is easier to understand why the app is not working, correct the situation and try again.

Acceptance Criteria:

1. In scenarios in which I would normally be shown the blue offline screen, I am informed that I have no active connection.
2. After I am informed that I have no active connection as in 1, I can access WiFi settings without needing to access the settings or utility tray.
3. After I am informed that I have no active connection as in 1, I can attempt to reload the page without closing and relaunching the app.
4. If I chose to ignore the message received in 1, I am taken to the previous position in the app. (if one exists)
5. If I chose to ignore the message received in 1, and I am currently on the entry point within the app (ie. first screen), I am exited out of the app.

Comment 11

[Francis Djabri [:djabber]]

Attachment: offline 1.2 MVP v0.2.pdf

Updated following Peter's review

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

My 2$:
(I think I could say something here because I implement current app error dialog)
The "connectivity menu" overlay on homescreen doesn't make sense.
We should put error overlay in the app causing error anyway. If the menu exists in homescreen, that means homescreen itself need network connectivity, not the app. This is not consistent. And homescreen itself doesn't know the app needs network activity or not.

Comment 13

[Sergi]

Is it possible to launch the "connectivity menu" overlay from the app instead of doing it from the home screen? i mean, that's something similar to what we do when an app needs to ask permissions to geolocalize the user, and it won't modify a lot the flow Francis is proposing.  

(In reply to Alive Kuo [:alive] from comment #12)
> My 2$:
> (I think I could say something here because I implement current app error
> dialog)
> The "connectivity menu" overlay on homescreen doesn't make sense.
> We should put error overlay in the app causing error anyway. If the menu
> exists in homescreen, that means homescreen itself need network
> connectivity, not the app. This is not consistent. And homescreen itself
> doesn't know the app needs network activity or not.

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Sergi from comment #13)
> Is it possible to launch the "connectivity menu" overlay from the app
> instead of doing it from the home screen? i mean, that's something similar
> to what we do when an app needs to ask permissions to geolocalize the user,
> and it won't modify a lot the flow Francis is proposing.  
> 
> (In reply to Alive Kuo [:alive] from comment #12)
> > My 2$:
> > (I think I could say something here because I implement current app error
> > dialog)
> > The "connectivity menu" overlay on homescreen doesn't make sense.
> > We should put error overlay in the app causing error anyway. If the menu
> > exists in homescreen, that means homescreen itself need network
> > connectivity, not the app. This is not consistent. And homescreen itself
> > doesn't know the app needs network activity or not.

Permission is not a good example. Permission is going to part of an app, not belong to whole system. There's some issue like a background app asking permission would overlay above foreground app.

IMO any app specific dialog should live in the app, any system-specific dialog shouldn't. It's the app firing the network error or whatever error, not the homescreen app.

It's easier to modify apps/system/js/error.js then create a new system wide overlay if you are talking about "won't modify a lot".

Comment 15

[Francis Djabri [:djabber]]

> IMO any app specific dialog should live in the app, any system-specific
> dialog shouldn't. It's the app firing the network error or whatever error,
> not the homescreen app.

Hi Alive, 

I agree with you. If an application is launched, it should load some content before the connectivity error dialog is shown. From my understanding, however, there are some applications that require a connection even to launch, and this is what the spec is referring to. In these cases, we could use a generic background if the app cannot provide one itself. Thoughts?

Comment 16

[Sergi]

When the user launches an app we're displaying a splash screen. Would it be possible to show the connectivity error message there as an overlay? 

(In reply to Francis Djabri [:djabber] from comment #15)
> > IMO any app specific dialog should live in the app, any system-specific
> > dialog shouldn't. It's the app firing the network error or whatever error,
> > not the homescreen app.
> 
> Hi Alive, 
> 
> I agree with you. If an application is launched, it should load some content
> before the connectivity error dialog is shown. From my understanding,
> however, there are some applications that require a connection even to
> launch, and this is what the spec is referring to. In these cases, we could
> use a generic background if the app cannot provide one itself. Thoughts?

Comment 17

[Sergi]

Francis, i've been reviewing the document you created (Offline MVP v0.1), and have a couple of comments.

- Page 6: When the user clicks on "Try again", what happens while the system is looking for a connection? should we change the info displayed in the overlay to tell him we're looking to connect to a network? One option may be showing just a message and a loading spinner while the process is ongoing, but i think we need to provide some kind of feedback to the user. (same for page 7).
- Page 6: - Is it possible to give the user a more detailed information about the error so she can identify easily how to solve the problem? some states like "there's no data connection", "you have low coverage", "WiFi is turned off" … 
- Page 7: Are we going to have here the same problem Alive identified in order to display the connectivity overlay error? i mean, you propose to launch the error message above the app that launched it, but i'm not sure if that action will be only possible to do when the app you want to launch is opened.
- Page 8: I assume the "Done" button in the settings view will be disabled until the user makes any change. Is that correct? What happens when the user changes the WiFi settings, taps "Done" and goes back to the connectivity action menu? are we going to automatically retry to connect, or the user will need to tap on "Try again"? IMHO it will better to automatically try to connect when the user changes WiFi settings, and display some feedback, as proposed in page 6. Having to tap on "Try again" after changing settings is a little bit confusing. 

Another question i have is the doc only covers the user side connection problems, but maybe we should show an error message for the server connection errors: NET TIMEOUT, UNKNOWN HOST, CONNECTION REFUSED, NOT FOUND, INTERNAL SERVER ERROR (maybe with a wording an average user understands). The point is that he may have connection through WiFi or data, but not being able to connect to a given app. It would make no sense to make him struggle to configure his connection settings if the problem is on the app side. Some documentation you may find useful to read: https://wiki.mozilla.org/images/c/ca/Gaia_Errors_v1_20120805.pdf

Comment 18

[Francis Djabri [:djabber]]

(In reply to Sergi from comment #17)
> Francis, i've been reviewing the document you created (Offline MVP v0.1),
> and have a couple of comments.
> 
> - Page 6: When the user clicks on "Try again", what happens while the system
> is looking for a connection? should we change the info displayed in the
> overlay to tell him we're looking to connect to a network? One option may be
> showing just a message and a loading spinner while the process is ongoing,
> but i think we need to provide some kind of feedback to the user. (same for
> page 7).

Checking the 1.2 pre-release build, there doesn't seem to be a significant delay when the user attempts to retry a connection. Right now, you see the old "Blue screen" flashing briefly before either the connection dialog is reshown, or a new page is loaded. I could see the rationale for showing some progress indicator if the process would take more than a second, but it seems like this isn't the case. 

> - Page 6: - Is it possible to give the user a more detailed information
> about the error so she can identify easily how to solve the problem? some
> states like "there's no data connection", "you have low coverage", "WiFi is
> turned off" … 

That would be great, and certainly what we're intending. But for this particular MVP we decided to only replace the blue screen with a newer, better designed screen, rather than catering to different use cases for the sake of getting something in time for 1.2. We will certainly address these other use cases in the next release, however. 

> - Page 7: Are we going to have here the same problem Alive identified in
> order to display the connectivity overlay error? i mean, you propose to
> launch the error message above the app that launched it, but i'm not sure if
> that action will be only possible to do when the app you want to launch is
> opened.

I'm afraid that I'm not sure what you're referring to here. In b2, the connectivity action menu is being displayed above the open app that launched it. So this goes along with Alive's suggestions as far as I can tell. 

> - Page 8: I assume the "Done" button in the settings view will be disabled
> until the user makes any change. Is that correct? 

Yes, agreed. 

What happens when the user
> changes the WiFi settings, taps "Done" and goes back to the connectivity
> action menu? are we going to automatically retry to connect, or the user
> will need to tap on "Try again"? IMHO it will better to automatically try to
> connect when the user changes WiFi settings, and display some feedback, as
> proposed in page 6. Having to tap on "Try again" after changing settings is
> a little bit confusing. 
> 

I can see your point. In my original proposal before we scaled back, I removed the "try again" button and instead would automatically dismiss the connection menu if a connection had been re-established. But again, with the reduced scope, the MVP proposal re-introduces the "Try again" button and for the sake of consistency I feel we should keep the user in control. It could also well be that changing the WiFi settings has no effect on the connectivity, and automatically retrying in this situation would be frustrating.  

> Another question i have is the doc only covers the user side connection
> problems, but maybe we should show an error message for the server
> connection errors: NET TIMEOUT, UNKNOWN HOST, CONNECTION REFUSED, NOT FOUND,
> INTERNAL SERVER ERROR (maybe with a wording an average user understands).
> The point is that he may have connection through WiFi or data, but not being
> able to connect to a given app. It would make no sense to make him struggle
> to configure his connection settings if the problem is on the app side. Some
> documentation you may find useful to read:
> https://wiki.mozilla.org/images/c/ca/Gaia_Errors_v1_20120805.pdf

That's a good point - Peter is checking now whether we can make these differentiations within the scope of the MVP.

Comment 19

[Francis Djabri [:djabber]]

Attachment: offline 1.2 MVP v0.3.pdf

Updated spec based on feedback from Alive and Sergi

Comment 20

[Michael Henretty [:mikehenrty][:mhenretty]]

Francis, could you clarify for me: do we also want the browser itself to have this behavior when getting a 404 page (ie. the Connectivity Action Menu), or just apps that use the blue screen?

Comment 21

[Peter Dolanjski [:pdol]]

> maybe we should show an error message for the server
> connection errors: NET TIMEOUT, UNKNOWN HOST, CONNECTION REFUSED, NOT FOUND,
> INTERNAL SERVER ERROR (maybe with a wording an average user understands).

Doug, do you know if the blue error screen comes up in these scenarios at the moment?

Comment 22

[Peter Dolanjski [:pdol]]

(In reply to Michael Henretty [:mikehenrty] from comment #20)
> Francis, could you clarify for me: do we also want the browser itself to
> have this behavior when getting a 404 page (ie. the Connectivity Action
> Menu), or just apps that use the blue screen?

Michael, we'd want to replace the blue error page with this new UX for all apps, including Browser.

Comment 23

[Candice Serran (:cserran)]

Michael Henretty changed story state to started in Pivotal Tracker

Comment 24

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Michael Henretty [:mikehenrty] from comment #20)
> Francis, could you clarify for me: do we also want the browser itself to
> have this behavior when getting a 404 page (ie. the Connectivity Action
> Menu), or just apps that use the blue screen?

Michael, about the implementation for this one I would like to do that at a Gecko level for some parts since a long time. For instance it would be good if we can specify an error page as an URI (one from the system app for example) into the Settings database for errors handling.

It would make it easy to have a system wide error handling both the system app and the browser app as well as having the error page living literally inside the app instead of having to maintain a overlay on top of it as it is done today.

Also the current situation is a bit weird since the overlay is displayed on top of the actual error page :/

Comment 25

[Marcelino Veiga Tuimil [:sonmarce]]

(In reply to Sergi from comment #17)
> Another question i have is the doc only covers the user side connection
> problems, but maybe we should show an error message for the server
> connection errors: NET TIMEOUT, UNKNOWN HOST, CONNECTION REFUSED, NOT FOUND,
> INTERNAL SERVER ERROR (maybe with a wording an average user understands).
> The point is that he may have connection through WiFi or data, but not being
> able to connect to a given app. It would make no sense to make him struggle
> to configure his connection settings if the problem is on the app side. Some
> documentation you may find useful to read:
> https://wiki.mozilla.org/images/c/ca/Gaia_Errors_v1_20120805.pdf

As we agreed, I have added bug 912445 to cover the case of server side issues

Comment 26

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #24)
> Michael, about the implementation for this one I would like to do that at a
> Gecko level for some parts since a long time. For instance it would be good
> if we can specify an error page as an URI (one from the system app for
> example) into the Settings database for errors handling.

Vivien, I agree with you that having a custom error page in gaia for all mozbrowser frames is a good idea. I'm getting pulled off of this for now to work on Notifications.get() (bug 899574). But I'm going to submit a patch today that handles offline errors for apps using the overlay. Gregor is going to see about having someone fix this for browser as well. If not, I think we can resolve this bug using the overlay for now and then see about replacing the blue screen with something nicer in bug 912445.

Comment 27

[[:fabrice] Fabrice Desré]

Attachment: gecko patch

Gecko patch to redirect about:neterror to app://system.gaiamobile.org/net_error.html

This works fine both in browser pages an in apps. The full url is accessible from document.documentURI and includes parameters to know which error occurred and which page we were trying to load.

Note that if app://system.gaiamobile.org/net_error.html is not there, bad things happen ;)

Here's my test one:
--------8<---------8<----------
<!doctype html>
<html>
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, user-scalable=no">
  </head>
  <body>
   <h1>Network Error!</h1>
   <p id="what"> </p>
  </body>
  <script>
    document.getElementById("what").innerHTML = document.documentURI;
  </script>
</html>
--------8<---------8<----------

Comment 28

[Peter Dolanjski [:pdol]]

Thanks Fabrice.  Just so I'm clear - does this patch cover the new UX that Francis defined, or is it just to help surface the error conditions?

Comment 29

[Michael Henretty [:mikehenrty][:mhenretty]]

Peter, what Fabrice's patch does is allows us to define a custom html page in gaia that will be displayed instead of the ugly Blue Screen. The next step is to move logic/display out of the overlay and fit it into this (net_error.html).

Comment 30

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: Gaia Pull Request

WIP gaia patch.

Note: this implements the UI flow to spec, but does not play nicely with Fabrice's Gecko patch. So, this can be updated in one of two ways: 

1.) add a stub net_error.html page that redirects to this overlay
2.) get rid of the overlay completely, and move all the logic into net_error.html

Number 1 is quick and dirty, number 2 is the right way, but 2 will take a little more time since we have to rip out the old overlay and re-purpose it for this new page. I estimate it to be about 1-2 days of work for me.

Comment 31

[[:fabrice] Fabrice Desré]

Let's do 2.) then.

Comment 32

[(inactive after 6/18) Alive Kuo [:alive]]

I wonder if gecko loads net_error.html for system app, could we(system app) interact with the page?
It looks like we could only do refresh (window.location.reload) in this case.

Comment 33

[[:fabrice] Fabrice Desré]

Which kind of interaction would you like to do? You implement whatever you want in the page, it's all yours.

Comment 34

[(inactive after 6/18) Alive Kuo [:alive]]

If we want to go through 2, we shall deprecate AppError(error.js) in system app because we don't need to listen mozbrowsererror anymore. Gecko automatically loads the page and what we need to do is do another net_error.js loaded in net_error.html and parse the URL according to https://mxr.mozilla.org/mozilla-central/source/docshell/base/nsDocShell.cpp#4575

Fabrice said he knows how to provide app manifest url information here. If we need it.

Comment 35

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 799797 [details] [diff] [review]
gecko patch

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

I think we should add a pref in nsAboutRedirector.cpp instead of this hardcoded url. Also I don't think I can r? something in docshell/base so let's see if bz wants to weight here.
r+ for the b2g/ part.

Comment 36

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 799797 [details] [diff] [review]
gecko patch

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

It makes me think that the b2g/locales folder likely needs an update as well.

Comment 37

[[:fabrice] Fabrice Desré]

Attachment: patch v2

v2 with the following changes:
- no more #ifdef in the nsAboutRedirector, we just use the existing B2GAboutRedirector to override about:neterror
- the url of the page can be set via the 'b2g.neterror.url' preference.
- I added the m=manifestURL if we're not in a NO_APP_ID page. Note that pages from the browser app are seen as being from the Browser app. If we don't want that, we'll need to also filter out pages that are inBrowserElement.

Comment 38

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 800275 [details] [diff] [review]
patch v2

r=me on the docshell bits

Comment 39

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: Gaia PR, adding placeholder net error page.

https://github.com/mozilla-b2g/gaia/pull/12284

Comment 40

[Jason Smith [:jsmith]]

Not blocking as this is not a critical product requirement, but this is important product 1.2 feature (strongly have). Nominate for uplift when landed on master/central with a risk assessment.

Comment 41

[[:fabrice] Fabrice Desré]

Attachment: Part 2 : Whitelist the neterror url in NeckoParent

This patch whitelists the url setup to point to the gaia neterror page. This page comes from the system and can be trusted.

Comment 42

[[:fabrice] Fabrice Desré]

Comment on attachment 806361 [details] [review]
Gaia PR, adding placeholder net error page.

The blue background makes my eyes bleed but I guess that's a feature ;)

Comment 43

[[:fabrice] Fabrice Desré]

Gaia patch landed at https://github.com/mozilla-b2g/gaia/commit/9411c266cffbd1ca81700c27f4cf86e8a80a2e6b

Comment 44

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/integration/b2g-inbound/rev/c8bdac9164ae
https://hg.mozilla.org/integration/b2g-inbound/rev/f5e14b213c0f

Comment 45

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/c8bdac9164ae
https://hg.mozilla.org/mozilla-central/rev/f5e14b213c0f

Comment 46

[Michael Henretty [:mikehenrty][:mhenretty]]

This bug is not fixed yet. The patches Fabrice put in Gecko was to enable us to handle things better in Gaia. We still need the Gaia patch to implement the new UX spec.

Comment 47

[bhavana bajaj [:bajaj]]

(In reply to Michael Henretty [:mikehenrty] from comment #46)
> This bug is not fixed yet. The patches Fabrice put in Gecko was to enable us
> to handle things better in Gaia. We still need the Gaia patch to implement
> the new UX spec.

What are the next steps here ? And who is the best assignee to help with gaia patches ?

Comment 48

[Michael Henretty [:mikehenrty][:mhenretty]]

The next step is to take the feature work I did for this: https://github.com/mozilla-b2g/gaia/pull/11930/files
and port it over to this new net_error.html page. There are still some details that need to be figured out (like permissions), so it's not a straight port. I have begun work on this already.

Comment 49

[Marcelino Veiga Tuimil [:sonmarce]]

What is the status of this bug? Is it close to be finished? Do we still need bug 912445?

I guess Gecko part is finished, and still working on Gaia part, but not sure about relationship with bug 912445, if it will need more Gecko & Gaia work after finishing this bug. Anyone can summarize status?

Comment 50

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #49)
> What is the status of this bug? Is it close to be finished? Do we still need
> bug 912445?
> 
> I guess Gecko part is finished, and still working on Gaia part, but not sure
> about relationship with bug 912445, if it will need more Gecko & Gaia work
> after finishing this bug. Anyone can summarize status?

I haven't had much time to work on this in the last few weeks since it's not koi+. But the status is this, the Gecko work is done, it now needs a fair amount of Gaia work to be completed. We still need bug 912445, and it will need additional work to this one. The current plan is to put in a bare bones offline page, something with only a `Retry` and `Cancel`  buttons, by next Friday (Nov. 8). At that point, work on bug 912445 can continue.

Comment 51

[Marcelino Veiga Tuimil [:sonmarce]]

Thanks for clarifying it! We will keep an eye on progress of this bug in order to resume work on bug 912445

Comment 52

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: GH PR, add basic close/retry screen to net_error.html

We still need three things for this PR:

1.) Bug 936301, so we can test the net_error.html page
2.) We need a gecko patch to allow window.close from net_error.html (I have a WIP for this)
3.) In order for this to work for apps on device you need to do 'make production'. We need to figure out why 'make reset-gaia' doesn't work.

Comment 53

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: windows.patch

try: https://tbpl.mozilla.org/?tree=Try&rev=9d7321727e14

Comment 54

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 829667 [details] [diff] [review]
windows.patch

This patch bypasses security for window.close from within about:neterror page. It is necessary to meet spec requirements here.

Comment 55

[[:fabrice] Fabrice Desré]

Comment on attachment 829667 [details] [diff] [review]
windows.patch

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

We decided to not do that.

Comment 56

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 829667 [details] [diff] [review]
windows.patch

We still need this patch for allowing the net_error.html page to close itself. This is unrelated to net_error loading resources from the system app.

Comment 57

[[:fabrice] Fabrice Desré]

Comment on attachment 829667 [details] [diff] [review]
windows.patch

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

We decided to not do that.

Comment 58

[Gregor Wagner [:gwagner]]

https://hg.mozilla.org/integration/b2g-inbound/rev/5339bec9fde7

Comment 59

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/5339bec9fde7

Comment 60

[Michael Henretty [:mikehenrty][:mhenretty]]

Sorry, forgot to add the keep-open keyword.

Comment 61

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: GH PR, add better net_error.html

Vivien or Fabien, could one of you take a look at this patch? This is a custom about:neterror page to be displayed whenever apps/web pages are offline. I had to add a build step to inline any JS resources since external requests are blocked by the same origin policy (I discussed this with bent & fabrice, and we think inlining is best way forward here).

Comment 62

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 832739 [details] [review]
GH PR, add better net_error.html

I made a few comments. Please ask r? again when those are answered/fixed.

Comment 63

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 832739 [details] [review]
GH PR, add better net_error.html

Vivien, thank you for the feedback. I have updated the PR based on your comments.

Comment 64

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 832739 [details] [review]
GH PR, add better net_error.html

Very close. I just want to have a last look for the innerHTML part. It makes me worried. I didn't think too much about it so I may be overreacted but since the error page is one of the rare place where inline scripts are allowed I just want to be careful there.

Comment 65

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 832739 [details] [review]
GH PR, add better net_error.html

Update based on your comments. I'll squash before merging.

Comment 66

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 832739 [details] [review]
GH PR, add better net_error.html

Can't wait to get rid of this blue screen of death. thanks.

Comment 67

[Michael Henretty [:mikehenrty][:mhenretty]]

master: https://github.com/mozilla-b2g/gaia/commit/41c3fd86a7138d152fb721b48eafe97a9a200e53

Comment 68

[Jason Smith [:jsmith]]

Someone should close out the blocking bugs here to indicate which bugs are fixed by this bug.

Comment 69

[Francis Djabri [:djabber]]

Attachment: offline 1.2 MVP v0.4.pdf

Updated to address bug #942325

Comment 70

[Jason Smith [:jsmith]]

https://moztrap.mozilla.org/manage/cases/?pagenumber=1&pagesize=20&sortfield=created_on&sortdirection=desc&filter-productversion=132&filter-suite=204

Comment 71

[Jason Smith [:jsmith]]

This has gone through a bunch of test runs & has had exploratory testing done on it, so there's a clear picture now of the followups needing to be fixed. Marking as verified as such.