Closed Bug 115353 Opened 23 years ago Closed 22 years ago

Clean up UI and Wording for Scripts and Windows Pref

Categories

(SeaMonkey :: Preferences, defect)

defect
Not set
minor

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: rebron, Assigned: doronr)

References

Details

Need to clean up the UI as far as wording and what preferences were surfacing to the user. Currently as implemented: Scripts and Windows x Enable Javascript x Open Windows by themselves x Move or resize existing windows x Make windows flip over or under other windows x Change status bar text x Change Images x Create or change cookies x Read cookies
ccing UI design owner
-> UI Design
Component: Preferences → User Interface Design
Really sending over to UI design.
Assignee: sgehani → mpt
QA Contact: sairuh → zach
From bug 75371 [Which is what this bug branched off of]: Personally, I feel that we should add the UI for every javascript annoyance that we block as a pref and list them in order of what we think is most important. The white box in the screenshot [on bug 75371] can be made to scroll.
I have to agree that having more items listed here is better, up to a point. There are some things it would be silly to prevent JS from doing, like making drop-down boxes in forms work intelligently (i.e., the choices in one change when another is frobbed by the user), because that's just a matter of functionality, not of user preference. But anything that changes the user's operating environment (taking away toolbars and menus from certain windows, for example) ought to be able to be easily shut off by the user, if desired. ISTR some hugely nasty JS behaviors from earlier browsers, like changing the user's start page setting (www.cartoonnetwork.com does this, or used to). _If_ these are implemented at all (which would be of dubious merit, and having not seen them in a while I do not know that they are implemented) they sure ought to be on this list. (I don't mean that they should be implemented just to be put on this list, only that if they are already implemented then they should go on the list.) Pop-up windows should stay at the top of the list, and other extremely annoying things (e.g., changing the status bar text) should be near the top of the list too. Although I don't want to get into a protracted argument about the exact order. (If it were me, I'd stick the cookies stuff way down the list because they don't have any directly visible impact on the user's experience, but I can just hear the privacy nuts going into heated tirades, and I don't want to have that argument.) Regarding wording: I am least satisfied with "Make windows flip over or under other windows"; that wording just... rambles too much, IMO. Notice how much longer it is than all the others. If "Raise and Lower windows" is too technical, "Push windows over or under other windows" is at least a marginal improvement.
From bug 75371 , with wording corrections from Ben Guthrie, Jason Bassford, Alex Bishop: +--- Scripts and Windows ------------------------------------------+ | | | [*] Enable JavaScript | | | | Some web pages use JavaScript to manipulate browser behavior. | | You can decide which behavior you want to allow: | | | | Allow web pages to: | | [ ] Pop-up unrequested windows | | [ ] Move or resize windows | | [ ] Change window focus | | [ ] Change status bar text | | [ ] Show mouseovers | | | | [ OK ] [ Cancel ] [ Help ] | +------------------------------------------------------------------+ On window focus: Common term. Microsoft uses it in TweakUI and IE prefs. Opera uses it in their documentation. If someone isn't sure what it means, they look in the dictionary or press Help. Rafael Ebron on cookies: "Let's not try and control whether cookies are dropped and read from this preference (that's what the Cookie preferences under Privacy are for)."
On the window focus issue: It currently reads: Make windows flip over or under other windows This is obviously awful wording. "RC" suggests "Change window focus", but this is quite a differant thing. If all it really is doing is setting focus, fine, but I believe the javascript commands at issue here raise and lower windows. Allow scripts to: "Raise and lower windows" sounds good to me.
> that's what the Cookie preferences under Privacy are for I don't believe those preferences apply to cookies set via script. People are welcome to test this, of course. :) Scripts are already rather limited in what sort of cookies they can set. In particular, they cannot set domain cookies. The thing that makes scripts so very dangerous regarding cookies is that the script can set cookies based on so many factors to which servers that set cookies do not have access. For example, a script can set a cookie based on which links you click on a page, the order you clicked them in, and how long you took between clicks (even if these are links to other sites; all it needs to do is detect the onclick event). Thus there are privacy issues associated with script access to cookies which are simply not there when server cookies are the only thing being considered.
Each pref should use terms that are consistent to related prefs. If we use "move" then the other prefs should be "create" and "raise/lower". Thus the consistent prefs should be called: +-----------------------------------------------------------------------------+ [ ] Create unrequested windows (Pop-ups) <-- consistent terminology [ ] Resize or move windows <-- resize first, because more common [ ] Raise or lower windows <-- "focus" is for cameras and glasses [ ] Change status bar text [ ] Show mouseovers <-- unclear. What is this anyhow? +-----------------------------------------------------------------------------+
I found this comment by The Pim on slashdot in response to mpt's post about the wording of the pref and I am pasting it here since it is rather insightful. So why not "Open windows automatically" or "Open windows without user input"? Here it goes: Can't resist adding my 2c. All of the entries after the first (I'm going by what the poster wrote; I haven't run 0.9.7 myself) can be read as if prefixed with "Scripts are allowed to ...". So make that the heading! "Scripts and Windows" makes little sense, since most of the entries are unrelated to windows. This change would require that "Enable Javascript" be moved to its own section, which seems appropriate anyway. (I guess someone wanted "windows" in the heading so that people looking to disable ad windows would see it; but this is "advanced" configuration, and I think anyone going here would know that it's really a script preference.) On to the original matter: "Open windows by themselves" is gratuitously ambiguous. "by themselves" seems to go with "windows", which could either mean that windows open in a separate part of the screen ("by" as in location"); or that windows spontaneously open without external cause ("by" as in agent). Neither one is really right. If you change the heading as I suggest, it reads, "Scripts are allowed to open windows by themselves". This is an improvement, because "by" as in agent clearly refers to "scripts". But the "by" as in location interpretation is still possible, so it remains confusing. "Scripts are allowed to open windows automatically" reads with no ambiguity to me, and seems no worse in any way. So I would suggest "Open windows automatically" as the text for the checkbox. "Open windows without user input" isn't bad if you want to be more explicit.
I'm glad to see the UI for script-handling preferences, but IMHO it should be finer grained, to distinguish between what a script does automatically and what it does via interacting with the user. Before, I could disable popups that are triggered by the onLoad parameter in the BODY tag by adding a line to prefs.js; now with the UI I can *only* disable popups *completely*. There are times when I want a script to be able to open a new window when I click something, so in this instance the UI took away a small bit of functionality that was there before.
> now with the UI I can *only* disable popups *completely* What gave you that idea? The UI will only prevent popups inside onload and onunload as well as in top-level scripts. This is exactly what you could do before. This is why "by themselves" is in the description of that checkbox. Are you suggesting a better wording?
If current heading "Allow scripts to do the following:" is kept, please drop "do the following" since its extra verbage and implied by the ":". But, I like the wording in comment 6 better yet.
Based on comment #12, I gather that the pref "Open Windows by themselves" map to the pref.js dom.disable_open_during_load? If so, it's a bit confusing that it doesn't mention anything about loading and unloading the page. It makes it sound like it applies to any windows being opened. Perhaps "Open unrequested windows when loading or exiting a page"? I generally find MPT's original design to be clear and accurate. I'd point out that the text needs to stay "Move or resize existing windows", since the pref only applies to resizing or moving your current windows. Windows that the page opens, either automatically or in response to the user, can be resized or moved by the opener page. How about this: +--- Scripts and Windows ------------------------------------------+ | | | [*] Enable JavaScript | | | | Some web pages use JavaScript to manipulate browser behavior. | | You can decide which behavior you want to allow: | | | | Allow web pages to: | | [ ] Open unrequested windows when loading or exiting | | [ ] Move or resize existing windows | | [ ] Flip windows over or under other windows | | [ ] Change status bar text | | [ ] Change images | | [ ] Create or change cookies | | [ ] Read cookies | | | | [ OK ] [ Cancel ] [ Help ] | +------------------------------------------------------------------+
> Perhaps "Open unrequested windows when loading or exiting a page"? That would be factually incorrect. The pref also disables windows being opened from functions that were run using SetTimeout... Also, consider the following situation. I have a document I am creating using document.write(). Up until I call document.close() it's not done loading (so the throbber runs). But the user may well perceive it as being loaded (no changes in 30 minutes). The user clicks on a button, in response to this I document.write() a <script> element which calls window.open(). This call will be blocked by the pref in question, since it is a top-level invocation before the document load has completed... though to the user this is more like a DOM modification than a document load.... Maybe just "Open unrequested windows"?
> This call will be blocked by the pref in question, since it is a top-level invocation before the document load has completed... I'd suggest that what you describe is more a side effect than desired behavior. The vast majority of the time the window open occurs immediately after loading or unloading the page. Even when it is time delayed, it is still caused by load or unload. I don't like "Open unrequested windows" because that implies that window.open is blocked entirely. In other words, new windows will not be caused by clicking a link like javascript:window.open. This is not what the pref does. See confusion in comment #11.
As a user, I would tend to assume that unchecking "open unrequested windows" would block *any* opening of windows other than the various menu options that specifically mention new windows.
Ok. For now, the changes shall be: 1. Allow scripts to do the following: --> Allow scripts to: 2. Open new windows by themselves --> Open unrequested windows 3. Make windows flip over or under other windows --> Raise or lower windows 4. Change images (image rollovers) --> Change images The (4) change is because it's not just on rollovers. The other changes are for clarity. Reassigning to Doron and marking dependent on bug 117517, since this bug will be fixed in the patch for that one.
Assignee: mpt → doronr
Severity: normal → minor
Component: User Interface Design → Preferences
Depends on: 117517
OS: Windows 2000 → All
Hardware: PC → All
QA Contact: zach → sairuh
[ ] Mail & Newsgroups Enable JavaScript for: [ ] Navigator is completely incomprehensible
Blocks: 127339
wfm
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
ditto, v w4m.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.