Closed Bug 177827 Opened 22 years ago Closed 22 years ago

Re-add dom.allow_scripts_to_close_windows pref

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bryner, Assigned: security-bugs)

Details

Tinderbox depends on this pref for XUL window open and pageload tests.  Without
the pref working, these tests will always wait for the script to timeout and
kill the process.  This is undoubtedly increasing our tinderbox cycle times for
the machines that run tests.
The fix for bug 32571 currently causes a window.close() to silently fail. I
suggest that it is better to prompt the user and ask whether they would like to
allow the window to close. Perhaps this bug could be given a UI on that prompt.
Something like:


 -------------------------------------------
|                                           |
|  A script on this page wants to close     |
|  this browser window. Do you want to      |
|  allow this window to be closed?          |
|                                           |
|  X Don't ask me about this again          |
|                                           |
|        -----------   ------------         |
|       |    Yes    | |     No     |        |
|        -----------   ------------         |
|                                           |
 -------------------------------------------
I'm going to add a pref to fix tinderbox, as I said in bug 32571. I do *not*
want to add a dialog. Dialogs are annoying and detract from the user experience.
Outside of an automation situation like tinderbox, allowing a script a window
that was not opened by script is probably never legitimate, and probably not
used anywhere other than malicious pages. It's very easy for the user to close
the window manually.

I was trying to keep this fix simple, and I think a dialog would be unnecessary
bloat.
I wasn't thinking of how easy it is for users to close the window, but rather
how mystifying it is to a developer when a script silently fails. At least a
message in the JS console would be nice.
I think that we can create option in Preferences:

When page want's to close window it doesnt own
[x] Ignore
[ ] Ask what to do
[ ] Close
No, we don't need a _UI_ for this.  Get a clue.
Bryner: You are mistaking your preference not to have a UI for the actual
reality. Get a life.
Let's keep things civil and professional, please. I strongly dislike adding more
dialogs to the product. As I said above, I was trying to keep this fix simple. I
will consider adding a JS console message when we block a close() call, but
that's all. If you want anything different, you'll have to find someone else to
write it.
I only mentioned one of the possiblities.


Basics are the same for me: alert when script asks for close() on window it 
doesnt own.


Sorry if it looked different.
There are multiple issues being raised here:

1. making the UI-less pref work again (the original point of the bug)
2. adding a UI for the pref
3. adding a mechanism to be informed about a script being denied the ability to
close a window, such as
   (a) a dialog
   (b) a JS console warning

For #2, I'd argue that anyone who knows enough to understand what the pref does
should be able to add it to their prefs file.  We don't need to add more stuff
to the prefs dialog, it's already too cluttered.

I think 3(b) is completely appropriate and would be helpful for developers. 
3(a) is only appropriate if you'd expect users to want different behavior at
different times, and I don't see any scenarios outlined here where that would be
the case.  The only cases I'm aware of are typical users, who would want this
always diabled, and tinderbox, which wants it always enabled.
Thanks for your analysis, Brian, I concur. I have restored the hidden pref, plus
a JS console message, in bug 32571. This bug is fixed. Anyone who wants a more
intrusinve UI for this feature, please open a new bug and assign it to someone
other than me.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.