290465 - Visually inform users of errors

Status: RESOLVED FIXED

(Core Graveyard :: XForms, enhancement)

Description

[Allan Beaufour]

How should we visually inform users of errors in a form?

We write messages to the JavaScript console right now, but we should somehow
point the user to the console. At least for fatal errors. We could:
* open the console automatically
* write error content to the document itself, eventually with a link(?) that
opens the console
* popup a xforms:message

Just some ideas...

Comment 1

[aaronr]

popups maybe for SERIOUS/FATAL errors, maybe.  Not for just warnings.  I'd vote
for something kinda like IE does...a little icon appears in the corner when JS
Console has something put in it from the current document.  Or at least allow
for the option of an icon in the corner through a pref, maybe.

If we go with popups or error content, we need to make sure to store the strings
in the xforms.properties file so that they can be translated.

Comment 2

[Zook Valem]

The error icons at the lower left corner in IE, we have a bug like this for
Gecko browsers way, way back somewhere in bugzilla.

Comment 3

[Allan Beaufour]

(In reply to comment #2)
> The error icons at the lower left corner in IE, we have a bug like this for
> Gecko browsers way, way back somewhere in bugzilla.

Possibly bug 47128.

Comment 4

[Allan Beaufour]

*** Bug 273804 has been marked as a duplicate of this bug. ***

Comment 5

[Allan Beaufour]

Attachment: A try for binding-exception

Here's a go at an approach that creates a dialog for binding-exceptions.

It will show a dialog for all binding exceptions on XForms element, so we
should probably eiher stop processing at first exception or only show one
dialog.

What do you think of the approach? The exception is stated as fatal in the
spec, so there's no need to continue afterwards.

A line number for the element would be nice though. And no need for commenting
on the style :)

Comment 6

[Allan Beaufour]

Attachment: Testcase with an illegal bind

Comment 7

[aaronr]

It's pretty nifty.  If we are going to do popups, then I think that we may want
to make sure to have a preference to disable these popups.  Also, maybe a way to
modify the message through a skin?  I could see a corporation wanting to use
their own error message in addition to what we provide.  Something like, "please
contact  xxxxx to report the above error message".  But nice so far.

Comment 8

[Allan Beaufour]

(In reply to comment #7)
> It's pretty nifty.  If we are going to do popups, then I think that we may
> want to make sure to have a preference to disable these popups.

Good idea.

I'm also a bit reluctant to add pop ups, but these errors are fatal, so the user
should really be aware of that. Showing an error page could also be an option,
but if the exception is triggered by the user interacting with a form, I think
it would be nice for the user to still have the form available.

> Also, maybe a way to modify the message through a skin?  I could see a 
> corporation wanting to use their own error message in addition to what we 
> provide.  Something like, "please contact  xxxxx to report the above error 
> message".  But nice so far.

Easy answer: They can distribute their own version of xforms.properties :)

Question is whether this is an implementation detail, or "custom error messages"
should be specified by the WG?
<xf:error-message type="xforms-binding-exception">[string]</xf:error-message>
?

Comment 9

[Allan Beaufour]

