set password to close chrome and start chrome as popup - google-chrome

hi im using laravel 8 and my software is pos ..
everything working so good but i have big problem ..
thats sometimes the cashier can refresh the page when the customer is gone without save the invoice
..
so what i did is this ..
document.addEventListener('keydown', (e) => {
e = e || window.event;
if(e.keyCode == 116)
{
var is_admin = $("#is_admin").val();
if(is_admin != 1)
{
e.preventDefault();
// this code here will not allow f5 to work
}
}
});
but the cashiers goes to the address bar and hit enter and like that he refresh the page
also sometimes they hit the refresh button beside url bar
so i start chrome in kisok mode in full screen
but the problem thats he can move the mouse to the top of the browser and the url bar will show again and he can do refresh page ..
so the solution for my problem is there any way to set password in chrome when refresh the page or close the chrome or is there any way to start chrome without close bar and url bar in kisok mode
thanks ..

Based on my research I didn't find anything related to setting a password in chrome for closing, instead, I have other solutions that may help you by considering this closing/refreshing issue happens accidentally.
#1st Solution - Closure Extension
https://chrome.google.com/webstore/detail/closure/jjagagcgljmlnihcilbpbfcglnopepjb
a very simple extension that works by locking the current browser tab. Click the toolbar icon or right-click on a page and select “Confirm Closure”. The favicon for the website in the current tab will turn into a padlock.
if the cashier clicked on the refresh button or the closing button a confirmation popup will show up.
#2nd Solution - Disable Close Button
checkout these 5 software that claims to prevent accidental closing of software by disabling the close button
https://www.raymond.cc/blog/prevent-program-closing-disabling-close-button/
#3rd Solution - Saving Draft.
The last solution I have is a workaround you can make by using
window.addEventListener('beforeunload', function (e) {
// saving current invoice in localstorage to be retrieved later
});
// check this answer
// https://stackoverflow.com/questions/13443503/run-javascript-code-on-window-close-or-page-refresh
beforeunload event, so you can save a draft of the current invoice in locale storage before closing the window, but you are should be very aware of how to manage these drafts, when to retrieve them, and when to clean them.
Also, you can use service workers if you choose this kind of solution.
Again, this all about if the cashier accidentally makes this behavior, which I think he must be aware of what he is doing, so you are making your validations as you can to prevent such behavior and make your system as robust as possible, I encourage you to think of this problem in a technical way then you should take the 3rd solution, and for the client just offer him the other 2 solutions which I see they will work well, otherwise, if the client wants to make something wrong in purpose then it will be his responsibility.

Related

Opening a new window/tab without changing focus (Chrome)?

I have a problem with focusing between browser windows/tabs. I would be very grateful for some input! :-)
Our main target browser is Chrome. And I know that the rules for what's allowed has changed over the years - because these features have been constantly abused... I've looked at a lot of older answers, e.g. I need to open a new window in the background with JavaScript, and make sure the original is still focused, but I haven't found anything that will work today. (Apparently this is called a "pop-under" window.)
In our application, in window-A, we want to open another window/tab, window-B, with a certain URL. But the focus should remain on window-A. We have full control of the webpages that are loaded in both windows, and they are loaded from the same domain.
This won't work (in window-A):
window.open('mydomain.com/second-page');
window.focus();
And this won't work (in window-B, after load):
window.opener.focus();
For a number of years now, Chrome hasn't allowed a window to set focus to itself or its parent.
This will actually work:
// in window-A:
window.name = 'HOWDY';
window.open('mydomain.com/second-page');
// in window-B:
window.open('', 'HOWDY');
Opening a blank URL in a named windows, will switch focus to that window - without changing the contents of the target window.
BUT it only works if I put it in an event handler - e.g.:
document.getElementById('mybutton').addEventListener('click', function(e) {
window.open('', 'HOWDY');
});
If I try to do it automatically (after load, or by sending the page a SignalR message), the open-blank-URL-in-named-window trick won't change focus. I suppose it's one of those "only allowed in direct response to user interaction" things. (It will load another page in window-A if I add a URL, though, so the open() call works. But window-B retains focus.)
Is there any way to solve this? Either by not moving focus to window-B in the first place, or by automatically moving focus back from window-B to window-A?
/Anders from Sweden

Would disabling the backspace and enter navigation be a problem for accessibility?

