We Keep Coding

Function __doPostBack() does not work in iOS, iPadOS browsers

I'm developing an ASP.NET Webform website using .NET Framework 4.6, C# and Javascript,
I've used HiddenField to store a value from a navigation drawer, then do a postback to update value in UpdatePanel, but seem that the code stucked at __doPostBack() on iOS, iPadOS browsers (all Safari, Chrome, Firefox), for Windows browsers everything works fine. Below is my Javascript code:
function headChange(e) {
__doPostBack('<%=HiddenField1.ClientID%>', '');
};
I tried several methods found on Internet such as:
Added <browserCaps userAgentCacheKeyLength="256"/> in web.config
Added return false; after __doPostBack('<%=HiddenField1.ClientID%>', '');
Replace __doPostBack('<%=HiddenField1.ClientID%>', ''); by <%= Page.ClientScript.GetPostBackEventReference(HiddenField1, String.Empty) %>;
Added a browser file to App_Browsers folder
but all with no luck,
Has anyone encountered the same problem and found the solution for this?
Thank you very much!

I found the error by do Inspect Element in Sarari, the error is shown as follow:
https://ibb.co/ynL1Zhp
"Function.caller used to retrieve strict caller" cause by __doPostBack function in MicrosoftAjaxWebforms.js
Then I found the solution for this by https://stackoverflow.com/a/25686598/7819116
Now my website works well in iOS browsers
Thank you all for the supports!

Exception when I use InvokeScriptAsync in webview

I have WebView in a UWP application that loads webpage, and I have InvokeScriptAsync Method that calls JS function:
InvokeScriptAsync("myFunction", new List<string>());
This code, fires myFunction correctly, and the return is correct.
function myFunction(){
...
return true;
}
But, when I have strange bug... when I set breakpoint in this call, the app blink and latter stops working correctly, but if I remove this breakpoint, the application works fine.
In another side, when I debug JavaScript with Script option in debug settings, the .NET application Works correctly and apparently JavaScript too, but when myFunction return a value, blink again and app stops working.
I'ts posible that debug application influences the behavior of the application? Any idea to find the bug?
Thanks

I can't set breakpoint in C# code and Javascript code at the same time
It is not a supported feature to debug managed codes(C#) and javascript in one Visual Studio Instance. Please see Support Javascript/Managed mixed mode debugging.

Shortcut Key commands in Chrome not preventing default action

So I am writing a shortcut library and for the most part it works, except for the issue I found right off the bat is in Chrome (haven't tested other browsers since I'm on a chrome book) is that when pressing ctrl+n it creates a new browser window. Basically in jist my code checks if the current key selection is defined and if it is preventDefault and run the exec function of that command.
ie.
if(joinedKeys in commands.cmd)
e.preventDefault();
commands.cmd[joinedKeys].exec();
I've even tried just doing this-
document.addEventListener("keydown",function(e){
e.preventDefault();
});
//as well as window.addEvent...
Neither work. Any suggestions as to stop the default action of the browsers?

See https://stackoverflow.com/a/7296303/5298696
In Chrome4, certain control key combinations have been reserved for
browser usage only and can no longer be intercepted by the client side
JavaScript in the web page. These restrictions did not exist in
Chrome3 and are inconsistent with both Firefox3/3.5 and IE7/8 (on
Windows).

alternative when an older browser does not accept jquery

I have just been altered to the fact that a user of my website is using a very old browser which does not run jquery (in this case Safari 1.x) and as a result can not access the login panel which uses jquery's slideToggle function.
Can anyone think of a fix which detects whether a browser is able to use jquery - and if not make that link go to a different page rather than showing the login panel?

You could a little conditional check like
if(!'jQuery' in window) {
// jQuery is not available
}
or, if Safari 1.x doesn't know about the IN operator (I'm not sure) use
if(!window.jQuery) {
}

