FireFox 3.6.4: Debugging-

FireFox 3.6.4: Debugging-

06-23-2010 3:09 PM |

FF 3.6.4 now isolates plugins in their own process. After upgrading from 3.6.3, I noticed that my breakpoints were no longer being hit and the red circle was the one that tells you that it couldn't attach to the process.

From what I can tell- FF is using "plugin-container.exe" to host the SL plugin and after starting your app, you can Debug|Attach To Process to that process in order to hit breakpoints again.

I'm not sure if there's an automatic way to do this yet.

Re: FireFox 3.6.4: Debugging-

06-23-2010 3:58 PM |

So that's why I can't debug today. Thanks for sharing.

Re: FireFox 3.6.4: Debugging-

06-23-2010 5:23 PM |

There's even more to it. Ever after upgrading to Firefox 3.6.4 a few hours ago, my current Silverlight app crashes every other minute when calling a WCF/RIA service. Sometimes I simply get a "plugin crashed" screen from Firefox that offers me to send in a crash report, sometimes I receive the following error in the callback from the domain context:

"Load operation failed for query 'XYZ'. The input source is not correctly formatted."

The app continues to work without any problems in IE8... extremely annoying. If anyone knows something about this, please let me know.

Edit: After some more research, it got even worse. FF 3.6.4 gives me more weird error messages when I make calls into my other WCF services. Sometimes for example it's something like "The value [very, very long number] cannot be parsed as the type 'DateTime'." I inspected the messages with Fiddler, and they're ok. The values in question (from the error message) are not even in the transferred data. I re-installed Firefox 3.6.3, and who would've thought that - everything's back to normal. I really hope the Mozilla guys will fix this soon.

Re: FireFox 3.6.4: Debugging-

06-24-2010 7:57 AM |

I've filed a bug to the Mozilla team and provided error reports and call stacks. Hopefully they find that information useful and can do something about it.

Regarding the debugging: I think it would be possible to write a VS plugin or similar to attach to the plugin-container.exe process automatically, however there's a simpler solution. You can disable the new isolation feature in Firefox:

1. Type "about:config" into FF's address bar
2. Accept the warning (if applicable)
3. Search for the entry "dom.ipc.plugins.enabled.npctrl.dll"
4. Change its value from "true" to "false" (double-click)
5. Restart the browser

Of course OOPP (that's how it's named) is a useful and good feature. In my opinion the above should only be used to simplify the debugging process for developers, but not recommended to your end users. Also leave it as it is in your testing environment.

Re: FireFox 3.6.4: Debugging-

06-24-2010 8:42 AM |

I've run into some crashing issues during testing. I have the Firefox web developer toolbar installed and usually when my app crashes the error message will be shown as a scripting error and I can see what happened, but generally the app keeps running. Now I just get the Silverlight Plugin has Crashed error.

Thanks for posting how to change back to the old behavior. While the process isolation is overall a good idea, it just doesn't work for Silverlight development.

Re: Re: FireFox 3.6.4: Debugging-

06-24-2010 10:56 AM |

Thanks, worked for me. After 1 1/2 hours cursing MS when it wasn't their fault so shame on me.

Re: FireFox 3.6.4: Debugging-

06-24-2010 7:06 PM |

Here is some more info about my crashes, maybe it helps someone else too. I found out that Firefox 3.6.4 doesn't like custom HTTP headers in requests to WCF/RIA services. Until now, I've been using IClientMessageInspector to inject my custom meta data HTTP headers into the requests. This is what results in (apparently randomly chosen)...

• A crash of the SL plug-in in FF 3.6.4 (mostly when the SL app runs for the first time after FF is started).
• A SL runtime error: "[Character garbage] contains invalid UTF-8 bytes"
• A SL runtime error: "The value [very large, sometimes negative number] cannot be parsed as the type 'DateTime'"
• A SL runtime error: "The input source is not correctly formatted."
• A SL runtime error: "The prefix 'XYZ' is not recognized."

When I remove the custom HTTP headers or disable the message inspector, the errors and also the crashes are gone.

Re: FireFox 3.6.4: Debugging-

06-25-2010 11:52 AM |

 I don't have to be debugging for the plugin-container to crash. Anything that takes a slightly long time causes Firefox to panic. The most frightening one to me is MessageBox.Show. I do have plans to replace all such things with dialogs of my own design, but as it is right now, any time a MessageBox waits for the user to click OK, Firefox kills the plugin for being unresponsive.

 I have changed my config to not use the container anymore, but clearly we cannot expect our users to do this. And I have yet to find some way to set a threshhold that says "Honest, this is going to take a while, but that's okay!"

