574342 - firefox 3.6.4 hang/crash on onbeforeunload event when silverlight loaded [@ TraceRecorder::record_NativeCallComplete() ]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P1)

Description

[lexxy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4 (.NET CLR 3.5.30729)

Since the update silverlight now causes firefox to hang completely when the following conditions are met:

a) silverlight is loaded on a web page
b) Javascript window.onbeforeunload sets returnValue to a string, causing firefox to prompt to confirm to close the window.

When these condinions are met the browser hangs requiring the process to be terminated.


Reproducible: Always

Steps to Reproduce:
1. Create a page with a silverlight embedded plugin and the following javascript:

window.onbeforeunload = function(e) {
    var e = e || window.event;

    //IE-FF
    if (e) {
        e.returnValue = 'Your changes may not be saved.';
    }
    //Safari
    return 'Your changes may not be saved.';
};

2. Navigate away from this window.
Actual Results:  
Hang, requiring process to be terminated.

Expected Results:  
No hang, prompt to confirm navigation away from the page.

Marked as critical due to hang and loss of data inputted into the LOB silverlight.

Comment 1

[Alice0775 White]

Attachment: testcase (Works For Me)

The testcase include silverlight object and onbeforeunload handler.
however, it Works For Me

Comment 2

[lexxy]

Thank you,

Your test case also works on my machine here. Problem remains with my specific implementation, although I must stress this behaviour was not seen until the automatic update of 3.6.4 applied.

In my specific implementation:

