The default bug view has changed. See this FAQ.

script timer not being reset when Microsoft Silverlight plug-in fires event callbacks to Javascript.

RESOLVED FIXED

Status

()

Core
Plug-ins
P3
normal
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Jaime Rodriguez, Assigned: jst)

Tracking

({verified1.8.1.12})

unspecified
x86
All
verified1.8.1.12
Points:
---
Bug Flags:
blocking1.9 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.2; .NET CLR 1.1.4322; MS-RTC LM 8; .NET CLR 3.5.21022)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.11; .NET CLR 2.0.50727) Gecko/20071127 Firefox/2.0.0.11

When user interacts with the Silverlight plug-in (mouse moves, clicks, etc.) the event handling is via Silverlight calls back onto firefox to execute some javascript. 
The problem is that firefox thinks of most of these callbacks as a single function. For example, 1000 mouse moves sent consecutively in a very short time-frame is timed by Firefox as one single call.. Firefox then times the length of the whole call and often fires "Warning: Unresponsive script".. 


Reproducible: Always

Steps to Reproduce:
Assuming you have default dom.max_script_runtime of 10 seconds
1.http://www.evangelistech.com/jaime/mozilla/ 
2.If you get a "Get Silverlight" icon, click on it and install Silverlight. 
3. Click very quickly 3 times on the red ugly button..
Actual Results:  
If you clicked 3 times very quickly you should see the status window run a 7 second loop once and half way through the second one you will see a "Warning Unresponsive script" message.. 


Expected Results:  
This is 3 separate clicks and 3 call backs from Silverlight to Javascript, so I was it not expecting to time out, since it is under the 10 seconds of dom.max_script runtime..
For example, if I do the same thing with the HTML button; it loops fine 3 times with 7 seconds loops, not firing the warning. 

The Microsoft silverlight folks tell me they are not doing any thing special; they detect the clicks and call on the javascript ( no coalescing ). 
As far as they know there is nothing they can set on Firefox to tell it 'this is a new/unique event'. 

Sorry to not submit a trace; I can't get the symbols from http://developer.mozilla.org/en/docs/Using_the_Mozilla_symbol_server to work with my 2.0.011 firefox; I always get a version mismatch. 

I also tried getting a 3.0.5 from trunk, and there I can get symbols, but I can't install silverlight. It always tell me SL is not installed even though it is and even when I install it in the browswer, it does not load the plugin when I restart.
(In reply to comment #0)
> User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1;
> When user interacts with the Silverlight plug-in (mouse moves, clicks, etc.)
> the event handling is via Silverlight calls back onto firefox to execute some
> javascript. 

Calls back into Firefox how, using what API?

/be
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

9 years ago
Two scenarios:
If we're provided just the name, we call Invoke on our NPObject with the NPIdent converted from the name.
If we're provided the script object (NPObject), we call InvokeDefault on the NPObject.
(Assignee)

Comment 3

9 years ago
This seems to be a problem with the plugin scriptability API implementation.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
(Assignee)

Updated

9 years ago
Flags: blocking1.9?
+'ing and P3.  Johnny, please re-prioritize this bug appropriately.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
(Reporter)

Comment 5

9 years ago
Hi all, 
Since you re-prioritized.. is there any workaround you can suggest for this? 

We have been trying to forward the work via setTimeout () .. that helps but it is not 100% reliable since we are only forwarding the longer requests, the overhead of forwarding every thing felt too high. 
Any thing else we can check to know how much script Mozilla thinks has been run? or any way to fake it so that timers are reset appopriately? 

Thanks in advance, 
(Assignee)

Updated

9 years ago
Assignee: nobody → jst
(Assignee)

Comment 6

9 years ago
Created attachment 295870 [details] [diff] [review]
Untested fix.

This should fix this problem, but I don't have Silverlight installed so I haven't been able to test this yet. Any help testing this would be greatly appreciated.
(Assignee)

Comment 7

9 years ago
Created attachment 295871 [details] [diff] [review]
Untested fix.

Same untested fix excluding an unrelated change that was laying around in my tree.
Attachment #295870 - Attachment is obsolete: true
(Assignee)

Comment 8

9 years ago
Could someone (that means you, Jaime :) test this out for me? There are installable Firefox builds with this change applied available here:

https://build.mozilla.org/tryserver-builds/2008-01-17_11:02-jst@mozilla.com-npruntime-script-timer-reset/
(Reporter)

Comment 9

9 years ago
Hi JST, 
Fix looks great !!  Thanks for fixing.. 

{Apologies for delay, we found new issue w/ Silverlight and Minefield related to an 'optimization' we had made on instantiation of the plugin, will start new thread for that] 
(Assignee)

Updated

9 years ago
Attachment #295871 - Flags: superreview?(jonas)
Attachment #295871 - Flags: review?(jonas)
Attachment #295871 - Flags: superreview?(jonas)
Attachment #295871 - Flags: superreview+
Attachment #295871 - Flags: review?(jonas)
Attachment #295871 - Flags: review+
(Assignee)

Comment 10

9 years ago
Thanks for testing Jaime!

Fix checked in, will be shipped with Firefox 3 (beta3 onwards, plus nightlies starting tomorrow).
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Would be good to get this on the branch, it's a pretty minimal fix.  Still room on the 2.0.0.12 train?  2.0.0.13?
Flags: wanted1.8.1.x?

Comment 12

9 years ago
+1 fixing in 2.0.0.12 - we are affected by this in our plugin as well
Comment on attachment 295871 [details] [diff] [review]
Untested fix.

Requesting approval to get this patch in our queues.
Attachment #295871 - Flags: approval1.8.1.12?
Comment on attachment 295871 [details] [diff] [review]
Untested fix.

approved for 1.8.1.12, a=dveditz for release-drivers
Attachment #295871 - Flags: approval1.8.1.12? → approval1.8.1.12+
note: 1.8.1.12 code-freeze is supposed to be today, please don't forget to land this.
Created attachment 299299 [details] [diff] [review]
1.8 branch patch

GetScriptContextFromJSContext is in nsIScriptContext.h on the branch (same impl).
Comment on attachment 299299 [details] [diff] [review]
1.8 branch patch

Er, except that include is already there, in the previous line. I will not duplicate it!
Attachment #299299 - Attachment is obsolete: true
Landed on the branch for 1.8.1.12 (Firefox 2.0.0.12). Also tested a branch build with the testcase from comment 0.
Keywords: fixed1.8.1.12
Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/2008012822 Firefox/2.0.0.12 using test case. No issues (and no unresponsive script prompt).
Keywords: fixed1.8.1.12 → verified1.8.1.12
I did notice one issue when I went and checked in trunk. I installed Siverlight in order to test this. On this same machine, both Firefox 2.0.0.11 and 2.0.0.12 detected that I installed Silverlight and run the test at the url. If I go there in my trunk build, even after restarting the browser several times, it isn't detecting that I have Siverlight installed. It shows me the icon for installing Silverlight instead.

So, there may be a trunk issue.
Flags: wanted1.8.1.x? → wanted1.8.1.x+
You need to log in before you can comment on or make changes to this bug.