695066 - Provide better user experience when errors (including networking and SSL errors) cause us to fail to load a subresource

Status: NEW

(Core :: Networking, defect, P5)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Right now, we silently ignore unsuccessful attempts to load CSS, Javascript, and other subresources. Should we have some indication that the subresources failed to load and/or why? Should we automatically retry to load subresources in certain error conditions (e.g. failure to connect and/or a truncated or corrupted response)?

Until recently, we would show a modal dialog box in the event that an SSL-specific error caused us to fail to load a subresource. Bug 682329 removed this dialog box, so that SSL-related errors are treated like other networking errors.

Comment 1

[Honza Bambas (:mayhemer)]

As I have spotted, Chrome shows an error in the content in place of the resource - a nice frame with the chrome icon and text: "resource failed to load because blah blah".  That is a perfect and pretty logical way to show an error for both developers AND common users.  We should have something like that too, not just for the main page but for iframes, images with respect to dimensions of an object on the rendered page.  Error dialogs are for common users useless - there is no context a dialog is bound to, so no one probably knows where from the error comes and what has actually failed.

Not sure what to do for resources non-visible in the content like CSS/JS.  IE 6 to 8 used to show an /!\ icon in status bar telling the user that something went wrong.  It used to be displayed almost every time because almost all sites were broken.  So not much information.

Any current browser (IE9,Chrome) don't have an identification that some hidden subresource were not loaded.

Comment 2

[Jennifer Morrow [:Boriss] (UX)]

This sounds like a good thing to fix.  I'm having trouble finding a place to reproduce the problem, though: Brian or Honza, do you have a link with failing resources to use as a test here?

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Jennifer, it is not hard to generate test cases. Just create a normal, valid HTML document, and then add one of:

   <img src='http://example.org/this-is-going-to-return-404.html'/>

or:

   <script src='http://host-without-DNS-entries.org/'>

or:

   <link rel='stylesheet'
         type='text/css'
         href='http://example.org/this-is-going-to-return-404.html'/>

or
   <!-- Note: https://amazon.com will give a cert error, because
              https://amazon.com uses a cert that is only valid
              for http://amazon.com -->
   <link rel='stylesheet' type='text/css'
         type='text/css'
         href='https://amazon.com/asdf'/>

or whatever.

Prior to the patch that was already checked in for bug 682329, we would show a modal dialog box in the last case (cert error on subresource). Now, we just silently hide the cert error (and don't load any resource), like we do for any other network error. You can see the difference here between Firefox 8 and Nightly.

IMO, it is probably the case that the best UX is for us to try harder to get the resource. For example, right now, we only try to fetch an image once. If that fails because of a network error, we're like "Shucks, we tried. Oh well." But, probably we should automatically retry, e.g. after flushing DNS or checking for captive portals, etc. But, this gets complicated because of DOM events that are supposed to be fired only in certain circumstances; somebody on the content team could probably explain why there would be difficulty there.

At a minimum, we need to report network/SSL/cert failures to the error console. Currently, we log some, but not all, failures. I don't know if being more comprehensive here will be sufficient for web devs, or if we should have special UI in our web dev tools or regular UI for showing this.

Captive portals are a big cause of failures to load resources and sub-resources. See bug 562917.

Comment 4

[Kai Engert (:KaiE:)]

This bug touches two different reasons why we don't load a subresource:

- we can't load it (it's offline)

- we don't want to load it (because it's insecure)

The latter is
https://wiki.mozilla.org/Security/Features/Mixed_Content_Blocker
and bug 62178.

Which may involve UI like
  "we currently don't load things because they are insecure,
   and we hide them by default"

and there is an additional state like
  "we currently DO load things, because the user has requested so,
   please note that this override is active and the page
   shows some of such insecure content".

I don't know how you are going to implement the better user experience,
but if you're going to include a status indicator, it's probably a three state thing:
- no insecure stuff used on page (e.g. sub-resource indicator absent)
- insecure stuff shown
- insecure stuff blocked

If you want to indicate "some resources offline",
in my thinking that would be a completely separate indicator,
and any combination of "secure/blocked/shown" and "offline" is possible.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Kai Engert (:kaie) from comment #4)
> - we don't want to load it (because it's insecure)
> 
> The latter is
> https://wiki.mozilla.org/Security/Features/Mixed_Content_Blocker
> and bug 62178.

Bug 62178 is one reason that the resource isn't loaded due to being insecure (HTTP content in an HTTPS page). However, there are other reasons--e.g. the resource's certificate is untrusted, there was a problem with the SSL handshake (e.g. strict renegotiation extension support is enabled and the server doesn't support the renegotiation extension), etc. Some of these blur the line between "we can't load it" and "it's not secure (enough)."

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Jennifer, I propose that we add a stopgap solution for this soon in Firefox for security errors (e.g. SSL certificate errors), using a solution similar to the one that Limi approved of in bug 62178 comment 147 for a very related class of errors, as follows:

When a page loads successfully, but some sub-resources of the page are blocked because of a cert- or SSL-related error, show an infobar that says something along the lines of "Some parts of this page were blocked for security reasons. [Technical details]." Clicking on the "More Info" button would show the specific error messages, e.g.:

"These parts of the page were blocked due to error SEC_ERROR_UNTRUSTED_ISSUER:

     https://images.self-signed-site.com/image1.png
     https://whatever.self-signed-site.com/foo.css"

 These parts of the page were blocked due to error SEC_ERROR_WHATEVER:

     https://adnetwork.com/tracking-pixel.png"

The idea here is that we don't spend too much effort feeding the user a bunch of jargon that attempts to explain the problem to them, but we make it possible for them to copy/paste something that they can send to their IT person and/or to the website author and/or to us. This is similar to the approach that Microsoft has taken for kernel-level errors (BSOD) in Windows 8; they say something like "Error 0x01230323. Search on the internet for that number for more information."

Again, this would just be a stopgap solution that would let the security and PSM teams move forward with some security changes that are seen as being urgent, without silently failing to load parts of pages. We suspect (but haven't verified) that these types of errors will be very rare, but they cause very confusing behavior when we do not show any notification for them.

Anyway, I am open for suggestions. I actually think we can do a lot better than this, long-term, but we (security people) are hoping that we can put together *some* kind of solution in time for the Firefox 14 release, as we've already checked in some compatibility-breaking change in Firefox 14 that will induce such failed sub-resource loads.

Comment 8

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258