A web page has a jquery driven hyperlink which opens a "FancyBox" (http://fancybox.net/) - a container for my silverlight.

The silverlight is ultimately hosted in an inline frame inside the fancybox.

The child page inside the inline frame is a silverlight applet with the relevant window.onbeforeunload.

Perhaps a test case with an inline framed silverlight, where the inline frame has the window.onbeforeunload code? (hyperlink on the inline frame to another page..)

Regards.

Comment 3

[lexxy]

Attachment: Inline frame test, working here.

I created the above test case (inline frame) and it is working on this machine. Problem remains with my specific implementation however.

After terminating the process, Windows outputs "Plugin container for Firefox has stopped working".

Regards.

Comment 4

[lexxy]

I was able to finally get a crash report.

http://crash-stats.mozilla.com/report/index/bp-3e21e5a2-d850-42f9-ad8e-f9f4a2100624

A user comment indicates a very similar problem:

"This has occured twice now when closing out an instructional video. It seems
when the video is told to close it crashes the browser."

Regards.

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

Signature	TraceRecorder::record_NativeCallComplete()
UUID	3e21e5a2-d850-42f9-ad8e-f9f4a2100624
Time 	2010-06-24 09:07:00.211287
Uptime	425
Last Crash	99612 seconds (1.2 days) before submission
Install Age	84947 seconds (23.6 hours) since version was first installed.
Product	Firefox
Version	3.6.4
Build ID	20100611143157
Branch	1.9.2
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 23 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0xffffffffffffffa0
User Comments	Also tracking this issue on bugzilla
Processor Notes 	
EMCheckCompatibility	False

Frame  	Module  	Signature  	Source
0 	js3250.dll 	TraceRecorder::record_NativeCallComplete() 	js/src/jstracer.cpp:11914
1 	js3250.dll 	js_Interpret 	js/src/jsops.cpp:2246
2 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1368
3 	js3250.dll 	js_InternalInvoke 	js/src/jsinterp.cpp:1423
4 	js3250.dll 	JS_CallFunctionValue 	js/src/jsapi.cpp:5112
5 	xul.dll 	doInvoke 	modules/plugin/base/src/nsJSNPRuntime.cpp:725
6 	xul.dll 	nsJSObjWrapper::NP_Invoke(NPObject*,void*,_NPVariant const*,unsigned int,_NPVariant*) 	modules/plugin/base/src/nsJSNPRuntime.cpp:751
7 	xul.dll 	mozilla::plugins::parent::_invoke(_NPP*,NPObject*,void*,_NPVariant const*,unsigned int,_NPVariant*) 	modules/plugin/base/src/nsNPAPIPlugin.cpp:1849
8 	xul.dll 	mozilla::plugins::PluginScriptableObjectParent::AnswerInvoke(mozilla::plugins::PPluginIdentifierParent*,nsTArray<mozilla::plugins::Variant> const&,mozilla::plugins::Variant*,bool*) 	dom/plugins/PluginScriptableObjectParent.cpp:785
9 	xul.dll 	mozilla::plugins::PPluginScriptableObjectParent::OnCallReceived(IPC::Message const&,IPC::Message*&) 	obj-firefox/ipc/ipdl/PPluginScriptableObjectParent.cpp:1202
10 	xul.dll 	mozilla::plugins::PPluginModuleParent::OnCallReceived(IPC::Message const&,IPC::Message*&) 	obj-firefox/ipc/ipdl/PPluginModuleParent.cpp:446
11 	xul.dll 	mozilla::ipc::RPCChannel::DispatchIncall(IPC::Message const&) 	ipc/glue/RPCChannel.cpp:506
12 	xul.dll 	mozilla::ipc::RPCChannel::Incall(IPC::Message const&,unsigned int) 	ipc/glue/RPCChannel.cpp:492
13 	xul.dll 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne() 	ipc/glue/RPCChannel.cpp:432
14 	xul.dll 	MessageLoop::RunTask(Task*) 	ipc/chromium/src/base/message_loop.cc:336
15 	xul.dll 	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) 	ipc/chromium/src/base/message_loop.cc:344
16 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc:444
17 	xul.dll 	mozilla::ipc::DoWorkRunnable::Run() 	ipc/glue/MessagePump.cpp:75
18 	xul.dll 	nsThread::ProcessNextEvent(int,int*) 	xpcom/threads/nsThread.cpp:527
19 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:118
20 	xul.dll 	xul.dll@0x9b13af 	
21 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:199
22 	mozcrt19.dll 	malloc 	obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:5790
23 	xul.dll 	xul.dll@0x30f133 	
24 	xul.dll 	xul.dll@0x3545b0 	
25 	firefox.exe 	firefox.exe@0x1b97 	
26 	ntdll.dll 	LdrpGetShimEngineInterface 	
27 	ntdll.dll 	_RtlUserThreadStart 	
28 	firefox.exe 	firefox.exe@0x183f 	
29 	firefox.exe 	firefox.exe@0x183f

Unsure if this is related to/Dupe of Bug 539474.

Comment 6

[Andreas Gal :gal]

Crash bugs with working test cases should be hidden until we get a chance to figure out whats going on (imo, please feel free to re-open if you disagree).

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attached test cases don't repro for me. Do we have any mdmps?

Comment 8

[Johnny Stenback (:jst)]

Bug 539474 might be related here.

Comment 9

[lexxy]

I'll try and get you folks more material to work with for this bug, a video or test case when I have time. For now we're developing on 3.5.11 which does not have the problem.

Comment 10

[lexxy]

Attachment: Video of problem

Bug still exists in Firefox 4.0b2.
Please find attached a video of the crash.

Firefox becomes non-responsive when you see the javascript confirm() appear on screen and needs terminating through task manager.

Comment 11

[Damon Sicore (:damons)]

Thanks for the video lexxy.

Comment 12

[Damon Sicore (:damons)]

Lexxy is this a hang or a crash?  Comment 10 seems to imply a hang.

Comment 13

[Robert Sayre]

can you point us at a URL to visit that does crash?

Comment 14

[chris hofmann]

looks like we get about 40 crashes per day with the signature in comment 5

TraceRecorder::record_NativeCallComplete()