I think there are alternative answers to this, but for me, I would have to weigh up the time it will take you to support his obsolete browser (I'm sure there may be other things inside the site), versus the payback to you...

In the plain HTML source code for the the href= of the login link, set that to a plain HTML login page.
Using jQuery, attach the click handler to the link, if this part fails, thats ok, the browser will just follow the href in the link to the plain login page, allowing your old-browser-user to login still.
$(document).ready(function(){
$('#login_link_id').click(function(){
// Your code here
});
});

If you use javascript/jQuery you should ALWAYS ensure your site works perfectly without it. In this case if you have a login popup box; you probably assign a click event assigned after the DOM has loaded.
What you should do is ensure that if jQuery isn't present the link loads a "normal" login webpage as opposed to the popupbox. I use something similar to this:
Log in
<script>
if(!'jQuery' in window) {
$(document).ready(function(){
//assign on click event to loginlink
});
}
</script>
If jQuery doesn't exist then login.html will be opened normally.

Wow, seriously?! Safari 1.x?? Anyhow, try this...
var isJQSupported = false;
$(function() { //shorthand for document.ready
isJQSupported = true;
//your usual code
});
if (!isJQSupported) {
window.location = "http://www.apple.com/safari/download/";
}

To me it sounds like safari 1.X has problems with jQuery internally. Which means simple checks like whether $ exists in the global space or whether $(function) does anything are not going to help.
The most likely root cause will be that javascript throws an error in loading of jQuery itself which will then stop the rest of your javascript code from execution.
There are four viable options here.
Either make the website work with noscript. Replace your login control with pure HTML and postbacks and ask the user to turn javascript off. This option is useful since you won't be fixing the issue for safari 1.x problems specifically.
You can make javascript check for safari 1.X and other non-supported browsers and only load jQuery through script tag injection or ajax if your user is using a supported browser. If the user is using a browser not compatible with jQuery then you can instead use plain javascript.
Get a copy of safari 1.x and see why jQuery breaks. Then fix it and ask for it to pulled into the release of jQuery 1.5. This relies on the fix being something that does can be done without hacking and that the jQuery team agrees is worth adding in.
Ask the user to use a compliant browser.
There might be some more options. I would personally lean towards asking the user to use a compliant browser because supporting Safari 1.x is ridiculous.

This seems like a case where progressive enhancement is needed.
You have to do multiple checks
see if $ exists
see if $.fn exists
[not sure if needed] check if $.support is a function
check for feature support as needed with $.support() http://api.jquery.com/jQuery.support/
At the end of the check, when jQuery reports that features you need are present - the rest of the script can run.
If you're not sure which features mentioned in the support you use, then this might need a single test on Safari 1.x to see what are the values returned by $.support(), but that is what your nasty old-browser-user can do for you (if you prepare code and publish) and report the resulting text. Then you compare the list with other [old] browsers that are accessible and determine features that are required.
The easy way would be to require everything and cancel all scripts if suport for any feature is missing. This will also rule out IE6 and IE7 and opera below 9.something and firefox below 2.0 or including - I'm not sure.

Use a server side language to detect if it's the old safari based on user-agent and load a different javascript file

window.onerror does not work

I have some tricky AJAX code on a form, and sometimes it will fail (don't ask why, I can't get around it). When this happens, I need to trap the error, reset a hidden field indicator, and submit the form naturally so that the user does not have an unpleasant experience. I planned on using window.onerror to do this, but it is never firing! I am using IE8 and all I have to worry about is the IE browser. Is there some gotcha to getting this event to work? Here's my code...
window.onerror = function() {
alert("Error!");
document.getElementById("hidAjax").value = "0";
document.forms[0].submit();
}

"A common problem that bites many developers occurs when their onerror handler is not called because they have script debugging enabled for Internet Explorer. This will be the case by default if you have installed the Microsoft Script Debugger or Microsoft Visual Studio 6.0® (specifically Visual InterDev 6.0™)—onerror handling is how these products launch their debugger. You can disable script debugging for a given instance of Internet Explorer on the Advanced tab of the Internet Options dialog box (note that checking the Disable script debugging setting will apply only to that instance of Internet Explorer):"
http://msdn.microsoft.com/en-us/library/ms976144.aspx

try/catch also introduces an additional error object that only has the scope of the catch. In applications where performance matters, this is not a good idea.

Any reason not to just put a try/catch around the tricky code?