306846 - Missing xforms-link-exception when form loaded from file:///

Status: RESOLVED FIXED

(Core Graveyard :: XForms, defect)

Description

[Stephen Pride]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050831 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050831 Firefox/1.6a1

Not sure if this is related to bug 300255 or not.  Also, the spec (to me anyway)
seems a little vague in determining when to throw an xforms-link-exception and
xforms-link-error (BTW, I tried both for the attached testcase, and neither were
caught).  See spec 3.3.1 (schema) and 4.4.2/4.5.3.  xforms-link-exception should
be thrown on an <xforms:model> with an invalid 'schema' attribute.

Reproducible: Always

Comment 1

[Stephen Pride]

Attachment: testcase

Comment 2

[Stephen Pride]

Strange.  Right after submitting this bug, the problem went away.  Not sure how
or why.

Comment 3

[Stephen Pride]

After further investigation, this appears to be a valid bug.  It seems to due
with the URI in the schema attribute and location of page.  For example, the
attached testcase works (i.e., throws the exception) when it resides on
bugzilla, but if the testcase is on the local system and loaded (via: File|Open
file...), the exception is not thrown.  Also, if the page is local and the
schema URI is changed to something like 'http://invalidSchema' and loaded (via:
File|Open file...), the exception is thrown.  Still not sure if this is an
xforms problem or user problem, specifically, but will reopen until it can be
resolved.

Comment 4

[Stephen Pride]

This behavior also occurs with <xforms:instance src=""> (which seems exactly
like bug 300870).

Comment 5

[aaronr]

Debugged this.  This is a timing problem.  XML Events aren't being processed on the action element early enough.  I thought that XML event handlers got attached during parsing or at least by the time the element with the ev:event attribute on it was inserted into the document, but that isn't the case.  nsXFormsMessageElement::ParentChanged and nsXFormsModelElement::DoneAddingChildren are both called before a listener is added to the model.  So in this particular testcase, when @schema is pointed to the local file system, schema->LoadAsync will return a failure code, so dispatchEvent is called right away.  The event xforms-load-exception is correctly dispatched to the model.  However the handler hasn't been created yet by XMLEvents so the event goes by unnoticed.  In the case where @schemas points to a remote file, then LoadAsync returns NS_OK and the thread is spun off.  While the channel is waiting to hear back from the server, XMLEvents adds the event handler.  So when the channel eventually calls the nsXFormsModelElement::OnError method and that dispatches the xforms-link-exception, then nsXFormsMessageElement::HandleAction will get invoked and the modal message will appear.

So in short, this really isn't a bug since we ARE dispatching the message correctly and to the proper element, but it is a problem because we are dispatching the event in such a way that no XML Event handler can possibly handle the event.  UGH!

Any ideas how we can tackle this problem?  Or is a README item?  In the extreme, should a ev:listener at the end of a document listening for a xforms-link-exception on a model inside the html:head tag get a chance to handle the event?

Comment 6

[Steve Speicher]

Test case: 3.3.1.c1
still valid

Comment 7

[Steve Speicher]

(In reply to comment #6)
> Test case: 3.3.1.c1
> still valid
> 
Also,
Test case: 3.3.2.b2

Comment 8

[aaronr]

In the end this bug should be fixed by the patch for bug 315712.  Leaving open so someone will verify these xforms testsuite testcases are fixed before closing this bug.

Comment 9

[Allan Beaufour]

This WFM on both trunk and branch... wrong testcase?

Comment 10

[Steve Speicher]

(In reply to comment #9)
> This WFM on both trunk and branch... wrong testcase?

I still see this bug.  Try detaching the test case to the local filesystem.  It only surfaces as described by comments #3 and #5

Comment 11

[Allan Beaufour]

(In reply to comment #10)
> (In reply to comment #9)
> > This WFM on both trunk and branch... wrong testcase?
> 
> I still see this bug.  Try detaching the test case to the local filesystem.  It
> only surfaces as described by comments #3 and #5

Ok. I changed the summary to reflect that.

Comment 12

[Steve Speicher]

WFM (now 5/22 nightly), the W3C test suite cases now pass...with flying colors.  Dup/res this one?  I think since bug 315712 made it into the build, this one is now fixed.

Comment 13

[Steve Speicher]

WFM (now 5/22), also all referenced W3C test suite cases pass.  

Comment 14

[Allan Beaufour]

Fixed by bug 315712.