Closed Bug 299424 Opened 19 years ago Closed 19 years ago

"disable common annoyances" pref UI is too vague (advanced javascript options were removed)

Categories

(Firefox :: Settings UI, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox1.5

People

(Reporter: vlad, Assigned: mconnor)

References

Details

Attachments

(1 file)

In the old pref dialog, we had under Enable Javascript the option to disable
allowing content to open a new page, resize windows, etc.  In the new pref
dialog, some of these seem to have been coalesced into a "but disable common
annoyances" checkbox.  That's pretty vague -- I have no idea what "common
annoyances" are, or whether I want to disable them or not.  There's no tooltip
or help to let me know, either.  Can we either bring back the old list, or at
least specify what this is supposed to do better?
*** Bug 298973 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 283716 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Not a dupe. Bug 283716 is about bringing back the advanced javascript options;
this bug is about correcting unclear wording in the new pref dialog (which can
be corrected with or without fixing bug 283716).

Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Flags: blocking-aviary1.1?
Not sure if this is going to block since the Help dialog has the definition of
this (although it is very dumb, because what some people think is annoying,
others don't, which brings us back to the advanced js options menu, which I'm
all for, but that's a different issue).
Jesse, a while back I saw a suggestion on which prefs we should just default and
hide in relation to this bug, can you repost here?
Assignee: nobody → mconnor
Status: REOPENED → NEW
Flags: blocking-aviary1.1? → blocking1.8b4+
Whiteboard: [minor l10n impact]
Mossop has a nice extension that adds this functionality:
http://www.blueprintit.co.uk/~dave/web/firefox/jsoptions/index.html

But I don't think we'll be seeing this in v1.1, although would be nice :P
I think I've only voiced my opinion about this on IRC and scattered throughout
Bugzilla, so I wrote this to post on this bug.

(1) Move or resize existing windows

Should be disallowed by default, except in windows opened by JavaScript with
only one tab.  It is frequently used to annoy visitors, and I don't think many
web applications need it.  (Bug 144069, bug 186708, bug 60323, bug 262660.)

(2) Raise or lower windows

Should be disallowed by default.  It is typically used for pop-unders (which are
still possible as on-click pop-unders) or accidentally (e.g. Gmail every time
you load a message).  I don't think many web applications need it, and those
that use it shouldn't be horribly broken if they can't control window focus.

(3) Hide the status bar

Should be disallowed by default, because keeping the status bar visible is a
security feature (see bug 252811).  Web applications have to deal with this in
Internet Explorer anyway.

(4) Change status bar text

Should be a pref, allowed by default for now.  Some sites use it to make link
information more readable or to show status information; other sites use it to
obscure link information or to distract users with a welcome-message ticker. 
Contrary to popular belief, disallowing web sites from changing status bar text
does not improve security: the URL displayed in the status bar is unreliable
because it is unescaped differently and because the web page could change the
link just as you click on it.

(5) Disable or replace context menus

Should be a pref, allowed by default for now.  Some sites have legitimate uses
for right-clicking, such as marking a mine in Minesweeper or showing a context
menu for a spreadsheet.  On the other hand, many sites disable the context menu
just to prevent people from "stealing images", not realizing their visitors have
other uses for context menus and other ways to save images.
Where can we discuss the issues involved in this bug and in bug 177838, bug
179692, bug 101509, bug 176304? As it stands now, more and more bugs are filed,
more discussions are scattered, there does not seem any coherent, structured
discussion on all these issues.

What's the relationship of this bug with bug 176304? Is there one?
Is there a relationship between this bug and bug 177838? Personally I would
consider a script that is removing toolbars and removing window resizability to
be annoying, reducing my usability, accessibility of my browser window.

You say Raise or lower windows should be disallowed by default. I disagree.
Opera 7+ makes Raising and lowering 2 distinct user prefs. I will accept
whatever Mozilla authorities decides on that "Raise or lower windows" issue: I
will not lose sleep on this if it is disallowed by default. OTOH, I want to
point out that all my writings

- http://developer-test.mozilla.org/en/docs/window.open#Best_practices
- How can I bring back the window if it is minimized or behind another window?
http://developer-test.mozilla.org/en/docs/window.open#FAQ
- http://www.mozilla.org/docs/dom/domref/dom_window_ref76.html#FAQ
- What does the "Raise or lower windows" setting do exactly?
http://www.gtalbot.org/Netscape7/Popup/PopupAndNetscape7.html#RaiseLowerSetting
Also "The biggest fault with pop-ups is that it takes the focus away from the
main browser window, and this can be disconcerting. (...) To address the issue
of a window losing focus, you can use JavaScript to re-set the focus."
Ian Lloyd, "The Perfect Pop-up" tutorial
http://www.accessify.com/tutorials/the-perfect-pop-up.asp
explain the proper, correct usage of focus() in the context of multiple windows.
This question (how to raise, bring back on top a secondary window) is very
frequent in web programming newsgroups.
Whiteboard: [minor l10n impact] → [minor l10n impact] [needs more research/input]
No longer depends on: 302400
*** Bug 302400 has been marked as a duplicate of this bug. ***
People don't need piecemeal control over this - if they do, fine, use about:config

We can enhance the documentation in the UI under this preference along the lines
of say:

[x] but disable common annoyances
    (like changing, moving or resizing windows, scrolling text in the 
     status bar, or blocking right click menus)

(better wording left for someone who is more of a UI wordsmith)

Or, something more like what Camino has:

[x] prevent sites from changing, moving or resizing windows, scrolling 
    text in the status bar or blocking right click menus.
If this pref defaults to being on (or whatever state the prefs are when the
button is checked), wouldn't it be better to just remove it altogether?

The way I see it, there are two types of user who'll care about this sort of thing:

1) Power users - this is useless to them, since they'll want to tweak the
specifics. They should use about:config.

2) Normal people - they probably don't want any of those things to happen, and
if the box is checked by default, I can't see much of a case for them unchecking
it - who wants extra annoyances?
(In reply to comment #11)
> If this pref defaults to being on (or whatever state the prefs are when the
> button is checked), wouldn't it be better to just remove it altogether?
> 
> The way I see it, there are two types of user who'll care about this sort of
thing:
> 
> 1) Power users - this is useless to them, since they'll want to tweak the
> specifics. They should use about:config.
> 
> 2) Normal people - they probably don't want any of those things to happen, and
> if the box is checked by default, I can't see much of a case for them unchecking
> it - who wants extra annoyances?

