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)
Firefox
Settings UI
Tracking
()
VERIFIED
FIXED
Firefox1.5
People
(Reporter: vlad, Assigned: mconnor)
References
Details
Attachments
(1 file)
22.35 KB,
patch
|
vlad
:
review+
asa
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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?
Comment 1•19 years ago
|
||
*** Bug 298973 has been marked as a duplicate of this bug. ***
Comment 2•19 years ago
|
||
*** This bug has been marked as a duplicate of 283716 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Comment 3•19 years ago
|
||
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 → ---
Comment 4•19 years ago
|
||
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).
Assignee | ||
Comment 5•19 years ago
|
||
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
Updated•19 years ago
|
Blocks: branching1.8
Comment 7•19 years ago
|
||
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.
Comment 8•19 years ago
|
||
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.
Updated•19 years ago
|
Whiteboard: [minor l10n impact] → [minor l10n impact] [needs more research/input]
Comment 9•19 years ago
|
||
*** Bug 302400 has been marked as a duplicate of this bug. ***
Comment 10•19 years ago
|
||
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.
Comment 11•19 years ago
|
||
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?
Comment 12•19 years ago
|
||
(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.
Comment 13•19 years ago
|
||
(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.
Comment 14•19 years ago
|
||
(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.
Comment 15•19 years ago
|
||
(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.
Comment 16•19 years ago
|
||
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.
Comment 17•19 years ago
|
||
> 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.
Comment 18•19 years ago
|
||
Wouldn't that make #104532 [Core]-Status bar ticker fails to update when tabs switched. [All] (-) a security issue?
Comment 19•19 years ago
|
||
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.
Comment 20•19 years ago
|
||
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...
Comment 21•19 years ago
|
||
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
Assignee | ||
Comment 22•19 years ago
|
||
as discussed, see beltzner's comment for details
Attachment #192060 -
Flags: review?(vladimir)
Assignee | ||
Updated•19 years ago
|
Whiteboard: [minor l10n impact] [needs more research/input] → [has patch][needs review vlad]
Comment 23•19 years ago
|
||
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.
Reporter | ||
Updated•19 years ago
|
Attachment #192060 -
Flags: review?(vladimir) → review+
Comment 24•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
Attachment #192060 -
Flags: approval1.8b4?
Updated•19 years ago
|
Attachment #192060 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Updated•19 years ago
|
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Comment 25•19 years ago
|
||
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:"> ----------------------^
Comment 26•19 years ago
|
||
(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
Comment 27•19 years ago
|
||
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+
Comment 28•19 years ago
|
||
Forget my last comment. I got my builds and times zone confused. Build 2005081002 works fine.
Comment 29•19 years ago
|
||
(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
Comment 30•19 years ago
|
||
> 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).
Comment 31•19 years ago
|
||
(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
Updated•19 years ago
|
Comment 32•19 years ago
|
||
For the record, this fix caused focus problems on gmail. See bug 305084 for details.
Comment 33•19 years ago
|
||
Also see bug 300453 and bug 304746
Comment 34•19 years ago
|
||
Could this checkin have caused a 10% Tp regression in beast? See bug 306107 for details.
Updated•19 years ago
|
Summary: "disable common annoyances" pref UI is too vague → "disable common annoyances" pref UI is too vague (advanced javascript options were removed)
Comment 35•16 years ago
|
||
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?
You need to log in
before you can comment on or make changes to this bug.
Description
•