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

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
12 years ago
10 months ago

People

(Reporter: Stephen Pride, Assigned: Doron Rosenberg (IBM))

Tracking

({fixed1.8.0.5, fixed1.8.1})

Trunk
x86
All
fixed1.8.0.5, fixed1.8.1
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

743 bytes, application/xhtml+xml
Details
(Reporter)

Description

12 years ago
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
(Reporter)

Comment 1

12 years ago
Created attachment 194659 [details]
testcase
(Reporter)

Comment 2

12 years ago
Strange.  Right after submitting this bug, the problem went away.  Not sure how
or why.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

12 years ago
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 4

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

Updated

12 years ago
Blocks: 322255

Updated

12 years ago
Assignee: aaronr → doronr
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

11 years ago
Blocks: 326372

Updated

11 years ago
Blocks: 326373

Comment 5

11 years ago
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

11 years ago
Test case: 3.3.1.c1
still valid

Comment 7

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

Comment 8

11 years ago
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.
Depends on: 315712

Comment 9

11 years ago
This WFM on both trunk and branch... wrong testcase?

Comment 10

11 years ago
(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

11 years ago
(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.
Summary: xforms-link-exception not being thrown → Missing xforms-link-exception when form loaded from file:///

Comment 12

11 years ago
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

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

Comment 14

11 years ago
Fixed by bug 315712.
Status: NEW → RESOLVED
Last Resolved: 12 years ago11 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch

Updated

11 years ago
Keywords: fixed1.8.1

Updated

11 years ago
Keywords: fixed1.8.0.5

Updated

11 years ago
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.