Recently, region-level three linkage was used in the project, and the most common dropdownlist sending back was used. For example, it is always quite good. But recently, the customer has changed a new server, I had a problem migrating my website, and the three-level linkage failed.
First, I declare that although this three-level linkage is implemented using server controlsCodeThere is no error. I can confirm that the server control attributes that are not frequently seen on the Internet are incorrect or the method usage is incorrect. New server in website running environment: Windows server2008 64-bit system, iis7, Application Program . NET Framework 4.0, managed pipelines are in integration mode, and 32-bit compatibility mode. Original server: Windows server2008 32-bit system, iis7, application. NET Framework Version 4.0, managed pipeline as integration mode. Local development: Windows 7 32-bit system, IIS express 8, vs2012 test environment: ie10, firefox21, chome27 on my own machine, IE6, 7, 8, 9, and 360 on my colleague machine, browsers such as travel and QQ. Test results:
An error occurs only when the new server and ie10 are combined ( The onselectedindexchanged event of the dropdownlist control is invalid. The problem is that the page will not be sent back after the selection is changed in the drop-down box ). Appendix: capture the following packets for websites on the new server:
Note: In ie10, all browser and document modes have been tried one by one, and the results are the same. From the source code, we can see that there is no onchange event in the HTML code returned by the server to ie10. I don't know where you think the error is? My first response was that the error occurred on the server side and should not be caused by the browser. As we all know, the browser only executes the HTML code, and the HTML code is dynamically returned by the server, the onchange event is obviously lost in the HTML code returned by the server to ie10. Comparing the server environment of the website, I put my focus on the 64-bit system, because the new and old servers are different. As a result, I fell into the trap, the website was re-compiled to a 64-bit environment, and the compilation process was still tortuous. Reference component system. data. SQLite. DLL cannot run in 64-Bit mode. It takes a lot of time to handle the problem, and the result is still incorrect. So far, I have to suspect that it is a browser problem, but my colleagues have not used ie10. So far, I have tested this error on my machine. I think that my boss's new notebook was Win8, so I sent the link to him and asked him to see if there was a problem under ie11. As a result, the boss saw my message cut chart, and all Beijing was running in Sichuan. He thought the database went wrong and asked the manager to solve the problem. When the manager did not read the code, but did not look at the server, he decided that there was a problem with my browser settings. After some settings, the manager "finished ", in fact, it is to add the current website to the compatibility list of IE (the specific method is to add the current website to the Compatibility View in the IE menu bar tool ).
I always thought that the browser mode in F12 was set to "ie10 Compatibility View", which is the same as adding Compatibility View in the IE menu bar tool. I did not expect that there are some differences.
After reading the following section, you will understand that the difference is only a time difference. The Compatibility View added in the toolbar is requested in the compatibility view during the request. The HTML code received by the Compatibility View in F12 is emphasized in the normal ie mode and only parsed In the Compatibility View. There are two solutions to problems we encounter during development. One is like our manager, and the other is fundamentally solved. I generally do not approve of this superficial solution, so I will continue to find a solution. Since the problem occurs in IE, I try to search by keywords such as ie10, finally, I used "Asp.net ie10" for Google. Article This is probably the meaning, and only two Chinese articles are found in the search. I cannot find the original article link, which means ASP. net4.0 was born earlier than ie10, so ASP. in versions earlier than net4.0, the User-Agent header of ie10 is not recognized, and ASP is the consequence. for example, the page error _ dopostback cannot be found, and the cookie function is not supported. This is a. net bug. Microsoft also released a patch. I didn't find the patch in the article (I don't know if it was covered by the subsequent patch or different system patch numbers), but after I updated all the patches on the new server, the error disappeared. From Weizhi note (wiz) time = 22:16:47
