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)
Core
DOM: Core & HTML
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.
Comment 1•22 years ago
|
||
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 | | | ----------- ------------ | | | -------------------------------------------
Assignee | ||
Comment 2•22 years ago
|
||
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.
Comment 3•22 years ago
|
||
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.
Comment 4•22 years ago
|
||
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
Reporter | ||
Comment 5•22 years ago
|
||
No, we don't need a _UI_ for this. Get a clue.
Comment 6•22 years ago
|
||
Bryner: You are mistaking your preference not to have a UI for the actual reality. Get a life.
Assignee | ||
Comment 7•22 years ago
|
||
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.
Comment 8•22 years ago
|
||
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.
Reporter | ||
Comment 9•22 years ago
|
||
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.
Assignee | ||
Comment 10•22 years ago
|
||
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.
Description
•