Re: FireFox 3.6.4: Debugging-

06-26-2010 5:56 AM |

I also use child windows for message boxes, simply because they integrate better and look less ugly. You're right in that we cannot expect users to turn off that (or any other) feature, so at the moment I'm trying to work around any issue that comes across to make it work with a default FF configuration.

dinane:

And I have yet to find some way to set a threshhold that says "Honest, this is going to take a while, but that's okay!"

If you just want to do that using Firefox's configuration, then the setting is "dom.ipc.plugins.timeoutSecs" (also accessible throught the built-in "about:config" page). By default it is set to 10 seconds, and this also is a problem when you debug and step through your code. Firefox kills the plug-in when you inspect your object's states for too long etc. Maybe it's a new way of motivation for devs to debug faster /sarcasm :).

Re: Re: FireFox 3.6.4: Debugging-

06-26-2010 1:23 PM |

Thanks for the Solution MisterGoodcat!

I just noticed this after doing some big changes in a project, and I thought I screwed something up :P

Re: Re: FireFox 3.6.4: Debugging-

06-27-2010 12:20 PM |

Firefox 3.6.6 increases the timeout value mentioned above to a 45 seconds default.

Re: Re: Re: FireFox 3.6.4: Debugging-

06-28-2010 10:40 AM |

 Wow, that cost me about an hour of time... the solution by MisterG fixed it (I upgraded to 3.6.6 but the problem remained until I did that)

 Thanks!

Re: FireFox 3.6.4: Debugging-

06-29-2010 1:13 PM |

I have the same issue. With Firefox 3.6.4 or 3.6.6, calling MessageBox.Show() just completely freezes Firefox. In my case, Firefox becomes totally unresponsive "immediately". I had to kill it using Task Manager.

I won't expect my users would do any config changes. This sucks.

Re: FireFox 3.6.4: Debugging-

06-30-2010 11:31 AM |

I posted the instructions at http://forums.silverlight.net/forums/p/189397/435701.aspx#435701.

Re: Re: FireFox 3.6.4: Debugging-

06-30-2010 2:04 PM |

Actually, there are other issues with Firefox 3.6.4 or 3.6.6 as well.

The most critical one I'm experiencing right now is that with Firefox 3.6.4 or 3.6.6, calling MessageBox.Show() just completely freezes Firefox. In my case, Firefox becomes totally unresponsive "as soon as" I call MessageBox.Show(). I had to kill it using Task Manager.

Of course my application has been working fine till 3.6.4. It's still working fine with IE7/8 and Safari 4/5.

Anyone having this problem?

Re: Re: FireFox 3.6.4: Debugging-

06-30-2010 2:13 PM |

 I noted the same issue. My current plan is to eliminate MessageBox.Show from my project. I do not know if anyone has reported this as a bug to Firefox and/or Microsoft. It is definitely a problem. It was already on my roadmap to eliminate use of that dialog, however, since it doesn't match our UI.

Re: FireFox 3.6.4: Debugging-

06-30-2010 3:48 PM |

MisterG, can you point me to a repro for the WCF/RIA issue; that could help us debug the issue? We have received a similar bug from Mozilla, it would really help if we got more details about the problem.

Re: FireFox 3.6.4: Debugging-

07-07-2010 8:42 AM |

 Thanks man, I needed that.

Re: FireFox 3.6.4: Debugging-

07-07-2010 10:44 AM |

Hi pillappa!

Sorry, I didn't see your request until now. I believe that bug report you received is mine :).Back on topic:

I've found a very reliable way of reproducing the issue with a very simple project. All you have to do is the following:

For the server:

1. Create a custom Attribute that implements IOperationBehavior. That attribute adds a custom DispatchMessageInspector in "ApplyDispatchBehavior".
2. Let the custom DispatchMessageInspector read a custom HTPP header in the "AfterReceiveRequest" method (for simplicity, I stored the result in a static property afterwards).
3. Add a custom entity class to your server project. I found that it's much harder to trigger a crash with value types. Crashing the plug-in is much easier the more complex the transferred data is. I made a simple custom entity class with a Guid as "Key" property and added two string properties, a DateTime property and a nullable integer.
4. Add a custom DomainService to your project.
5. Add a single method to that domain service and attribute it with your custom IOperationBehavior implementation attribute from step 1. I used a "Get" method, because of the custom return entity type.
6. In that method, create a new instance of your custom entity class and fill in some data. I only bounced back the HTTP header the message inspector has extracted, filled in the current date, and generated a 1024 characters random string (not even garbage, only characters from A to Z). Again, it's much simpler to crash the plug-in when you transfer more data. If you only fill in the DateTime property, for example, you may have to invoke the service method like 20 times or more to get an error message.
   

