No method for user to control activity and/or state of Javascript functions.

RESOLVED INACTIVE

Status

()

Core
Event Handling
--
enhancement
RESOLVED INACTIVE
16 years ago
7 hours ago

People

(Reporter: Hanspeter Niederstrasser, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

The ability to permanently enable/disable a user defined set of Javascript
functions should be allowed.  For example: the user can control if window.open
can be called by onload/onunload through the GUI, but this can also be done by
adding a pref to user.js.  Through the Prefs | Advanced | Scripts & Windows
panel, several other javascript functions are also controlled (window.status for
example).  This is a very limited subset of existing functions.

Reproducible: Always
Steps to Reproduce:
1. Tools -> Javascript Manager
2. The Javascript Manager should appear
OR
1. Search for \Profiles\profile\salted.slt\chrome\userJavascript.js to edit
2. File does not exist

Actual Results:  Nothing happens.  Neither of the two options described in
"Steps to Reproduce" currently exist.


Expected Results:  Either a Javascript Manager or userJavascript.js should exist
that allow the user to control the activity and/or state (on or off) of
javascript functions.

I first thought of this when I got sick of running across sites using <body
oncontextmenu="false"> and wanted a way to permanently disable that function. 
The solution would be similar to how popups were originally disabled by turning
off window.open when called from onload/onunload (adding a pref to user.js). 
While this would be a single javascript function that is affected, a generalized
system should be created, either via a textfile (through a putative
userJavascript.js similar to how userContent.css can be used to override author
stylesheets) or through a GUI Javascript Manager.

The Scripts & Windows Prefs panel is of necessity limited in scope since it
deals mostly with windows.  By providing either a Javascript specific GUI (maybe
similar to the Cookie Manager), or a user editable text file similar to
userContent.css (for CSS control) or user.js (for general non-GUI reachable
prefs), a similar result can be achieved to enable a user to enable/disable any
javascript function regardless of what the web page calls.

Comment 1

16 years ago
This is not dom events...
Status: UNCONFIRMED → NEW
Component: DOM Events → Browser-General
Ever confirmed: true
(Reporter)

Comment 2

16 years ago
After further hunting through Bugzilla, this bug is definitely related and
similar to bug 38966 as far as the prefs panel suggestion is concerned.  Also,
most of the ideas for how the control backend is being set up are discussed in
http://www.mozilla.org/projects/security/components/ConfigPolicy.html
(Configurable Security Policies).

Marking as duplicate of bug 38966.  Sorry for the spam.


*** This bug has been marked as a duplicate of 38966 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 3

16 years ago
ok, but maybe it would be better to leave this as a separate bug that 38966 is
dependant on?
Status: RESOLVED → VERIFIED
(Reporter)

Comment 4

16 years ago
Good point as far as reopening to make bug 38966 depend on this one.

On another note, I'm not sure if I used the right terminology in the summary.  I
used "functions" to mean things like onmouseover/oncontextmenu/onclick, but
would "events" be a more accurate phrase (my terms knowledge here is fuzzy)? 
The config security policies already deals with javascript functions such as
window.open, document.write, etc. and this bug was opened to allow a user to
modify behavior with regards to onmouseover/oncontextmenu/etc as well.  Please
feel free to modify the summary if you feel the description could be more
accurate, especially once this gets linked to a higher profile bug (bug 38966).

Comment 5

16 years ago
Ok, reopening. The feature requested as I understand is a user friendly way to
disable javascript functions and events. Perhaps then the summary should be
"Need a user friendly way to disable javascript functions and events"?
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---

Comment 6

16 years ago
From tryandguessit@yahoo.com's (reporter) email:

I think the scope of this bug has narrowed due to partial overlap
elsewhere since I first filed it and that might be causing the
confusion.

Originally: make a simple way for users to control what can be run or
accessed as far as javascript is concerned.  Could be gui, could be a
text file.  Back end could act similar to a user style sheet, but for
javascript.

1 1/2 months later, I found bug 38966 and the Config Security Policies
page and thought that between the two (38966 for front end, Config
Security Policies for back end), they overlapped with most (my comment
#2) of what this RFE was meant to address.  That is why I then marked
this as a dupe of 38966.

But at this time, neither bug 38966 nor the Config Sec Policies cover
events like onhover, onunload, oncontextmenu, etc.  Therefore, in
regard to your email, this is the 2nd case where some features are
already being taken care of, while others haven't been addressed
elsewhere; which is why I welcomed your comment to reopen and mark
38966 dependent on it.  Establishing a back end for controlling events
could then be implemented as a front end gui through bug 38966.
Blocks: 38966
Product: Browser → Seamonkey

Comment 7

13 years ago
pushing back to events.  blocking oncontextmenu already exists (and is enabled by default).
Assignee: joki → events
Status: REOPENED → NEW
Component: General → Event Handling
Product: Mozilla Application Suite → Core
QA Contact: vladimire → ian

Updated

10 years ago
Blocks: 86194
Assignee: events → nobody
QA Contact: ian → events

Comment 8

7 hours ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 16 years ago7 hours ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.