For part 2, the keyword is "probably." Everyone has different tastes, so we
can't just assume that every normal user will want to have these js effects
prevented With that said, ditching the UI altogether would be a bad idea: how
would that look to joe average if there's a js UI in 1.0, but none in 1.5 or
later? That can easily lead someone to believe that they no longer have control
over what javascript can do, that mozilla is now dictating exactly what js
effects the user can and cannot see, and I doubt we want to do that.

My solution to this: put a tooltip with the description of what will be
disabled. Since it's clear that the advanced options will never come back
(except for an extension), I say just stick with what's there right now and
shove a tooltip in there. If someone doesn't find a js effect as being annoying,
about:config and the JS Options extension are the fail-safes for this.
(In reply to comment #12)
> For part 2, the keyword is "probably." Everyone has different tastes, so we
> can't just assume that every normal user will want to have these js effects
> prevented 

Why not? The default choice has been made for the other dozen or so dom.disable
preferences and some of those are just as valid as "common annoyances".

> With that said, ditching the UI altogether would be a bad idea: how
> would that look to joe average if there's a js UI in 1.0, but none in 1.5 or
> later? 

Considering that the previous options were hidden behind an advanced button and
were, as Ben said, piecemeal, these people can use about:config if they really
want to change the defaults. I don't understand how an all-or-nothing approach
to a few preference is any better than this.
(In reply to comment #13)
> Why not? The default choice has been made for the other dozen or so dom.disable
> preferences and some of those are just as valid as "common annoyances".

Assuming this AND removing a UI present in the previous official release is
something that worries me.

> 
> Considering that the previous options were hidden behind an advanced button and
> were, as Ben said, piecemeal, these people can use about:config if they really
> want to change the defaults. I don't understand how an all-or-nothing approach
> to a few preference is any better than this.

Do we really want "omg this window resizes in IE but doesn't in firefox WTF THIS
SUCKS" problems and then tell someone to go into about:config or use JS Options
to turn off the disabling feature, when this quite possibly can happen to a LOT
of people? Do we even know if joe average is using the ui that's in 1.0.x?

I think before anything else is done, we need to poll everyday, normal users and
ask if they use the js UI in their 1.0.x version, before thinking about ditching
the UI altogether. Maybe stick the tooltip in for 1.5 and research this more for
2.0, but I honestly don't see the need to remove this from the ui.

(In reply to comment #14)
> Assuming this AND removing a UI present in the previous official release is
> something that worries me.

The UI from the previous release is already fundamentally gone. Arguing that
because something is there now it should never be removed is the same argument
that failed when the original six checkboxes were replaced with one.

It's infinitely better to make educated assumptions for normal people than to
give them options they don't need. This is, I believe, a core principle of Firefox.

> Do we really want "omg this window resizes in IE but doesn't in firefox WTF THIS
> SUCKS" problems and then tell someone to go into about:config or use JS Options
> to turn off the disabling feature, when this quite possibly can happen to a LOT
> of people? 

Why not? The same people will complain when they can only enable resizing by
also allowing pages to hijack their context menu at the same time.

> Do we even know if joe average is using the ui that's in 1.0.x?

Considering that it's behind an Advanced button as a subset of "Enable
JavaScript", I severely doubt anyone we can class as an average joe is using
these settings.
I believe that hiding the status bar should be disallowed in every situation. It shouldn't be affected by 
"disable common annoyances".

Because "disabling common annoyances" covers a too wide range of settings, many users may need to re-
enable these annoyances to use some tools such as "rich textboxes" (textboxes with bold, italics...). 
However, actually, if they re-enable the annoyances, they also allow websites to hide the status bar which 
is a bad thing as it slightly reduces the security of these users.
> I believe that hiding the status bar should be disallowed in every situation.
It shouldn't be affected by 
> "disable common annoyances".
> 

I agree with you and Microsoft itself agrees with you.
"Expect the status bar to be present, and code for it. The status bar will be on
by default and is 20-25 pixels in height."
quote from "Fine-Tune Your Web Site for Windows XP Service Pack 2, Browser
Window Restrictions in XP SP2"
"Script-initiated windows will be displayed fully, with the Internet Explorer
title bar and status bar. (...)"
Script management of Internet Explorer status bar
"Internet Explorer has been modified to not turn off the status bar for any
windows. The status bar is always visible for all Internet Explorer windows." 
They even explain, substantiate and justify the security reasons as well.

I quote, explain all this here:
http://developer.mozilla.org/en/docs/DOM:window.open#Note_on_status_bar
http://developer.mozilla.org/en/docs/DOM:window.open#Note_on_security_issues_of_the_status_bar_presence

Status bar should always be present to relay reliable, unaltered info and
notifications to the users.
Wouldn't that make #104532 [Core]-Status bar ticker fails to update when tabs
switched. [All] (-) a security issue?
FWIW, this was a user having a problem with this: 
http://www.livejournal.com/community/firefoxusers/127686.html

"disable common annoyances" disables scripts changing images, which breaks 
livejournal's entry page (which allows the user to choose an icon, and 
previews the chosen icon).  I also know of a couple of simple quiz sites which 
change an image in order to indicate if an answer was correct or not.

Lots of paranoid people will poke about in their options and check this box, 
and then not understand why things that didn't annoy them have stopped 
working. People either need to be able to understand what the option does, or 
they don't need to be given the option in the first place, IMHO.
hrm... all of my previous comment was based on an assumption that the new box 
matches the actions of all the 1.0.x boxes. I probably shouldn't comment based 
on rash assumptions so apologies if last comment is rubbish...
I've been lurking on CC and refraining from comment for a while now, but as we
close in on branch date I should probably express my hesitation with the entire
"disable common annoyances" thing.

I really like the spirit of the new pref, but am worried that we're acting
without a thorough understanding of:
  1) What people consider to be common annoyances
  2) What the words "common annoyances" means to the average user
  3) What websites break by us doing this

