Last Comment Bug 338517 - label failing cross-domain check should trigger xforms-link-error
: label failing cross-domain check should trigger xforms-link-error
Status: RESOLVED FIXED
: fixed1.8.0.5, fixed1.8.1
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Allan Beaufour
: Stephen Pride
Mentors:
http://www.w3.org/TR/xforms/
Depends on:
Blocks: 338788
  Show dependency treegraph
 
Reported: 2006-05-19 01:45 PDT by Allan Beaufour
Modified: 2016-07-15 14:46 PDT (History)
3 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch (1.12 KB, patch)
2006-05-19 01:45 PDT, Allan Beaufour
bugs: review+
doronr: review+
Details | Diff | Splinter Review
Patch (2.43 KB, patch)
2006-05-22 05:09 PDT, Allan Beaufour
no flags Details | Diff | Splinter Review

Description Allan Beaufour 2006-05-19 01:45:07 PDT
"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 2006-05-19 01:45:56 PDT
Created attachment 222590 [details] [diff] [review]
Patch
Comment 2 Olli Pettay [:smaug] 2006-05-19 01:51:20 PDT
Comment on attachment 222590 [details] [diff] [review]
Patch

Makes sense
Comment 3 aaronr 2006-05-19 09:11:36 PDT
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 2006-05-22 00:08:49 PDT
(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 2006-05-22 01:16:36 PDT
Fixed on trunk
Comment 6 Allan Beaufour 2006-05-22 01:18:38 PDT
(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 2006-05-22 05:09:09 PDT
Created attachment 222847 [details] [diff] [review]
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 2006-05-22 05:10:11 PDT
Comment on attachment 222847 [details] [diff] [review]
Patch

Ooops. Wrong bug.

Note You need to log in before you can comment on or make changes to this bug.