Closed Bug 561817 Opened 14 years ago Closed 14 years ago

Silverlight OpenFileDialog crashes

Categories

(Core :: IPC, defect)

x86_64
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking1.9.2 --- .4+
status1.9.2 --- .4-fixed

People

(Reporter: mohanb, Assigned: benjamin)

References

Details

(5 keywords)

Attachments

(7 files, 2 obsolete files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; InfoPath.2; OfficeLiveConnector.1.4; OfficeLivePatch.1.3; .NET4.0C)
Build Identifier: 3.6.4 (Beta)

Silverlight 2.0 OpenFileDialog crashes in Firefox 3.6.4 Beta. It works fine in 3.6.3 and earlier versions of Firefox, and also in IE.

I am attaching a detailed repro.

Reproducible: Always

Steps to Reproduce:
1. Copy the attached file test.htm and sltest.xap to a local folder.
2. Open test.htm in Firefox 3.6.4 Beta
3. Click on the button. The OpenFile dialog comes up.
4. Try to select a file.

Actual Results:  
The Silverlight plugin vrashes and Firefox hangs.

Expected Results:  
The OpenFile dialog should close and a message box should pop up, displaying the name of the selected file.

You can create sltest.xap as follows:
1. Copy the attach file sltest.zip
2. Extract the file to a local folder.
3. Open the csproj file in Visual Studio 2008, with Silverlight 2.0 Tools installed.
4. Build.

The xap file would be generated under the Bin folder.

Here is the source of test.htm:
----------------------------------------

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
    <title>sltest</title>
   
    <script type="text/javascript">
    	function ShowDlg() {
    		var slCtl = document.getElementById("sl_control");
    		slCtl.content.DlgHlpr.LaunchOpenFileDialog();
    	}
    </script>
</head>

<body>
Hello world
    <br />
    <br />
    <input type="button" value="Click me" onclick="ShowDlg()" />
    <br />
    <br />
    <div style="border:solid red 5px; display:inline-block;">
		<object id="sl_control" data="data:application/x-silverlight," type="application/x-silverlight-2" width="0" height="0">
			<param name="source" value="sltest.xap"/>
			<param name="minRuntimeVersion" value="2.0.31005.0" />
			<param name="autoUpgrade" value="true" />
			<a href="http://go.microsoft.com/fwlink/?LinkID=124807" style="text-decoration: none;">
     			<img src="http://go.microsoft.com/fwlink/?LinkId=108181" alt="Get Microsoft Silverlight" style="border-style: none"/>
			</a>
		</object>
    </div>
</body>
</html>


----------------------------------------

Here is the code in the Silverlight "main page" class (Page.xaml.cs in the zip file):

-------------------------------------------------------------
using System;
using System.Collections.Generic;
using System.IO;
using System.Net;
using System.Windows;
using System.Windows.Browser;
using System.Windows.Controls;

namespace sltest
{
    public partial class Page : UserControl
    {
        public Page()
        {
            InitializeComponent();
            this.Loaded += new RoutedEventHandler(Page_Loaded);
        }

        void Page_Loaded(object sender, RoutedEventArgs e)
        {
            HtmlPage.RegisterScriptableObject("DlgHlpr", this);
        }

        [ScriptableMember]
        public void LaunchOpenFileDialog()
        {
            OpenFileDialog dlg = new OpenFileDialog();
            dlg.Multiselect = true;
            bool? result = dlg.ShowDialog();
            if (result.HasValue && result.Value && dlg.Files != null)
            {
                string s = string.Empty;
                foreach (FileInfo fi in dlg.Files)
                {
                    s += fi.Name + "; ";
                }
                HtmlPage.Window.Alert("You selected: " + s);
            }
        }
    }
}
-------------------------------------
Bulusa, would you mind testing with silverlight 3.0 or 4.0? I don't have access to a SL 2.0 installer so I can't confirm. This would be more pressing if it's a problem in the latest builds of the runtime.

FWIW, I tested your test case with 4.0 and didn't have any trouble.
Hey Jim,

I ahve Silverlight 4.0 installed, byt my code runs in Silverlight 2.0 compat mode. This is important because the OpenFile dialog is launched through JavaScript and this is supported in Silverlight 2.0 only but not Silverlight 3.0 or later. 

To repro the bug, you do NOT need Silverlight 2.0. All you need to do is to use the XAP that I attached. Are you saying that using the attached sltest.xap and test.htm, you were not able to reproduce the bug in Firefox 3.6.4 on Windows 7?

