If you use InfoPath long enough, you will eventually run into a browser publishing error message something like this: "The form template has been published to the server but it can only be opened in InfoPath Filler."
Often the message will tell you to examine Design Checker and resolve any errors that appear there, but if there aren't any errors then this message can feel quite frustrating. Your next step in troubleshooting should be examining the SharePoint logs, but that's not possible if you have a cloud-based installation, such as Office 365, and there's no guarantee the logs will contain useful information. Another tool that can help with troubleshooting is Fiddler, a simple desktop application that allows you to examine the web traffic that is sent back & forth between InfoPath and your SharePoint server during the publishing process---but again, no guarantees that that traffic will contain the answer.
If you've tried all these steps and still don't know what's going wrong, then usually (a) there is a configuration issue with your SharePoint server, or (b) InfoPath has failed to catch an error in your form template. A few weeks ago, I discovered one of these types of errors after a long painstaking search. I'm posting this blog to give you a heads up, in case you've got a similar undetected error in your own template.
For some reason, InfoPath will verify xPaths that contain double forward slashes, like the following:
xdXDocument:GetDOM("Status")/dfs:myFields/dfs:dataFields/d:SharePointListItem_RW//d:ID
In other words, if you have a double slash inside an xPath expression in one of your rules, then InfoPath won't detect it and will treat the xPath as valid.
If you then try to browser publish a form containing such an expression, IPFS---InfoPath Forms Service, the server-side web service that converts templates to browser forms---will throw an error and only publish in filler mode without telling you why. What's more, the associated SharePoint logs won’t point to this xPath as a source of the error, leaving you to find this only by trial & error debugging. Isn't that wonderful?
Now, before you throw up your hands and say you don't have the time to manually examine every single rule in your complex form template, there's an easy way to do this: export the source files (File -> Publish -> Export Source Files) then find the file called manifest.xsf and open it in a text editor, such as Notepad. Then simply search for "//my" and, if you have any data connections in your form, also search for "//d" - this will locate only double forward slashes in the xPath expressions in your template.
So, next time you get a browser publish error alert and InfoPath's Design Checker doesn't show any errors, check your xPaths and see if any of them contain double forward slashes.
Happy Form Designing!
~Jen