We want to get this right, and we don't want to churn users twice by doing this
for 1.5 and then changing it the next time down the line. IMO that requires a
bit more research on all three of these points. Perhaps more importantly, if we
get of the default prefs wrong, we need for there to be an easy way for users to
work around it.

I also think that average users will expect Firefox to block common annoyances
by default (it's one of our key differentiating value propositions, after all)
and won't foray into these options unless under the guideance of someone more
advanced (either in person or through some online tips & tricks guide).

As such, I think the best thing to do for 1.8b4 would be to ...
  - back out of the "disable common annoyances" checkbox
  - have the default settings be as close to the ones suggested in comment 7 as
possible
  - get better research on this for the future
  - plan to provide a better UI for this with better information
as discussed, see beltzner's comment for details
Attachment #192060 - Flags: review?(vladimir)
Whiteboard: [minor l10n impact] [needs more research/input] → [has patch][needs review vlad]
maybe u could integrate the js options extension into firefox instead of the old
advanced options. this extensions has more options than the original anyway.
Attachment #192060 - Flags: review?(vladimir) → review+
This is just a band-aid to restore 1.0.x behavior while research is done on how
to properly simplify these prefs; no need or desire to add prefs here.
Attachment #192060 - Flags: approval1.8b4?
Attachment #192060 - Flags: approval1.8b4? → approval1.8b4+
Status: NEW → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Mike, the checkin has a space in advanced-scripts.dtd in one of the entities
which breaks the dialog
+
+<!ENTITY allowScripts .label            "Allow scripts to:">
----------------------^
(In reply to comment #25)
> Mike, the checkin has a space in advanced-scripts.dtd in one of the entities
> which breaks the dialog

I've checked in a fix so that this won't be broken in the next nightlies. Thanks
Robert.
Hardware: PC → All
Whiteboard: [has patch][needs review vlad]
Target Milestone: --- → Firefox1.1
Reopen??

Another problem cropped up in 2005081000 build when selecting "Advanced":

XML Parsing Error:error in processing external entity reference
Location: chrome://browser/content/preferences/advanced-scripts.xul
Line Number 4, Column 87:

<!DOCTYPE prefwindow SYSTEM
"chrome://browser/local/preferences/advanced-scripts.dtd:>

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b4) Gecko/20050810 Firefox/1.0+
Forget my last comment.  I got my builds and times zone confused. Build
2005081002 works fine.
(In reply to comment #19)
> "disable common annoyances" disables scripts changing images, which breaks 
> livejournal's entry page (which allows the user to choose an icon, and 
> previews the chosen icon).  I also know of a couple of simple quiz sites which 
> change an image in order to indicate if an answer was correct or not.

We at Backbase (.com) have seen that problem too in our product. The HTML DOM is
built dynamically, and because of this blocking of dynamically changing images,
no images created by <img> tags were visible. The CSS images were though. I
actually do not see what value this blockade adds, because a. I do not think
there is anything wrong with dynamically changing images, and b. it can still be
done with CSS anyway, e.g. <div style="background:url(...);width:x;height:y;" />.

So, with this fix, what is the default behaviour for changing of images? I at
least do not see any UI to change it, so I assume it is always allowed unless
people manually go into about:config and change the pref for that?


~Grauw
> I do not think
> there is anything wrong with dynamically changing images, 

I agree with you and I think users overall agree that dynamically changing
images does not cause annoyance or is not inherently a problem.
The previous menu is back, this time (DP 1.0+ rv:1.8b4 build 20050810) changing
images is not there. So I'd say we all agree that changing dynamically image
source is not considered as an annoyance. 

> with this fix, what is the default behaviour for changing of images?

Default value of dom.disable_image_src_set in about:config is false. So, by
default, image src can be dynamically changed.

> so I assume it is always allowed unless
> people manually go into about:config and change the pref for that?

Yes, I'd say so and this is how it is right now (build 20050810).
(In reply to comment #29)
> [...] I at
> least do not see any UI to change it, so I assume it is always allowed unless
> people manually go into about:config and change the pref for that?

Correct. So the situation is actually better for sites like yours - in 1.0 there
was a check box in the advanced UI to disallow it. Contrary to my assertion in
comment 19, the "common annoyances" option in the alphas did not disable changes
of image, so wouldn't have been a problem in this case. Now after this fix we
are back to having a selection of checkboxes in the advanced UI, and that option
isn't there, so the user would have to edit the pref (and one would hope that
people doing that are more likely to be aware of consequences...)

This fix seems to work ok (using 2005081107 on win2k), so marking verified while
I'm here.
Status: RESOLVED → VERIFIED
Depends on: 305088
Blocks: 305088
No longer depends on: 305088
For the record, this fix caused focus problems on gmail. See bug 305084 for details.
Depends on: 305084
Also see bug 300453 and bug 304746
Depends on: 300453, 304746
Could this checkin have caused a 10% Tp regression in beast?

See bug 306107 for details.
Summary: "disable common annoyances" pref UI is too vague → "disable common annoyances" pref UI is too vague (advanced javascript options were removed)
Comment on attachment 192060 [details] [diff] [review]
restore 1.0 behaviour, tweak prefs

>Index: toolkit/locales/en-US/chrome/global/dialog.properties
>===================================================================
>RCS file: /cvsroot/mozilla/toolkit/locales/en-US/chrome/global/dialog.properties,v
>retrieving revision 1.2
>diff -u -p -8 -r1.2 dialog.properties
>--- toolkit/locales/en-US/chrome/global/dialog.properties	24 Nov 2004 15:55:23 -0000	1.2
>+++ toolkit/locales/en-US/chrome/global/dialog.properties	9 Aug 2005 06:09:20 -0000
>@@ -1,8 +1,8 @@
> button-accept=OK
> button-cancel=Cancel
> button-help=Help
> button-disclosure=More Info
> accesskey-accept=
> accesskey-cancel=
>-accesskey-help=H
>-accesskey-disclosure=I
>+accesskey-help=
>+accesskey-disclosure=
What's this change doing here and is it still possible to get this backed out?
Depends on: 426632
You need to log in before you can comment on or make changes to this bug.