top urls for the last 14 days seem to be weighted towards a facebook emoticon page and some on-line training sites. 

  22 http://www.5linxuniversity.com/user/pcms/?f=checkStatus
  21 http://e-formation.institut.minefi.gouv.fr/QCMCCC/index.html
  16 http://treinet.bradesco.com.br/docent/login/index.html
  13 http://www.facebook.com/SweetIM.Emoticons
  10 about:blank
   9 http://learningcenter.apta.org/My_Courses.aspx
   6 https://iatraining.us.army.mil/_chrome/student.php#reqtype=module&course_id=61&module_id=10128&page=2
   6 http://www.jokerclub.ru/freegames/
   6 http://www.insidevalpak.com/irj/portal
   4 https://learning.cypress.com/plateau/user/common/dispatchItemDetailActions.do
   4 https://institucional.bradesco.com.br/extranet3/mensagem.htm
   4 http://www.philsgang.com/pttinstructions.aspx
   4 http://learningcenter.apta.org/AppSvr/LearningCenter/courses/PTCPI/Module1/player.html
   4 http://grow.hp.com/Saba/Web/Main
   3 https://www.tsgp.afpa.fr/accesressources/scormflakes/player.aspx
   3 https://my.usf.edu/webapps/portal/frameset.jsp
   3 https://ielts.britishcouncil.org.hk/iorps/html/content/road-to.jsp
   3 http://www.timeticker.com/
   3 http://www.sefaz.pe.gov.br/
   3 http://www.keyskills4u.com/
   3 http://www.apta.org/AM/Template.cfm?Section=Home&TEMPLATE=/CM/ContentDisplay.cfm&CONTENTID=46049
   3 http://www.5linxuniversity.com/user/pcms/?f=trainings

Comment 15

[lexxy]

@Damon Sicore (:damons)

Yes, it would be best to describe this as a hang. As you can see from the video, once confirm() appears the browser no longer responds to input indefinately.

Comment 16

[chris hofmann]

but then does it crash sometimes as in the case with comment 4 and 5?

Comment 17

[lexxy]

@chris hofmann

I struggled to get a crash report. I had to keep repeating the problem until eventually it did crash instead of hang, I'm not sure if there was anything I did in particular to get the crash report dialog to appear - perhaps I ended the plugincontainer.exe process instead of firefox? I'm not sure.

But to answer your question: yes, sometimes the browser can be crashed with this issue but it is more often a hang right now.

Comment 18

[Daniel Veditz [:dveditz]]

"confirmed" that we see a crash here, although it's not in a "ready-to-fix" state.

Comment 19

[chris hofmann]

if comment 5 is the crash we are tracking in this bug then it looks like we got about 58 of those reports in a sample from yesterday.  looks like it might be cross platform.  all reports are 3.6.x.   might be fixed on trunk, or maybe the beta population just isn't big enough yet.

checking --- TraceRecorder::record_NativeCallComplete 20100816-crashdata.csv
found in: 3.6.8 3.6.3 3.6.4 3.6.6 3.6
release total-crashes
              TraceRecorder::record_NativeCallComplete crashes
                         pct.
all     290649  58      0.000199553
3.6.8   187371  51      0.000272187
3.6.3   12687   3       0.000236463
3.6.4   3703    2       0.000540103
3.6.6   10922   1       9.15583e-05
3.6     6088    1       0.000164258

os breakdown
TraceRecorder::record_NativeCallCompleteTotal 58
Win5.1  0.53
Win6.0  0.14
Win6.1  0.22
Mac10.4 0.00
Mac10.5 0.03
Mac10.6 0.07

Comment 20

[chris hofmann]

that http://www.facebook.com/SweetIM.Emoticons test url contines to show up.  that might be the fastest path to trying to find STR by signing up for that facebook group/app

Comment 21

[lexxy]

@ chris hofmann and comment 19

I notice you mention all reports are 3.6.x but I would like to point out that the issue still remains in 4.0b3.

Interestingly, ending process plugin-container.exe in this version allows firefox to resume normally. The behaviour is as follows:

1) trigger the hang as demonstrated in video
2) end process of plugin-container.exe
3) Firefox un-hangs, the confirm() prompt visible on screen can now be used to click OK or cancel. The silverlight in the background does not redraw or displays "plugin has stopped working".

nb) If i click 'ok' or 'cancel' while firefox is hung, these clicks are registered after plugin-container.exe is ended.

Comment 22

[Marcia Knous [:marcia]]

Many of the sites that are noted in Comment 14 are sites that require a login, so I started looking for sites that did not require one. 

http://www.timeticker.com/ was one of these, and although I don't get any crash on http://www.timeticker.com/, the first time I visited the site and selected the "My Time" link I did get a hang and two instances of an OOPP plugin crash (Got the OOPP dialog twice). This is using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b4) Gecko/20100818 Firefox/4.0b4.

Will continue working to see if I can generate a consistent crash on that site or another site in the list.

Comment 23

[chris hofmann]

we probably ought to open this up in a week or two if we can find a good set of STR.  doesn't seem like we are getting any closer.  maybe bc can check automation for the tracerecorder signature and the sweetIM.emoticon site.

Comment 24

[lexxy]

In the meantime we'll be recommending our customers use 3.5.11.
Unfortunately though this would likely mean we specify Internet Explorer 8 as our main supported browser.

If the bug remains stale in the long term we'll investigate alternative javascript which may remove the problem. If time and resources allow I will try and build a test case for you which meets the same criteria as our crashing web application - but I'm not sure when just yet.

Regards.

Comment 25

[Daniel Veditz [:dveditz]]

lexxy: 
We're not seeing this crash in Firefox 4, though the beta audience isn't as broad as the 3.6 audience. Can you reproduce the problem in Firefox 4? We've made many changes to the trace engine so it's possible we've fixed it.

Comment 26

[Jesse Ruderman]

Check a nightly from http://nightly.mozilla.org/, because the latest beta doesn't yet have the biggest JS engine changes.

Comment 27

[lexxy]

Attachment: Hanging Test Case (Always Hangs For Me)

Hello All,

I've built a test case that reproduces my problem 100% of the time in every version of firefox (including nightlies) post v3.5.

Hopefully this will shed some light on the issue.

Kind regards.

Comment 28

[David Anderson [:dvander] - inactive, e-mail if emergency]

I can reproduce the problem in comment #27 - hang, not a crash - but I'm not convinced it's in the JS engine. The stack I see:

 	ntdll.dll!_KiFastSystemCallRet@0() 	
 	user32.dll!_NtUserWaitMessage@0()  + 0xc bytes	
 	xul.dll!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=1)  Line 161 + 0x11 bytes	C++
 	xul.dll!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x012d89d8, int mayWait=1, unsigned int recursionDepth=1)  Line 317 + 0xf bytes	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012ae3c)  Line 519	C++
 	xul.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x012d89d8, int mayWait=1)  Line 250 + 0x16 bytes	C++
>	xul.dll!nsXULWindow::ShowModal()  Line 419 + 0xb bytes	C++


The loop in ShowModal() is ilooping:

    while (mContinueModalLoop) {
      if (!NS_ProcessNextEvent(thread))
        break;
    }

No JS code is executed through this loop.

Comment 29

[chris hofmann]

jst/bz,  any ideas on the hang stack in comment 28

Comment 30

[Boris Zbarsky [:bzbarsky]]

NS_ProcessNextEvent is supposed to block until there are native events to run.  Does it keep finding events?  If so, which ones?

Comment 31

[Brendan Eich [:brendan]]

This bug is against the wrong component, then? I.e., not JS Engine.

/be

Comment 32

[Damon Sicore (:damons)]

Boris, who can answer your question in Comment 30?  Need to get motion on this, and I'm having to keep hunting people down on this one.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Anyone with a debugger and debug build who can reproduce the bug...

I guess I'll see if I can reproduce this on Windows.

Comment 34

[Damon Sicore (:damons)]

bz, any luck here?