Thanks
Mohan.
(In reply to comment #6)
> Hey Jim,
> 
> I ahve Silverlight 4.0 installed, byt my code runs in Silverlight 2.0 compat
> mode. This is important because the OpenFile dialog is launched through
> JavaScript and this is supported in Silverlight 2.0 only but not Silverlight
> 3.0 or later. 
> 
> To repro the bug, you do NOT need Silverlight 2.0. All you need to do is to use
> the XAP that I attached. Are you saying that using the attached sltest.xap and
> test.htm, you were not able to reproduce the bug in Firefox 3.6.4 on Windows 7?
> 
> Thanks
> Mohan.

Correct. Also testing with our latest "rc2" for 3.6.4 - 

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/

We've landed a number of bug fixes for the next rc of OOPP, which might be playing a role.
Blocks: OOPP
Hey Jim,

I ahve Silverlight 4.0 installed, byt my code runs in Silverlight 2.0 compat mode. This is important because the OpenFile dialog is launched through JavaScript and this is supported in Silverlight 2.0 only but not Silverlight 3.0 or later. 

To repro the bug, you do NOT need Silverlight 2.0. All you need to do is to use the XAP that I attached. Are you saying that using the attached sltest.xap and test.htm, you were not able to reproduce the bug in Firefox 3.6.4 on Windows 7?

Thanks
Mohan.
Please ignore the duplicate comment from me above. I will install and test with your "rc2".
I just installed rc2 from the link you provided. The crash/hang still happened.
Just to be clear, the build I installed was named Namoroka and had the version 3.6.5pre.
(In reply to comment #11)
> Just to be clear, the build I installed was named Namoroka and had the version
> 3.6.5pre.
That's correct.


Steps:

1) open test case
2) click button
3) select a text file from my documents
4) a little dialog pops up stating the name of the file I selected
5) repeat

No crash.

I'll try to get some more testers in here.
Keywords: qawanted
blocking1.9.2: --- → ?
I am able to rperoduce the crash+hang on two separate machines, each of running Windows 7 and Firefox 3.6.5pre, but one having Silverlight 3 runtime, and the other having Silverlight 4 runtime.

I installed Firefox by going to http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/ and running firefox-3.6.5pre.en-US.win32.installer.exe.
Finally caught this on a release m-c build. stacks attached.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file hang stacks
Keywords: qawanted
Good to know! Please let me know when a fix becomes available and I'd be happy to verify on my side.
I was able to recreate this pretty easily on 3.6.4(build1) as well as the latest 1.9.2 nightly on a 64-bit Win7 machine with Silverlight 3. After step 4 in comment #12 I would get an oopsie but the entire browser would freeze, and I had to kill the firefox process

bp-04ae35fe-8dc4-4d4f-bab2-492632100426
be79d8eb-74fa-41fa-8c5c-284e10516c43
Is it the case that all OpenFileDialog calls will be run in compatibility mode? What about the testcase is causing that?