(In reply to comment #8)
> (In reply to comment #7)
> > It's pretty nifty.  If we are going to do popups, then I think that we may
> > want to make sure to have a preference to disable these popups.
> 
> Good idea.
> 
> I'm also a bit reluctant to add pop ups, but these errors are fatal, so the user
> should really be aware of that. Showing an error page could also be an option,
> but if the exception is triggered by the user interacting with a form, I think
> it would be nice for the user to still have the form available.

We could also use the "popup blocked bar", showing a message like:
"The form generated a fatal error. Click here for details..."
?

Comment 10

[Allan Beaufour]

Attachment: 2nd rev.

* preference xforms.disablePopup (no UI though)
* fatalError property so dialog is only shown once
* better styling

Comment 11

[aaronr]

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > It's pretty nifty.  If we are going to do popups, then I think that we may
> > > want to make sure to have a preference to disable these popups.
> > 
> > Good idea.
> > 
> > I'm also a bit reluctant to add pop ups, but these errors are fatal, so the user
> > should really be aware of that. Showing an error page could also be an option,
> > but if the exception is triggered by the user interacting with a form, I think
> > it would be nice for the user to still have the form available.
> 
> We could also use the "popup blocked bar", showing a message like:
> "The form generated a fatal error. Click here for details..."
> ?

That's an interesting thought.  If I were the form user, I think that I'd like
that better than the dialog popup.  One less window floating around on my
screen.   Maybe we could make the preference a 3-way one (dialog popup, popup
blocked bar, or nothing)?

Comment 12

[Allan Beaufour]

(In reply to comment #11)
> (In reply to comment #9)
> > We could also use the "popup blocked bar", showing a message like:
> > "The form generated a fatal error. Click here for details..."
> > ?
> 
> That's an interesting thought.  If I were the form user, I think that I'd like
> that better than the dialog popup.  One less window floating around on my
> screen.   Maybe we could make the preference a 3-way one (dialog popup, popup
> blocked bar, or nothing)?

I thought some more about it, and I think it would break the current use of the
"blocked bar". It's, to my knowledge, used for non-crucial information. To
inform about extension downloads from non-trusted domains, blocked popups, and
missing plugins. The user can still navigate the page etc. and ignore the bar.
The user cannot ignore the binding-exception and continue using the form as it
is a fatal error, and the form is most likely in a non-valid state. Hmmm,
somebody must have a more informed opinion about the UI for Firefox...

Note to myself: Remember to make sure that the popup does not show, if the form
author has handled the exception.

Comment 13

[Allan Beaufour]

Do anybody else have comments on this, and/or who could we CC to get some more
informed "UI-comments"?

Comment 14

[Doron Rosenberg (IBM)]

If you notice on trunk, we now use error pages for things like 404s, etc.  We
could do something similar ("Invalid XForms", maybe give a reason).

Comment 15

[Doron Rosenberg (IBM)]

http://lxr.mozilla.org/seamonkey/source/docshell/resources/content/netError.xhtml
isd the neterror file, however one can't add custom error descriptions.

Comment 16

[Christian :Biesinger (don't email me, ping me on IRC)]

(not for 404, only connection refused, no such host, etc.)

Comment 17

[Allan Beaufour]

(In reply to comment #14)
> If you notice on trunk, we now use error pages for things like 404s, etc.  We
> could do something similar ("Invalid XForms", maybe give a reason).

Yes, I've seen that. The difference is that here that we actually have some
content that the user may want to see/save.

Comment 18

[Doron Rosenberg (IBM)]

<beltzner> I'd suggest softening to:
<beltzner> warning icon (I think that might be what you have now, but I wish it
were yellow)
<beltzner> "The form on this page contains an error and will not work properly."
<beltzner> smaller text "See the Javascript console for details"
<beltzner> they'll get "Xform" from the window title, I'm hoping
<doron> right
<beltzner> the goal of the softening is to make it so that if the user ends up
seeing this error, they're not overwhelmed or confused by the difference between
"xform" and "form"
<doron> so not list the error at all. hmm
<beltzner> if it's in the JS console, I think we'd want to push the users that way
<beltzner> s/users/developers using xforms
<beltzner> :)

Here is your UI review :)  alert-icon for the yellow image I believe.

Comment 19

[Allan Beaufour]

(In reply to comment #18)
> <beltzner> I'd suggest softening to:
> <beltzner> warning icon (I think that might be what you have now, but I wish it
> were yellow)
> <beltzner> "The form on this page contains an error and will not work properly."
> <beltzner> smaller text "See the Javascript console for details"
> <beltzner> they'll get "Xform" from the window title, I'm hoping
> <doron> right
> <beltzner> the goal of the softening is to make it so that if the user ends up
> seeing this error, they're not overwhelmed or confused by the difference between
> "xform" and "form"
> <doron> so not list the error at all. hmm
> <beltzner> if it's in the JS console, I think we'd want to push the users that way
> <beltzner> s/users/developers using xforms
> <beltzner> :)

I agree with beltzner. Good thoughts.

> Here is your UI review :)  alert-icon for the yellow image I believe.

Thanks. You had made a better design ready, right?

Comment 20

[Doron Rosenberg (IBM)]

http://www.nexgenmedia.net/temp/alert.png

<dialog id="XFormsBindingDialog"
	minwidth="40em"
	title="&xforms.bindingdialog.title;"
	buttons="accept"
	xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

  <hbox flex="1">
    <hbox align="start">
	    <image class="alert-icon spaced"/>
    </hbox>

    <vbox>
      <description style="padding-bottom: 5px" class="header">The form on this
page contains an error and will not work properly</description>
      <description style="font-size:0.8em;">See the JavaScript Console for
details</description>
    </vbox>
  </hbox>
</dialog>

Comment 21

[Allan Beaufour]

Attachment: 3rd rev.

Ok, this bug just shows a dialog on the first binding-exception received:
 -------------------------------------------------------------------------
|				XForms Error				  |
|									  |
|    The form on this page contains an error and will not work properly   |
| !									  |
|    See the JavaScript Console for details				  |
|									  |
 ------------------------------------------------------------------------- 

(also kills a comment about bug 280366, which is fixed)

Comment 22

[Doron Rosenberg (IBM)]

Comment on attachment 192929 [details] [diff] [review]
3rd rev.

>+<!DOCTYPE dialog SYSTEM "chrome://xforms/locale/xforms.dtd">
>+<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
>+<dialog id="XFormsBindingDialog"
>+        minwidth="40em"
>+        title="&xforms.bindingdialog.title;"
>+        buttons="accept"
>+        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
>+
>+  <hbox flex="1">
>+    <hbox align="start">
>+            <image class="alert-icon spaced"/>
>+    </hbox>
nit: <image> is indented too much

>+
>+    <vbox>
>+      <description style="padding-bottom: 5px" class="header">
>+	&xforms.bindingdialog.description1;
>+      </description>
>+      <description style="font-size:0.8em;">
>+	&xforms.bindingdialog.description2;
>+      </description>
>+    </vbox>
>+  </hbox>

nit 2: perhaps indent the &foo; so that is becomes clear who they live under?

Comment 23

[Allan Beaufour]

Attachment: 3rd rev. w/Doron's comments

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 192942 [details] [diff] [review]
3rd rev. w/Doron's comments

>+<!DOCTYPE dialog SYSTEM "chrome://xforms/locale/xforms.dtd">
>+<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
>+<dialog id="XFormsBindingDialog"
>+        minwidth="40em"
>+        title="&xforms.bindingdialog.title;"
>+        buttons="accept"
>+        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
>+
>+  <hbox flex="1">
>+    <hbox align="start">
>+      <image class="alert-icon spaced"/>
>+    </hbox>
>+
>+    <vbox>
>+      <description style="padding-bottom: 5px" class="header">
>+        &xforms.bindingdialog.description1;
>+      </description>
>+      <description style="font-size:0.8em;">
>+        &xforms.bindingdialog.description2;
>+      </description>

Could you at least put a class attribute to the second <description>.
And it might be even better to remove style attributes and add the styling
to a css file.
Either way r=me

Comment 25

[Allan Beaufour]

Attachment: 3rd rev. -- ready for check in

w/styling in bindingex.css

Comment 26

[Allan Beaufour]

Checked in to trunk

Comment 27

[Doron Rosenberg (IBM)]

already in branch