kevingy
commented
4 years ago Just so that it's understood, this code was also an attempt to support ASP.NET postbacks using JavaScript in a browser that doesn't support JavaScript. The EventTarget is pushed to the server in a page-round trip and intercepted in the PageLoad event on the ASP.NET WebForms page.
If the SimpleBrowser user changes the user-agent to something more common (Google, Firefox, IE), then IIS (which is where ASP.NET WebForms pages are typically hosted) will send the hidden __EVENTTARGET form input.
Honestly, I'm a bit torn whether or not to remove this code:
- Pro: It works. Although it shouldn't be there, it's performing the function it was intended to perform, even if it's a shameless hack.
- Con: It's an attempt to support JavaScript when SimpleBrowser doesn't support JavaScript.
- Pro: Some Javascript support is better than none, even if it is targeted and an inconsistency.
- Con: There is an easy workaround - just change the user agent.
- Con: This code is making unit testing of this class difficult.
- Pro: Difficult unit testing is usually code-smell that there is a larger problem, whether the problem is architectural or just a shameless hack.
If there are any other opinions here, I'm open.
In AnchorElement.Click() there is code that injects a hidden input for an IIS __EventTarget. (I think I was the who added it, years ago.) This addition was short-sighted. SimpleBrowser shouldn't care what the webserver is. If the code in question is needed, the SimpleBrowser consumer should implement it in their solution rather than to have this hack for IIS executed for every SimpleBrowser user regardless of problem space and webserver.