We obviously want a fix, just not sure that it need to block Firefox 3.6.4.
Are you asking why this must be fixed before Firefox 3.6.4 goes out? Invoking Silverlight OpenFileDialog from JavaScript is a common scenario. This bug in Firefox 3.6.4 breaks that scenario and causes the browser to freeze.
All of this bug, except for the last bit about the browser freezing, seems inconsequential. I can reproduce the browser freezing, though. It looks like a Windows bug, almost: the browser is wide awake in its main event loop, but Windows thinks its still blocked on the modal dialog which was already killed.
That may be true, but why does the plugin crash in this specific build of Firefox? That seems to be the root cause..
(In reply to comment #20)
> All of this bug, except for the last bit about the browser freezing, seems
> inconsequential. I can reproduce the browser freezing, though. It looks like a
> Windows bug, almost: the browser is wide awake in its main event loop, but
> Windows thinks its still blocked on the modal dialog which was already killed.

Spin loop isn't running, we don't detect modal UI when they're invoked via script.
Yeah, why not? We should.
(In reply to comment #23)
> Yeah, why not? We should.

We discussed this back when we implemented spin loop for input events, and decided to concentrate on just that for the time being. I think we're at a point now where we could spread that protection around to some of the other client in-calls. I'll work up a patch.
blocking1.9.2: ? → .4+
(In reply to comment #21)
> That may be true, but why does the plugin crash in this specific build of
> Firefox? That seems to be the root cause..

In 3.6.4 we changed the way we handle plugins. Most of the time this will result in greater stability: common plugin crashes won't bring down the entire browser. In a few cases, such as this one, the change introduced new problems. Thank-you for reporting this so we can fix it.
Makes sense, thanks for providing the details. Looking fwd to the fix.
Attachment #442457 - Flags: review?(jones.chris.g)
Functionally the same as bsmedberg's patch, but keeps the RPC-stack tracking code centralized.
Attachment #442457 - Attachment is obsolete: true
Attachment #442505 - Flags: review?(benjamin)
Attachment #442457 - Flags: review?(jones.chris.g)
Attachment #442505 - Flags: review?(benjamin) → review+
Comment on attachment 442505 [details] [diff] [review]
Entered/ExitedCall callbacks for toplevel actors upon RPC in-calls

Looks right to me, I'll be able to test later. Do you want me to just push it with the other patch when it's all done?
Comment on attachment 442505 [details] [diff] [review]
Entered/ExitedCall callbacks for toplevel actors upon RPC in-calls

a=LegNeato for 1.9.2 (preapproving this to speed the process along)
Attachment #442505 - Flags: approval1.9.2.4+
Assignee: nobody → benjamin
Attachment #442487 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #442572 - Flags: review?(jmathies)
Attachment #442572 - Flags: review?(jmathies) → review+
This patch isn't right yet, right-clicking on hulu triggers the hang detector.
blocking1.9.2: .4+ → ?
blocking1.9.2: ? → .4+
I think we still want to block on .4 on this at this point.
Yes, definitely, I reset the flag by accident, bugzilla sucks.
This patch sits on top of the others and restores the NestableTasksAllowed magic.
Attachment #442744 - Flags: review?(bent.mozilla)
Component: General → IPC
Product: Firefox → Core
QA Contact: general → ipc
Comment on attachment 442744 [details] [diff] [review]
Restore the NestableTasksAllowed munging for RPC frames which spin internal event loops, rev. 1

Looks fine to me! Though I would be even happier if you lose the _ prefix on IncallFrame members. r=me either way though.
Attachment #442744 - Flags: review?(bent.mozilla) → review+
Attachment #442572 - Flags: approval1.9.2.4?
Attachment #442744 - Flags: approval1.9.2.4?
Attachment #442572 - Flags: approval1.9.2.4? → approval1.9.2.4+
Attachment #442744 - Flags: approval1.9.2.4? → approval1.9.2.4+
Thanks for fixing this so quickly! Please let me know how/from where I can install the build with this fix, so that I can test my scenario.
No crash or hang in the latest trunk hourly. We'll wait for a new 1.9.2 nightly to test it there before verifying. We'll also test around this.
Testing for this should include re-verifying bugs with hangs, in particular context menus and fullscreen. This bug made a lot of logic more general, with the accompanying risk.
(In reply to comment #41)
> Thanks for fixing this so quickly! Please let me know how/from where I can
> install the build with this fix, so that I can test my scenario.

For the moment, you can get an hourly build from
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-1.9.2-win32/1272660322/ . That will only be there for a short time though.

From tomorrow, there will be a new nightly build containing the fix at the same place as you downloaded from before: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/
Michael, we're actually respinning the nightly 1.9.2 builds right now to pick up this change.
I installed the latest nightly build and verified that the fix works. Thanks for getting this fixed so promptly!

I have noticed that the user agent string has "Namoroka" instead of "Firefox. Is this how it would be when you release this version? THis can break sites that do user agent sniffinbg?
(In reply to comment #46)
> I installed the latest nightly build and verified that the fix works. Thanks
> for getting this fixed so promptly!

Thanks for your report and the testing.

> I have noticed that the user agent string has "Namoroka" instead of "Firefox.
> Is this how it would be when you release this version? THis can break sites
> that do user agent sniffinbg?

Don't worry. The branding is different to avoid confusion if people distribute/use nightly builds (Namoroka is the project name for Firefox 3.6 versions). The official release will be branded as Firefox.
Thanks for testing this Bulusu; I'm verifying it per comment #46.
Keywords: verified1.9.2
So, I just installed Firefox 3.6.6 and was happy to see that the problem mentioned in this bug does happen anymore. HOWEVER, now I see an opposite (sort of) issue. 

When the OpenFile dialog comes up, it is no longer modal! So, I am ble to click back on the parent window and set focus to to it and provide mouse/keyboard events, which ends up breaking my app (because my app assumes that the OpenFile dialog is modal).

Note that this latest issue DOES NOT happen in my reduced sample app that I attached to this bug. It does happen in my real app but unfortunately, I cannot provide a URL that you can access. I will contnue working on creating a small app to reproduce the problem, but I wnated to give you a heads-up.

Thanks
Bulusu Mohan
Ok, I was able to get a repro for the latest issue. It will happen if I mark the Silverlight control as windowless. That is, add the following line in the param list for the OBJECT tag:

<param name="windowless" value="true">

I will create a separate bug to track this.
You need to log in before you can comment on or make changes to this bug.