Wrong ordering of dispatched events

RESOLVED FIXED

Status

Core Graveyard
XForms
RESOLVED FIXED
11 years ago
a year ago

People

(Reporter: Steve Speicher, Assigned: aaronr)

Tracking

({fixed1.8.0.12, fixed1.8.1.4})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

1.58 KB, application/xhtml+xml
Details
1.40 KB, patch
Doron Rosenberg (IBM)
: review+
smaug
: review+
Details | Diff | Splinter Review
(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070416 Minefield/3.0a4pre
Build Identifier: 

This is for all 4 Rebuild(a), Recalculate(b), Rebuild(c), Refresh(d) as well as all together(e).  These are all normative W3C test cases 10.1.1.(a-e)

Reproducible: Always
(Reporter)

Comment 1

11 years ago
Created attachment 261943 [details]
test case (for rebuild only)

see test suite link for all other scenarios

Comment 2

11 years ago
I pretty sure rebuild, recalculate, revalidate and refresh used
to work according to spec at some point. So is this a regression?

Comment 3

11 years ago
'm

Comment 4

11 years ago
What does this actually mean: "This action causes the processing of xforms-rebuild to happen, bypassing the normal event flow"
What is the normal event flow?

Comment 5

11 years ago
Right now model->Rebuild(); is called, but should we just dispatch
xforms-rebuild to model?
(Assignee)

Comment 6

11 years ago
My bad.  I asked SteveS to open this bug.  I looked at this last night and thought it was a bug since I know that even with deferred actions, when rebuild is called directly it executes right away.  I forgot all about it being a direct action that bypassed the event flow.

(In reply to comment #4)
> What does this actually mean: "This action causes the processing of
> xforms-rebuild to happen, bypassing the normal event flow"
> What is the normal event flow?
> 

according to the errata, this means: http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E5c

So looking at the errata: http://www.w3.org/2006/03/REC-xforms-20060314-errata.html#E5, there shouldn't even be an xforms-rebuild event dispatched in this testcase the way I read it.  The xf:insert will defer a rebuild, but then the direct invocation of rebuild should cause the rebuild to happen without dispatching an event and clear the flag for the deferred rebuild.

Can someone else look at this and see if they read this the same way that I do?  So in short I believe the testcase is wrong to say that there should be a rebuild and I think we are wrong since we do send a xforms-rebuild event. 
(Assignee)

Comment 7

11 years ago
ok, all of the logic in the code is correct for the most part.  The issue is that when nsXFormsRebuildElement::HandleAction calls nsXFormsUtils::GetModel(mElement), it gets a different value back EVERY TIME.  So when aParentAction->SetRebuild(model, PR_FALSE) is called, it is passing in a different value for model every time.  So when action goes to look to see if that model has already had some deferred flags set on it, like DEFERRED_REBUILD, it won't find the model to clear the flag.  That is why we are doing the deferred rebuild even though we don't need to.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 8

11 years ago
Created attachment 262558 [details] [diff] [review]
patch

fixed bug by qi'ing to nsISupports before storing, retrieving from mDeferredUpdates hashtable in nsXFormsActionElement.
Assignee: xforms → aaronr
Status: NEW → ASSIGNED
Attachment #262558 - Flags: review?(doronr)
(Assignee)

Updated

11 years ago
Attachment #262558 - Flags: review?(Olli.Pettay)

Updated

11 years ago
Attachment #262558 - Flags: review?(doronr) → review+

Updated

11 years ago
Attachment #262558 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 9

11 years ago
checked into trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Whiteboard: xf-to-branch
(Assignee)

Comment 10

11 years ago
checked into 1.8 and 1.8.0 branches
Keywords: fixed1.8.0.12, fixed1.8.1.4
Whiteboard: xf-to-branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.