*** Bug 298973 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 283716 ***
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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
13 years ago
Whiteboard: [minor l10n impact] → [minor l10n impact] [needs more research/input]
13 years ago
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 #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.
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
Created attachment 192060 [details] [diff] [review] restore 1.0 behaviour, tweak prefs 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.
13 years ago
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? → approval1.8b4+
Status: NEW → RESOLVED
Last Resolved: 13 years ago → 13 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
For the record, this fix caused focus problems on gmail. See bug 305084 for details.
13 years ago
Depends on: 305084
Could this checkin have caused a 10% Tp regression in beast? See bug 306107 for details.
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.