For the client:

1. In the SL client, create a custom endpoint behavior that attaches a custom client message inspector.
2. The custom client message inspector should add a custom HTTP header in the "BeforeSendRequest" implementation. I only added a static string with an "X-MyCustomHeader" key.
3. Add a button or some other mechanism to the UI so you can invoke the service method. Use a callback to inspect the result of the operation.
   

With that setup, I did not manage to make ONE SINGLE successful call into the service with Firefox 3.6.6. I did at least receive an exception on the client-side. The error messages were different from what I've posted above, but still very weird (e.g. "Unexpected end of file. Following elements are not closed: ..."). In at least one out of five attempts, the Silverlight plug-in crashes. Until the configured timeout in Firefox is triggered, the whole browser just hangs and is unresponsive, CPU load for both Firefox.exe and plugin-container.exe is very high (so much for the increased stability).

Additional notes:

• If you inspect the messages with Fiddler2, you can see that they're valid.
• If you try to access the service in IE8, it succeeds without any problems.
• If you disable the plug-in isolation in Firefox (about:config, dom.ipc.plugins.enabled.npctrl.dll => false, browser restart, make sure the process really had been shut-down), the calls to the service succeed without any problems.
• Now the weird part: if you disable the custom HTTP header (remove the lines from the client message inspector) and leave the Firefox plug-in isolation activated, the calls to the service also succeed without any problems!
  

If you need my sample project, ready to go, please send me a private message, or I'll upload it somewhere.
 

Re: FireFox 3.6.4: Debugging-

07-15-2010 12:17 PM |

We have the same problem in our project. IE8 works fine, but with FF or Chrome just about any query fails with 'Load operation failed for query 'FooBar'. The input source is not correctly formatted.'

Observed with:

-Firefox 3.6.6

-Chrome 5.0.375.99

What we have in common with MisterGoodCat is that we inject a custom HTTP header at the client. The server is not doing anything out of the ordinary. Fiddler shows that the query returns with 200 OK and we cannot see any difference in the responses sent back to IE or to FF/Chrome. The custom header is also present in the HTTP request as it should. Leaving out the HTTP header causes everything to work fine again.

The following code shows what we do at the client - we add some code to a WCF RIA domain context partial class that does the HTTP header injection:

 public sealed partial class MyDomainContext
  {
    partial void OnCreated()
    {
      WebDomainClient<IMyDomainServiceContract> webDomainClient = (WebDomainClient<IMyDomainServiceContract>)DomainClient;
      ContextFlowEndpointBehavior contextFlowEndpointBehaviour = new ContextFlowEndpointBehavior();
      webDomainClient.ChannelFactory.Endpoint.Behaviors.Add(contextFlowEndpointBehaviour);
    }
  }

  public class ContextFlowEndpointBehavior : IEndpointBehavior
  {
    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) { }
    public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
    {
      clientRuntime.MessageInspectors.Add(new ContextFlowMessageInspector());
    }
    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher) { }
    public void Validate(ServiceEndpoint endpoint) { }
  }

  public class ContextFlowMessageInspector : IClientMessageInspector
  {
    public void AfterReceiveReply(ref System.ServiceModel.Channels.Message reply, object correlationState) {}
    public object BeforeSendRequest(ref System.ServiceModel.Channels.Message request, IClientChannel channel)
    {
      HttpRequestMessageProperty property = (HttpRequestMessageProperty)request.Properties[HttpRequestMessageProperty.Name];
      property.Headers["MyCustomHeaderName"] = "FooBar;
      return null;
    }
  }

Re: FireFox 3.6.4: Debugging-

07-15-2010 12:46 PM |

Exactly what I'm doing too. I hope there will be a solution soon so I can stop using workarounds for that.

Re: FireFox 3.6.4: Debugging-

07-24-2010 12:11 AM |

this might be a temp workaround: if I globally switch to the Silverlight http stack the problems seem to disappear.

Execute the following line before doing any RIA calls. Eg in the ctor of your main page:

WebRequest.RegisterPrefix("http://", System.Net.Browser.WebRequestCreator.ClientHttp)

Re: FireFox 3.6.4: Debugging-

07-26-2010 11:10 AM |

That's an awesome post! Thanks for sharing!

I, too, am guilty of cursing MS when it was indeed FF causing this one. I've disabled OOPP as instructed and the VS debugger now attaches Silverlight projects completely as normal again, saving me the trouble of having to debug SL in IE, which I'd really, really rather not.