Comment 35

[Boris Zbarsky [:bzbarsky]]

I haven't had a chance to get to it yet.  :(

Comment 36

[Jesse Ruderman]

bz says he'll be able to get to this when he's done with fx4 blockers, which could take quite a while.

Comment 37

[lexxy]

Any resolution on this one yet, guys?

Our first customer is now using our newly developed web application however we had to ship using Internet Explorer 8.

Comment 38

[Boris Zbarsky [:bzbarsky]]

See comment 36.  Unless this gets reprioritized or assigned to someone else, it's unlikely to get traction in the next month, at least.

Comment 39

[Marcia Knous [:marcia]]

http://tinyurl.com/29q9uzy links to the crashes in the last week. Bug 539474 is also on file for this stack.

Comment 40

[Daniel Veditz [:dveditz]]

Attacking this from a different angle, this doesn't happen in 3.5.x, right? If we can figure out when it started happening during 3.6 development then it might give us another clue.

Comment 41

[lexxy]

Hello again guys,

How are we doing with this? Seven months later and this bug is still open?

This issue is the crux of our customer-base using IE8 over Firefox, around 250 workstations would now be using the latest version of firefox to run their intranet application if this had been resolved quickly. Perhaps this is small beans but I would of thought browser-share gain in the business sector would be a good thing?

I'll be tracking the resolution with interest.

Regards,

Alexander

Comment 42

[Johnny Stenback (:jst)]

Olli, can you have a look here? Please see comment #28.

Comment 43

[Johnny Stenback (:jst)]

Olli?

Comment 44

[Olli Pettay [:smaug][[e-mail]]]

Ah, sorry. My todo list seems to be increasing ... :)

Comment 45

[Johnny Stenback (:jst)]

This bug's been around for a while, the first thing we should do is to verify this is still a problem with the most recent Silverlight etc. Not holding 5 for this though.

Comment 46

[Johnny Stenback (:jst)]

Ben says he can help look into this.

Comment 47

[Johnny Stenback (:jst)]

Ben, any updates here yet?

Comment 48

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I have not been able to crash yet.

The hang is easily reproduceable on 3.6.17 but is no longer present on 4.0, most likely due to the fact that confirm() doesn't launch a modal window there any more (after dolske's bug 59314).

Additional work has been done to make flash capable of launching its own modal dialogs, bug 648935, and I would expect that if silverlight launches modal dialogs it would now work on trunk.

Not sure what to do here, I'm reasonably certain no one wants to backport non-modal content alert windows. Since I can't get this to crash we could probably unhide this bug.

Comment 49

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Oh, I should mention that I updated to the latest version of Silverlight, 4.0.60310.0, before testing.

Comment 50

[Daniel Veditz [:dveditz]]

lexxy: we can't reproduce any problem in Firefox 4 or 5, so hopefully your customers can use that. We can no longer reproduce a crash in 3.6.x (there have been several js engine changes and Silverlight updates) so we don't think this is a security bug anymore.

We can reproduce the hang in 3.6.x but are unlikely to figure out a fix that's appropriate for that branch.

Comment 51

[lexxy]

Daniel,

Thanks for your comment.
Firefox 5.0 does show some improvement, but there's still a problem here. What happens now is that when the popup appears- you get very odd behaviour. Clicking 'OK' and 'Cancel' does nothing for the first few times - and then suddenly it will work.

However, ultimately, after a few instances of what I described above - Firefox completely hung in exactly the same style as before and needed ending through task manager.

Extra info: This involved launching multiple Silverlight's in the same web page session. The hang occured in the 3rd/4th attempt.

Comment 52

[lexxy]

Some good news here, this issue does appear to be fixed completely in Firefox 6.0.

Comment 53

[(PTO May 7-12) Ryan VanderMeulen [:RyanVM]]

WFM per Comment 52.

Comment 54

[Joshua Mitchell (Inactive)]

Issue is resolved - clearing old keywords - qa-wanted clean-up