295124 - [FIXr]dom.max_script_run_time kicks in to early for xbl content

Status: RESOLVED FIXED

(Core :: XBL, defect, P1)

Description

[Bernd]

I will try to attach svg xbl testcase ( so you need either a svg enabled build
or a ff nightly). When the same script is used from a xml file it does not show
the warning.

Comment 1

[Bernd]

Attachment: reference xml file

Comment 2

[Bernd]

Attachment: binding

Comment 3

[Bernd]

Attachment: css for the ninding

Comment 4

[Bernd]

Attachment: the file that uses the binding

Comment 5

[Bernd]

running the sample from a local disk makes the warning appear much earlier, so
that there will be confusion whether 5 sec elapsed or not

Comment 6

[Boris Zbarsky [:bzbarsky]]

bernd, I can't reproduce this in my Mozilla build (from a week or two ago) or my
Firefox build (from this morning) -- the SVG shows properly, I get no dialog at all.

Comment 7

[Bernd]

Attachment: thats what I get

I get this with my debug build (from yesterday) and a recent ff nightly.
This happens usually at least on the second load.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

I can definitely see the problem on reload.

The issue is that XBL constructors/destructors don't call ScriptEvaluated(), so
they never reset the mBranchCallbackTime on the nsJSContext to zero when
they're done.  They also never reset mBranchCallbackCount.  So on reload in
this case we put up the alert at 5 seconds minus the time the first load
took....

The fix is to just use the nsCxPusher helper to manage the JSContext stack for
us and handle calling ScriptEvaluated as needed.

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 184903 [details] [diff] [review]
Proposed fix

r+sr=jst

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 184903 [details] [diff] [review]
Proposed fix

Requesting 1.8b3 approval.  This makes us not put up the "slow script" alert
incorrectly when XBL is involved.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed.