Closed
Bug 473360
Opened 16 years ago
Closed 16 years ago
Unable to disable CTRL+N shortcut, even after suppressing the event methods via js
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: chiths, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
We have recently ported a thick client application into html. We have to suppress some browser behavior to ensure certain malfunctions not to happen.
We have disable back buuton and forward button via struts2 programming.
We have disabled right clicks by disabling contextmenu via js.
Similar approach to diable CTRL+N is not yielding success. Following is the html to test. The javascript identifies the CTRL+N in firefox, but attempts to disable the default behavior is not working...
---html starts here
<html>
<head>
<title>GS1 US Data Driver</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
<meta HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<META HTTP-EQUIV="EXPIRES" CONTENT="0" />
<script type="text/javascript">
function disableCtrlKey(event){
if ((event.keyCode == 78) && (event.ctrlKey)){
event.cancelBubble = true;
event.returnValue = false;
if(event.stopPropagation)
event.stopPropagation();
if(event.preventDefailt)
event.preventDefault();
alert ("No New Windows:"+event.keyCode+event.cancelBubble+event.preventDefault+event.cancelable);
return false;
}
}
</script>
</head>
<body onKeydown="return disableCtrlKey(event)">
This is a test, please press ctrl+N
</body>
</html>
--html ends here--
Reproducible: Always
Steps to Reproduce:
1.Please use the attached html
2.
3.
Actual Results:
The alert indicating that CTRL+N is to be disables appears. But the new window does not get disabled. It still gets launched.
event.cancelable returns true indicating that CTRL+N can be stopped
Expected Results:
Display the alert and no new window shud be launched
|
||
Comment 1•16 years ago
|
||
Browser is privileged code, so I'd really hope that you can't block it from working. Chances are this is WONTFIX, but I'm moving it into the right component.
Component: Bookmarks & History → General
QA Contact: bookmarks → general
|
||
Comment 2•16 years ago
|
||
Right, content having control over browser shortcuts is intentionally not allowed. If you want to use Firefox in a "kiosk" situation, there are alternative options that might be worth investigating, http://www.google.ca/search?q=firefox+kiosk+mode has some potential leads.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
I think I have not stated my case clearly. By having back and ctrl+N enabled, the application's state handling is compromised in firefox. in IE a new window resolves to a new session. In firefox a new window resolves to the same session. Any number of firefox windows resolve to the same session on the server. This makes using firefox almost not usable. We cannot use the kiosk mode, because it is user driven, we cannot ask 1000's of our customer to do something on their individual m/cs, this beats the purpose of designing a web application, where there is no client side customization/installation required. Also we cannot force customer to change their browsing behavior (use kiosk mode as opposed to normal way). It is sometimes not possible to take a purists stand , because of the complexities involved.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
|
||
Comment 4•16 years ago
|
||
This is WONTFIX, web content should not be able to hijack normal browser usage in this manner. If your application cannot handle a second instance of the same URL with the same session, I suggest you find a way to fix that. We are not going to allow content authors to block users from using their browser as they see fit.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → WONTFIX
|
||
Comment 5•2 years ago
|
||
This is a problem for kiosk / dedicated-system applications, where it's necessary to lock the users into the application.
It took only three hours of production use before one of my users accidentally typed Ctrl+N and couldn't figure out how to recover.
Perhaps these keys might be disabled or disable-able in kiosk mode.
You need to log in
before you can comment on or make changes to this bug.
Description
•