Our app is having an issue in IE where users inadvertently hitting backspace on non-text controls is causing navigation and issues. I've been tasked to suppress the backspace. But we're an app that is required to be 508 compliant. Accessibility is important. Wouldn't suppressing the backspace hurt our accessibility? And if so, Chrome and Edge don't have this issue. Do they not use the same keyboard shortcuts?
Alt + left arrow is standard in most newer browsers for the back button.
As this works in IE as well there is still a way for users to navigate back with their keyboard.
Technically this could be considered a fail as you are interfering with expected behaviour, but I personally think that the inconvenience of having a whole form disappear trumps that so if you decided to disable the backspace key if the currently selected input is empty that would be OK.
Make sure that this only stops normal backspace behaviour if an <input> is currently selected though (or <textarea>) using something like document.activeElement.
This way users can still use backspace to go back if they do not have an input selected.
A "catch all" solution removing the need to disable backspace
One way that you can solve this without disabling the backspace button is with window.onbeforeunload;
Create a flag set to false that changes to true if any input has a value / changes are made etc.
Then use window.onbeforeunload and check the value of that flag. If it is true then show a message, false and return null so no warning is shown.
The following example should work all the way back to IE9 and fire a warning before allowing navigation.
I would encourage you to implement this anyway - it is just as easy to accidentally close the page, hit the physical back button etc. by mistake so doing this protects against all accidental navigation.
var changed = false; // change it to true if an input has a value / has changed.
window.onbeforeunload = function() {
return changed ? "Are you sure you want to navigate away? Unsaved changes will be lost." : null;
}
Edge and Chrome willingly disabled the backspace to go back in history because of the risk of unexpected data loss.
This was removed from Edge in October 2018 and in Chrome 52.
You are perfectly right to disable it as it's intended to protect your users.

Chrome - type=file drag and drop

I have a weird situation. One of my users is using functionality of Chrome (current version, 49, 50), that he drags and drops a file from his folder on local computer to normal input type=file button in a form on the webpage. Once again, let me stress it even more, its normal html input, no fancy javascript, no drag&drop events and handlers, nothing like this. It just takes the name of the dragged file and puts it into the input field, as like he selected it via "normal" way, opening the file select window, locating file on harddrive, selecting the file and confirming.
In some specific situation, this stops working (while doing some edits in the page via javascript / ajax), and I need to "reenable" it.
But, and that is my question, I haven't found any documentation of this "feature" in Google Chrome (or maybe some other browsers as well, I don't know). Why it works, how it works, how it should work and what to do if it stops working :) Does anyone has any experience with this ? The only way how to "fix" it now is to reload the page. I'd love to solve it ... :)
EDIT 1 : I just did a quick test, it works and bugs the same way in Firefox on Win. It doesn't show any error in dev console or any message, it just doesn't add the file as expected.
I've found it. The previous discussion with deceze pointed me to test the javascripts I have on the page, that do not "interfere" with the input type=file ... they weren't any such scripts, but I've found that after doubleclick on the table (that I'm using for editing) this script is being called
$(document).bind('drop dragover', function (e) {
e.preventDefault();
});
and there wasn't any unbind action when table is saved ... this caused the drag and drop everywhere on the page to stop working after the edit.

chrome goes back 2 times instead of one time when using history.pushState/location.hash

open a new tab in Chrome (opens http://google.com for example)
open a testpage.htm containing history.pushState({},"test","#lightbox");
which changes the url to testpage.htm#lightbox
if you hit the back button of your chrome the url is changed to http://google.com, which is two states back, not one
firefox and msie10 work both good, so it's a chrome issue
how can i fix this? is there a workaround?
thank you in advance
(feel free to give my question a better title and feel free to correct my english)
notes:
on step 2 you can also use window.location.hash = "#lightbox" but does the same issue
on step 3 you can simulate the back button from within your code, using history.back() and in this very case the url is switched to the correct one testpage.htm, so this is related only to the back button of Chrome's gui
I also tried
window.addEventListener("popstate", function(ev){ ev.preventDefault(); });
window.addEventListener("hashchange", function(ev){ ev.preventDefault(); });
without success :(
Update 2: does the same using History.js

Deleting localStorage data

What vulnerabilities do i face, when coding a web app utilising localStorage, of a user inadvertently or deliberately delete localStorage data?
I'm happy to put a button saying "Delete my data", this is under my control, but are there ways beyond my control that localStorage data may be deleted? Or not used (ie. Incognito mode/private browsing mode)?
Thanks
Anyone can call localStorage.clear() from the console or location bar at any time. It's possible for a bookmarklet to be used to do the same thing.
Treat localStorage with the same volatility you'd treat a cookie. Assume that it can disappear at any time. It's best used for user-settings and temporary data. If a user clears it, be prepared to use default fall-backs or start the process over.
localStorage is editable by the user , it's similar to the cookies .
User can delete / edit it if he wants , so you should make ur tests on server sides ...
here's an example of how angry birds got hacked ...
http://thenextweb.com/apps/2011/05/11/angry-birds-for-chrome-already-hacked-unlocking-all-levels/
var i = 0;
while (i<=69) {
localStorage.setItem('level_star_'+i,'3');
i++;
}
window.location.reload();
Here's what we found a user can do on iPhone IOS4 and iPad IOS4.
Kill Safari
Double tap your "action button", press and hold the safari button that shows up on the bottom. When the circle with an x in the middle shows up, click the x.
Clear the Safari cache
Settings | Safari | Clear cache
Start Safari back up
Bad news - all sites local storage is cleared, not just yours!