Develop Reference

IOS 15: WebAuthn catches error but still prompts user

The registration process with WebAuthn on IOS works fine and expected. As we use the same code on both android and ios, we dont use discoverable credentials, but instead saves the credential-id in a cookie. If an user deletes his cookie, we can not see if the user has registered previously without prompting the user for registration again. This is okay, and if we get an InvalidStateError (because the user is already registered) we let the user think he has registered again, and just creates a new cookie.
The problem is: When the navigator.credentials.create() is called, the InvalidStateError is catched immideately, before the user have time to do anything about the faceID prompt which shows. When the InvalidStateError is caught, the Registration Completed page shows. This means the completed page is shown behind the face-id prompt, which is very confusing for the user. How can the registration be completed if the face-id prompt is not finished?
On Windows, the error is not thrown before the user has completed the faceid prompt, which means the registration-process is experienced exactly as a first-time registration.
Is it a bug that the prompt is shown after the error is thrown? Any tips to how i can work around this? If this is not the right forum to ask - where is a better place?
Best regards, Nina

Is it a bug that the prompt is shown after the error is thrown? Any tips to how i can work around this? If this is not the right forum to ask - where is a better place?
This feels like a bug in WebKit. My recommendation is to submit a bug report over at https://bugs.webkit.org/. If you can, include a video showing the issue using iOS' screen recorder; it'll probably be impossible to capture a screenshot mid-registration because in my experience iOS dismisses the Face ID prompt if you try to take one.

How to run a function on close in a Chrome App?

I'm having an issue where closing my Chrome App too quickly after completing a stage corrupts the save data. This is because it's in the middle of saving some data.
Is there any way to keep the Chrome App open for a few seconds after the user presses close or alt+f4? Or another solution that maybe has a popup telling the user that the app is saving and will close automatically?

You can use the chrome.runtime.onSuspend.addListener( function ) method to specify some code to run when the user quits the app. As stated in the chrome documentation, any code running or triggered in the background/event page will keep the program alive for a short time to allow these processes to end. Remember to register this event listener method in your background/event page before the user has a chance to quit.
Additional information here:
https://developer.chrome.com/extensions/runtime#event-onSuspend

Script to automatically submit form in any browser

Note: I could not think words for this question to search in Google. That's why asking my question. Please bear with me.
I have internet subscription of xyz company and it's login based connection. But what happens is that sometimes login screen reappears and is asking for password. I have already stored user name and password in web page but I have to click on login button to relogin again.
Can I have any script written for this login page that whenever internet connection goes and asks for relogin again, script automatically submit form and get connected with internet?

You're looking for content scripts. There is no cross-browser way to inject code into a web page, but each major browser has a well documented way to do it:
Firefox
Chrome
Internet Explorer
Technically you could also write a script that sniffs HTTP requests using a tool like Wireshark and posts form data whenever it detects the page is displayed, but that doesn't seem like a great solution.

Javascript Confirm method Kills my session data on Safari 5.0.2

There is something seriously wrong here. I am about a 100% sure the confirm method is causing serious issues with sessions on Safari. The confirm prompt basically asks the user to make sure he/she wants to go through with an action before pulling off a Jquery POST. This works fine on every other browser, but on Safari the users session data gets deleted and they get logged out upon refreshing the page. I removed the method and everything is back to normal. Has anyone experienced this before? Very strange... shakes fist at apple
Edit: I tried using Jqueries Dialog widget and I am experiencing the same issues. What do you think is going on?
Edit2: For those who are curious, the alert doesn't wipe out the session data, it just brings the control back to the client end therefore the browser isn't really in touch with its server side. This comment explains it best:
You have to be mindful of where your code is running when you are
using ASP.NET. In your example, since you are using the Session
object, you are running on the server. Your web server has no way of
popping up an alert dialog on the user's machine. Instead, it has to
write JavaScript code to the client, which can then execute this code
and give the user an alert. So, you need to change your approach. If
you need the alert, you will need to feed the information to the
client, and have the entire check take place there, in which case you
lose access to your session variable (stored on the server), so the
only comparison you will be able to do is based on something on that
form or else something that you write out to the client machine.
Reference: http://www.velocityreviews.com/forums/t65880-javascript-alert-function.html
It's ridiculous to see that Safari does not automatically handle this situation like it's counterparts.
Edit3: More proof! A quick google search revealed lots of people on Safari have complaints about getting signed out of facebook randomly. Facebook also has pop up balloon warnings that notify you about important instances such as walking away from a half written message. I get logged out every time that balloon warns me! It's like a tough bouncer for Safari. What is going on here?

Okay, here's the solution, if you are running Safari 5.0.5 UPDATE NOW! 5.0.5 is junk. Call this a coincidence but for me this has reenforced the age long cliche about Apples inability to develop good software.

Implement locking & unlocking a document while editing

Here's the situation:
I have a web-based ticket application, multiple users.
One problem that might occur (and does happen in the old version I'm replacing) is that user1 opens a ticket, edits it, and saves it. But while he was editing it, user2 also opened and saved the ticked. The changes user2 made will be lost/overwritten by user1.
To prevent this I implemented a locking mechanism, it's fairly simply:
On opening a ticket the PHP script checks for existing locks.
If it doesn't find any, it locks & opens the document.
In JS, setTimeout() and an XmlHttpRequest call to unlocks the ticket after 10 minutes (works w/o problems).
I also set an unload event to unlock the ticket when closing/moving away from the window/tab
The problem sits in step 4: The unload event (& it's friend beforeunload) just doesn't work well enough to implement this reliably (for this feature to have any serious meaning, it needs to be reliable), many browsers don't always fire it when I would like it to be fired (Like pressing back button, hitting F5, closing tab, etc. This varies per browser)
The only alternative I can come up with is using a setTimeout() and XmlHttpRequest() call to a php script to tell it the page is still open. If this "heartbeat" monitor fails we assume the user moved away from the ticket and unlock the document.
This seems horribly inefficient to me and quickly leads to many requests to the server with even a few users.
Anyone got a better idea on how to handle this?
It needs to work in IE8+ and other modern browsers (ideally, Firefox, Webkit, Opera). I don't care about IE6/IE7, our organization doesn't use those).

Using heartbeat pings via XHR is the way to go. Depending on the use case you might also want to send them after the user stopped typing in a field instead of every x seconds - this would ensure the page being kept open but inactive would not keep it locked.
If you send those XHRs after the user stopped typing, use one of the keydown/up/press events and a debounce / throttle script to send the request only when the user stops typing for e.g. 5 seconds and one every x seconds (in case it's likely enough the user will be typing for a long time).

Maybe it's not the best solution, but it's worth looking into it : websockets.
You could establish a connection with the server at page load and when the connection fails (ie the client does not respond to the ping), you can unlock the ticket.
Using something like socket.io ensures you that this procedure will work even on ie8.
The main advantage is that you do not send a request every n seconds, but the server sends you a ping every n seconds and you don't have to care about unload/beforeunload events. If the client doesn't respond to the ping, unlock the ticket.
The main disadvantage is that you need a server to handle all your websocket connections, which can be done in almost any server-side language, but it can be a bit harder than a simple web-service (in case of xhr polling)

Implementing ajax heartbeats or unload handlers to unlock the document automatically is tricky.
You problem is that even if you have support for beforeunload in all browsers that you target, it still might not be called if the browser crashes or the user falls asleep.
Look at how webdav works. You explicitly aquire a lock before you start edit, then you save and release the lock explicitly.
Other users can see who has acquired a lock and admins can release locks that has been left behind by accident.