If a user unchecks this box, they'll effectively render the browser unusable on a large number of sites. We should not ship this option to hundreds of millions of users.
Individuals that need this functionality should use about:config, NoScript, web developer tools, or similar.
(In reply to Jesse Ruderman from comment #1)
I don't think that's directly relevant to this bug, but presumably we would either (A) minimally rename it or (B) remove it entirely. I will let you guess which option Limi will likely prefer. :)
This checkbox is pretty useful to me as both a Gecko developer and website developer.
Would it make sense to move it into developer tools or something along those lines?
It'll still be available in about:config, and it wouldn't be hard to write an add-on to re-add the checkbox to prefs (or elsewhere). I saw another comment elsewhere about someone using this for testing websites, so it might be fodder to expose in dev-tools. New bug for that, please. :)
Limi is right. Kill this UI. (And add to web dev tools.) As for the other advanced prefs, we should assess whether our defaults should just be "what Firefox does" or whether there's still a case for allowing changes. Irritating disablement (as opposed to useful disablement) of the context menu seems, at least to me, to be rare these days. People have given up on the idea that you can stop people copying and pasting web page content.
Created attachment 733785 [details] [diff] [review]
Remove all JS-related preference UI
This removes the checkbox as well as the advanced button, and gets rid of the dialog XUL and DTD. Funnily enough, the dialog has included a script file since its inception in 2005 - except the script file was never necessary and indeed never seems to have existed except for a brief stint in 2008 (bug 412862). The "Enable Java" strings are dead as well, as the preferences were all removed in bug 506985.
Created attachment 733798 [details]
Screenshot of preference window's Content tab without images or JS
Is there a bug on file for adding UI for this to devtools?
(In reply to :Gavin Sharp (use email@example.com for email) from comment #9)
> Is there a bug on file for adding UI for this to devtools?
Yes, sorry, meant to link that: bug 852490.
*** Bug 537482 has been marked as a duplicate of this bug. ***
What about the legacy prefs? AFAICS, the option to en/disable JS is moved to dev tools. However the advanced options are no longer accessible for the average Joe. I suggest resetting them to a sensible default. There are 3 options (roughly translated):
1. Move and resize JS Popups
2. Put windows in front of or behind other windows
3. Deactivate context menu
I guess (1) can be used in sensible contexts (and I don't know what gets disabled actually) and therefore could be reset to TRUE. But FALSE wouldn't break legitimate sites, IMO, so this value is also acceptable.
(2) is disabled on my machine and I don't see a compelling reason to allow this (reset to FALSE?).
(3) is probably about showing the context menu when rightClickEvent.preventDefault() was called – there are legitimate use cases for that (that should be solved in a different way), and restricting access to media on a page is no longer en vogue (thankfully – reset to TRUE).
That said, those options don't seem to me like having a high impact, thus it may be ok to just leave them however they were set …
(In reply to Florian Bender from comment #12)
> (3) is probably about showing the context menu when
> rightClickEvent.preventDefault() was called – there are legitimate use cases
> for that (that should be solved in a different way), and restricting access
> to media on a page is no longer en vogue
YouTube does it. It replaces the context menu with a custom one that doesn't provide the features I'm usually interested in. I deliberately prevented YouTube from doing this and certainly don't expect that preference to be reset.
Changing our defaults for the prefs whose UI is being removed here is outside the scope of this bug.
Created attachment 734700 [details] [diff] [review]
Reset image+js-loading prefs
This resets the image and JS blocking preferences, as well as the 3 "advanced" JS preferences, for which UI is removed.
Comment on attachment 734700 [details] [diff] [review]
Reset image+js-loading prefs
What's the rationale for doing this? See comment 13.
(In reply to Dão Gottwald [:dao] from comment #16)
> Comment on attachment 734700 [details] [diff] [review]
> Reset image+js-loading prefs
> >+ Services.prefs.clearUserPref("dom.disable_window_move_resize");
> >+ Services.prefs.clearUserPref("dom.disable_window_flip");
> >+ Services.prefs.clearUserPref("dom.event.contextmenu.enabled");
> What's the rationale for doing this? See comment 13.
Comment 14? Essentially, I was under the impression we would reset all preferences for which there was no more UI.
> >+ Services.prefs.clearUserPref("permissions.default.image");
> Wrong bug?
I'd rather increment the UIversion just once and land the migration in one go. Because the actual removal patch on this bug would conflict with the one for bug 851701, I've done this one on top of the one from bug 851701. I'll land that as soon as I have review, and then land this one.
(In reply to :Gijs Kruitbosch from comment #17)
> > >+ Services.prefs.clearUserPref("dom.disable_window_move_resize");
> > >+ Services.prefs.clearUserPref("dom.disable_window_flip");
> > >+ Services.prefs.clearUserPref("dom.event.contextmenu.enabled");
> > What's the rationale for doing this? See comment 13.
> Comment 14?
> Essentially, I was under the impression we would reset all
> preferences for which there was no more UI.
As a user who deliberately prevented sites from disabling native context menus, resetting that now would require me find out about the hidden pref, whereas keeping the custom value requires me to do that only if I change my mind about context menus (which I probably won't).
Also, I'd hope that the devtools UI picks up that option as well.
(In reply to Dão Gottwald [:dao] from comment #18)
> (In reply to :Gijs Kruitbosch from comment #17)
> > > >+ Services.prefs.clearUserPref("dom.disable_window_move_resize");
> > > >+ Services.prefs.clearUserPref("dom.disable_window_flip");
> > > >+ Services.prefs.clearUserPref("dom.event.contextmenu.enabled");
> > >
> > > What's the rationale for doing this? See comment 13.
> > Comment 14?
> Seems unrelated.
My point was, I was not going to change it to something else than the default. The reason to change it at all was...
> > Essentially, I was under the impression we would reset all
> > preferences for which there was no more UI.
> As a user who deliberately ...
... that not everyone changes these deliberately, as pointed out in Limi's blogpost. Generally, for image/JS loading, I guess it's very plausible that the number of users who disable it without either full intent or full knowledge of what they're doing are in the majority. How that ratio works for the advanced JS prefs, I'm less sure, but I suspect the "I did this a long time ago and don't remember and/or what do you mean I changed this checkbox?" group is still bigger than the conscious users of these prefs. In any case, I'm happy to leave the final decision with people smarter than me; I simply went with the simplest thing I thought could work.
That we're now removing the ability to toggle the pref through UI means that we should restore the default behavior, lest users get "stuck" with non-default behavior without a way to restore it. Users who want (and have set) non-default behavior intentionally will need to use about:config to restore that non-default behavior. I don't think we need address that use case.
(In reply to :Gijs Kruitbosch from comment #19)
> > > Essentially, I was under the impression we would reset all
> > > preferences for which there was no more UI.
> > As a user who deliberately ...
> ... that not everyone changes these deliberately, as pointed out in Limi's
> blogpost. Generally, for image/JS loading, I guess it's very plausible that
> the number of users who disable it without either full intent or full
> knowledge of what they're doing are in the majority.
It's unclear to me why anyone would disable images other than for saving bandwidth, so I don't think your assumption holds in this case, which is however off-topic for this bug.
> How that ratio works
> for the advanced JS prefs, I'm less sure, but I suspect the "I did this a
> long time ago and don't remember and/or what do you mean I changed this
> checkbox?" group is still bigger than the conscious users of these prefs.
I may not remember that I touched the context menu checkbox, but that doesn't mean I'm no longer happy with that choice. Why would I? I don't think there's one true answer for all these prefs and I have no clear opinion on the other two right now. If it's obvious that people modified them because they misunderstood them, because they didn't see their full impact or for reasons that don't matter any longer, then resetting them may make sense.
(In reply to :Gavin Sharp (use firstname.lastname@example.org for email) from comment #20)
> That we're now removing the ability to toggle the pref through UI means that
> we should restore the default behavior, lest users get "stuck" with
> non-default behavior without a way to restore it. Users who want (and have
> set) non-default behavior intentionally will need to use about:config to
> restore that non-default behavior. I don't think we need address that use
Whether being stuck with that non-default behavior is a bad thing depends on the nature of the given pref. Again, I think this needs to be answered on a case-by-case basis. Bulk-resetting all those prefs will just unnecessarily upset users.
(In reply to Dão Gottwald [:dao] from comment #21)
> Bulk-resetting all those prefs will just unnecessarily
> upset users.
A very small amount of users, who have a relatively simple recourse. The alternative you seem to be suggesting (leave the pref as-is, with no visible way to revert it) seems strictly worse, because it will frustrate users who want the default behavior but don't know how to get it, rather than frustrating users who want the non-default behavior and have customized it intentionally in the past.
Yeah, this WFM. We shouldn't reset prefs flippantly, but in cases like this I think it's reasonable and acceptable to presume that users who intentionally wanted the non-default behavior will be able to seek out ways to retain/replicate their previous experience (if they really want to).
Side note: ideally the "advanced JS" pref for controlling window move/resize and raise/lower would be smarter by default. Bug 454779 is a good starting point for the history of the move/resize issues. Maybe we should pick that up again (but shouldn't block progress of this bug).
Pushed both patches to inbound:
imo, this has nothing to do more with developers than as a regular user. it's a totally average-joe setting, useful for having in plain sight in the menu. a:c is a hassle, devtools r slowish fancylookers. every few weeks i guess one toggles it for a site then does back right when he is done. i've never tried the menu button to the right but now that i read its nice too.
its a totally self-obvious thing to undo if anything (with the millions of sites which r broken wo it) goes unusual im sure the user 'd just know its because he needs to do it back, i see nothing of that worry raised that its confusing or dangerous.
same for the to-me bogus-seeming thing that the vast majority of the users dont know sh about it when toggling it. thats nonsense! how could one imagine it as this?
Removal and(!) reset of flags should be noted in the release notes.
Additionally, it would be helpful to provide an addon alongside the UI removal that re-introduces the UI (or implements a new UI) to set those prefs. This could be a Fx-power-user addon that includes several of those UI removals in one addon (yes, there are power-users who don't want to fiddle with or even don't know about:config!). Introducing an addon that provides some of the advanced (removed) UI may help alleviating protests by upset users.
I think when some settings like these are changed and user had NON-DEFAULT setting for each of them [one or more], We should inform him with some message box or other way that there were such changed performed. This would inform only users that changed these values - so it will not appear for, as mentioned earlier, majority of users - You could actually collect data on how many of users had it not default if the user opted-in to inform mozilla of performance and such (if it's not against privacy etc). It could look like this:
"settings: xxx yy were changed to default values due to something. If you are not familiar with them You can just ignore this message." or something similar. We can also include information that they were moved to advanced user options [about:config] and point to some URL explaining how to turn them back on.
This would prevent unecessary "WHAT IS THIS?!" from members having such UNEXPECTED BEHAVIOUR happen (well, if someone had it - window resizing by scripts - disabled and didn't see some window size SELF-RESIZE for a long time then that may be UNEXPECTED for him/her).
A notification for the users that set this setting differently than the Fx default would certainly help against Angry Users(TM). This notification can then link to a SUMO article explaining the change (and maybe provide instructions for power users).
This change has made using Firefox effectively less convenient.
But as I'm saying this change makes more chaos than leaving it on and just enchanting them with some kind of notifications. I personally don't like things that lack customizations (points at Firefox for android - good there is still about:config there!).
Still this is kind of weird. More and more people can do much more than just browse websites, they can create them and yet we take such options away? Look at it from this perspective. If IT is almost everywhere now, children are taught to do much more than just browse the internet, like creating small applications, older people are using the internet and can easly create blogs etc., we take such options because...? Do We really consider they may not know what they mean? I think the idea of taking away more and more options may not be good, especially for browser that was(is?) on the top if it comes to being easly customizable. Instead there should be more information provided as to what disabling them can result (like some window when unchecking, telling user what the results may be and for example ask him/her to show him/her the movie of how the webpages may look like after disabling it), and/or mentioned previously notifications (like the notificication about the site wanting to install add-on).
There are addons that are way better at handling JS on/off (e. g. for individual sites or domains or resources) than one global setting could do. Please use those.
And there's still an about:config setting.
Steps to reproduce:
The following is not an acceptable work around:
In the preferences applet, it's about 5 clicks deep.
In the "about:config" registry, I must first KNOW that the registry exists, and know what to type to find it. I must bypass a warning, assuring that I understand the nature of the settings I will be "tampering" with. I must know to search for the registry key. I must figure out what registry key to search for. I must type in the search string correctly and locate the proper setting, and I must change the setting properly.
I've suspected for some time, and am becoming more certain, that Firefox, as other browsers, has been developed sufficiently — to a point at which there is not much that is left to do for many developers, particularly those in the UI team. But because they like the feeling of having power and control, they come up with ideas and shove them into people's throats, no matter how bad the ideas are.
I think the only devs that should continue working on Firefox are those who work on performance and security. The rest should find other things to do. Otherwise, they just keep ruining what used to be a good browser.
Flames are also inappropriate for Bugzilla, and repeat offenders will be disabled. See https://bugzilla.mozilla.org/page.cgi?id=etiquette.html.
[Comments are now restricted to users with the editbugs privilege -- with privilege comes responsibility, so please consider carefully before commenting if you are able.]
This has been noted in the Aurora 23 release notes:
If you would like to make any changes or have questions/concerns please contact me directly.
Adding this to the sign-off criteria for Firefox 23.0b1.
Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20130618 Firefox/23.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130618 Firefox/23.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130618 Firefox/23.0
Build ID: 20130618004018
>This has been noted in the Aurora 23 release notes:
I'd like to echo the sentiment of comment 29 that the reset by us of an intentionally user-set flag also warrants a release note.
(In reply to :Gavin Sharp (use email@example.com for email) from comment #8)
> pages will need an update to reflect the removal of these options.
This was completed on Jul 11, 2013.