Closed Bug 882186 Opened 11 years ago Closed 11 years ago

[System] Replace blue offline error page with new UX

Categories

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

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:-, feature-b2g:2.0)

VERIFIED FIXED
1.3 Sprint 4 - 11/8
blocking-b2g -
feature-b2g 2.0

People

(Reporter: sergiov, Assigned: mikehenrty)

References

Details

(Keywords: feature, Whiteboard: [apps watch list][ucid: System51, systemsfe][1.3:p2])

Attachments

(10 files, 4 obsolete files)

333.86 KB, image/jpeg
Details
1.42 MB, application/pdf
Details
348 bytes, text/html
Details
32.06 KB, patch
vingtetun
: review+
bzbarsky
: review+
Details | Diff | Splinter Review
46 bytes, text/x-github-pull-request
fabrice
: review+
Details | Review
1.46 KB, patch
jduell.mcbugs
: review+
Details | Diff | Splinter Review
46 bytes, text/x-github-pull-request
Details | Review
1.46 KB, patch
fabrice
: review+
Details | Diff | Splinter Review
46 bytes, text/x-github-pull-request
vingtetun
: review+
Details | Review
1.39 MB, application/pdf
Details
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!
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.
Whiteboard: [apps watch list]
Summary: [System] 404 on offline apps → [System] Browser error page when an app is offline
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".
Summary: [System] Browser error page when an app is offline → [System] 404 on offline apps
Summary: [System] 404 on offline apps → [System] Browser error page when an app is offline
Summary: [System] Browser error page when an app is offline → [System] Browser start-up error page when an app is offline
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.
Blocks: 870362
Keywords: feature
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.
Attached file 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.
Brad - as we have a UX spec attached now, can you please check to see if this bug is now sprint-ready?
Flags: needinfo?(blassey.bugs)
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?
Flags: needinfo?(blassey.bugs) → needinfo?(krudnitski)
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.
Flags: needinfo?(krudnitski)
Attached file offline 1.2 MVP.pdf (obsolete) —
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.
Summary: [System] Browser start-up error page when an app is offline → [System] Replace blue offline error page with new UX
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.
Attached file offline 1.2 MVP v0.2.pdf (obsolete) —
Updated following Peter's review
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.
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.
(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".
> 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?
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?
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
(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.
Attached file offline 1.2 MVP v0.3.pdf (obsolete) —
Updated spec based on feedback from Alive and Sergi
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?
Assignee: nobody → mhenretty
Flags: needinfo?(fdjabri)
> 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?
Flags: needinfo?(doug.turner)
(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.
Flags: needinfo?(fdjabri)
Michael Henretty changed story state to started in Pivotal Tracker
(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 :/
(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
(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.
Attached patch gecko patch (obsolete) — Splinter Review
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<----------
Attachment #799797 - Flags: review?(21)
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?
Flags: needinfo?(fabrice)
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).
Attached file 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.
Attachment #799949 - Attachment mime type: text/plain → text/html
Let's do 2.) then.
Flags: needinfo?(fabrice)
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.
Which kind of interaction would you like to do? You implement whatever you want in the page, it's all yours.
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 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.
Attachment #799797 - Flags: review?(bzbarsky)
Attachment #799797 - Flags: review?(21)
Attachment #799797 - Flags: review+
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.
Attachment #799797 - Flags: review+ → review-
Attached patch patch v2Splinter Review
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.
Assignee: mhenretty → fabrice
Attachment #799797 - Attachment is obsolete: true
Attachment #799797 - Flags: review?(bzbarsky)
Attachment #800275 - Flags: review?(bzbarsky)
Attachment #800275 - Flags: review?(21)
Comment on attachment 800275 [details] [diff] [review]
patch v2

r=me on the docshell bits
Attachment #800275 - Flags: review?(bzbarsky) → review+
Whiteboard: [apps watch list] → [apps watch list][systemsfe]
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.
blocking-b2g: --- → -
Depends on: 918090
This patch whitelists the url setup to point to the gaia neterror page. This page comes from the system and can be trusted.
Attachment #806988 - Flags: review?(jduell.mcbugs)
Flags: needinfo?(doug.turner)
Attachment #806988 - Flags: review?(jduell.mcbugs) → review+
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 ;)
Attachment #806361 - Flags: review?(fabrice) → review+
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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 ?
Flags: needinfo?(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.
Assignee: fabrice → mhenretty
Flags: needinfo?(mhenretty)
Attachment mime type: text/plain → text/x-github-pull-request
Target Milestone: --- → 1.3 Sprint 3 - 10/25
Blocks: 930630
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?
Target Milestone: 1.3 Sprint 3 - 10/25 → 1.3 Sprint 4 - 11/8
(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.
Thanks for clarifying it! We will keep an eye on progress of this bug in order to resume work on bug 912445
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.
Depends on: 936301
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 on attachment 829667 [details] [diff] [review]
windows.patch

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

We decided to not do that.
Attachment #829667 - Flags: review?(fabrice)
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.
Attachment #829667 - Flags: review?(fabrice)
Flags: in-moztrap?(jsmith)
Comment on attachment 829667 [details] [diff] [review]
windows.patch

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

We decided to not do that.
Attachment #829667 - Flags: review?(fabrice) → review+
https://hg.mozilla.org/mozilla-central/rev/5339bec9fde7
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Sorry, forgot to add the keep-open keyword.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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).
Attachment #832739 - Flags: review?(kaze)
Attachment #832739 - Flags: review?(21)
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.
Attachment #832739 - Flags: review?(21)
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.
Attachment #832739 - Flags: review?(kaze) → review?(21)
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.
Attachment #832739 - Flags: review?(21)
Comment on attachment 832739 [details] [review]
GH PR, add better net_error.html

Update based on your comments. I'll squash before merging.
Attachment #832739 - Flags: review?(21)
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.
Attachment #832739 - Flags: review?(21) → review+
Whiteboard: [apps watch list][systemsfe] → [apps watch list][systemsfe][1.3:p2]
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Someone should close out the blocking bugs here to indicate which bugs are fixed by this bug.
Keywords: verifyme
QA Contact: jsmith
Updated to address bug #942325
Attachment #792509 - Attachment is obsolete: true
Attachment #792604 - Attachment is obsolete: true
Attachment #794281 - Attachment is obsolete: true
Depends on: 949286
Depends on: 949177
Depends on: 949191
Depends on: 952305
Depends on: 956851
Depends on: 956930
Depends on: 957613
No longer blocks: 942325
Depends on: 942325
No longer blocks: 943261
No longer depends on: 936301
Depends on: 937659
Depends on: 940084
No longer depends on: 949177
Depends on: 959704
Depends on: 959800
No longer depends on: 959704
No longer depends on: 956930
Depends on: 963322
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.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Whiteboard: [apps watch list][systemsfe][1.3:p2] → [apps watch list][ucid: System51, systemsfe][1.3:p2]
Depends on: 981906
feature-b2g: --- → 2.0
You need to log in before you can comment on or make changes to this bug.