338517 - label failing cross-domain check should trigger xforms-link-error

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[Allan Beaufour]

"Dispatched as an indication of: a failure in link traversal of a linking attribute, in a situation not critical to form processing."
[http://www.w3.org/TR/2006/REC-xforms-20060314/slice4.html#evt-linkError]

Imho that means we should trigger it for failing cross-domain checks too. One could argue that it could be "critical to form processing", but without this there is no way the form author can find out. With the event, an error can at least be displayed to the user.

Comment 1

[Allan Beaufour]

Attachment: Patch

Comment 2

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

Comment on attachment 222590 [details] [diff] [review]
Patch

Makes sense

Comment 3

[aaronr]

My issue with this would be compatibility.  We'd be generating an error in situations when other processors wouldn't.  And in reality, since we don't (and may never for 1.0, it seems) support context info on events, the event notification is practically useless.  The form author can't determine which control is linking to the problematic link or even what the problematic link is so it isn't like any error-recovery handling could really take place.  I'd be more in favor of a mozilla specific 'fatal error' that would trigger the fatal error dialog, which points the user to the JS console to see which link failed.  It would be easy to see in testing without the form author having to code his own message that he would eventually have to remove when they roll out the form.  

But I'm not completely against the idea.  It is a logical interpretation of the spec.  If we are going to take this approach, then I would think that it should be consistent across all of the controls and not just limited to label.  Help, hint, alert, load, and message all generate a xforms-link-error in the same scenario that label does, so if those link traversals fail due to cross-domain checks, then we should send the xforms-link-error then, too.

Comment 4

[Allan Beaufour]

(In reply to comment #3)
> My issue with this would be compatibility.  We'd be generating an error in
> situations when other processors wouldn't.  And in reality, since we don't (and
> may never for 1.0, it seems) support context info on events, the event
> notification is practically useless.  The form author can't determine which
> control is linking to the problematic link or even what the problematic link is
> so it isn't like any error-recovery handling could really take place.  I'd be
> more in favor of a mozilla specific 'fatal error' that would trigger the fatal
> error dialog, which points the user to the JS console to see which link failed.
>  It would be easy to see in testing without the form author having to code his
> own message that he would eventually have to remove when they roll out the
> form.  

<xf:message ev:event="xforms-link-error">
A control failed to retrieve necessary content. Please make sure that XXX, and YYY.
</xf:message>

I would like to include that as a form author. I personally hate pop-ups so, I would probably do a <xf:toggle ev:event="xforms-link-error" case="link-error"/>. I could even switch to a case where controls are using an entirely different model, making the form work in "offline mode" if there's network errors. Just a few quick ideas :-)

> But I'm not completely against the idea.  It is a logical interpretation of the
> spec.  If we are going to take this approach, then I would think that it should
> be consistent across all of the controls and not just limited to label.  Help,
> hint, alert, load, and message all generate a xforms-link-error in the same
> scenario that label does, so if those link traversals fail due to cross-domain
> checks, then we should send the xforms-link-error then, too.

That's a good idea. I'll do a follow-up bug for that.

Comment 5

[Allan Beaufour]

Fixed on trunk

Comment 6

[Allan Beaufour]

(In reply to comment #4)
> (In reply to comment #3)
> > But I'm not completely against the idea.  It is a logical interpretation of the
> > spec.  If we are going to take this approach, then I would think that it should
> > be consistent across all of the controls and not just limited to label.  Help,
> > hint, alert, load, and message all generate a xforms-link-error in the same
> > scenario that label does, so if those link traversals fail due to cross-domain
> > checks, then we should send the xforms-link-error then, too.
> 
> That's a good idea. I'll do a follow-up bug for that.

Bug 338788

Comment 7

[Allan Beaufour]

Attachment: Patch

Also dispatch xforms-link-error on security errors.

If I understand message correct (?), then we were missing a mStopType setting on redirects, which I have now added.

Comment 8

[Allan Beaufour]

Comment on attachment 222847 [details] [diff] [review]
Patch

Ooops. Wrong bug.