Closed Bug 633154 Opened 12 years ago Closed 8 years ago
Suppressing alert boxes leads to NS
_ERROR _NOT _AVAILABLE
Assignee: nobody → general
Product: Firefox → Core
QA Contact: general → general
This has nothing to do with the JS engine. It also looks like this was a purposeful decision. See the last two paragraphs of bug 61098 comment 209.
Assignee: general → nobody
QA Contact: general → general
The page I work on uses alert boxes for validation messages. Most of the times, the checkbox to suppress further alerts is already shown for the second box. Since we're not catching any exceptions right now, client-side validation gets completely broken after alerts are suppressed.
What do other browsers do in this case?
Safari 5 and IE 8 don't seem to support suppressing alerts. Chrome 9 does what I expected, continuing execution without showing an alert.
Opera has a "Stop scripts executing on this page" checkbox on alerts; I'm not sure what it does.
I'm concerned that this has been whiteboarded toward wontfix -- I believe that this is a real user-experience problem and does *not* behave the way developers expect it to behave. jst's comments from 2003 notwithstanding, this check box should suppress alerts but not throw an exception. AFAIK, Firefox 4 is also the first moz-browser which ships with this option enabled. It should also be noted that malware has changed significantly since 2003, and that we have run-away-script detection now, which I think complete mitigates his concern.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Fwiw, we had runaway script detection then too, iirc.
Is this bug going to not be fixed ever? Note that confirm() has the same bug. I think that alert() should not throw any exception (unless it is some "standard" among most of the browsers). So when alert() is suppressed the JS code should continue without any notice. With confirm() it's more complicated as you expect a return code from this function. So if user suppresses a confirm() with "yes", then he is expecting all other confirm()'s to be confirmed and vice-versa (or not?). The problem is that there could be more confirm() dialogues on the page and user expects browser to remember the choice only for one type of question (eg. "Are you hungry?" -> "Yes", but "Really delete this file?" -> "No"). So I guess the only workaround for this bug try-catching every alert() and confirm() call...
from Bug 681505 comment #3 (In reply to Josh Matthews [:jdm] from comment #3) > This should just be an easy change from |return NS_ERROR_NOT_AVAILABLE| to > |return NS_OK| in nsGlobalWindow::Alert, nsGlobalWindow::Prompt, and > nsGlobalWindow::Confirm. I modified \dom\base\nsGlobalWindow.cpp with NS_OK instead of NS_ERROR_NOT_AVAILABLE in locally . And it worked as expected.
It seems intuitive that a suppressed alert is simply ignored and the code thereafter is executed normally. However, in case of confirm and prompt dialogs the user has an influence on the control flow. The only possibility to keep the code running here is to return default values, as if the user had manually cancelled (false for confirm and null for prompt). This may not work as intended for every script out there, but should be the best bet. It's also what Chrome does btw.
(In reply to Florian Lasinger from comment #13) > […] return default values, as if the user had manually cancelled (false for > confirm and null for prompt). This may not work as intended for every script > out there, but should be the best bet. It's also what Chrome does btw. I think that's the safest option (and IMHO the expected behaviour).
Not sure what the needinfo flag means and why it's associated with me. I'm just the reporter here.
Needinfo means that someone is being asked for information. It can make sense to ask the reporter for information if it's something like "how do I reproduce this?". But yeah, asking you for needinfo for comment 15 doesn't make much sense. > can we catch this error "NS_ERROR_NOT_AVAILABLE" Sure. It's just an exception. You can catch it.
Jonas, since you originally asked for the code to be this way, you get the honor of reviewing. Note that I didn't bother differentiating between the cases when the window is no longer current and the case when it explicitly has dialogs disabled, but I could do that if you think it's worth it...
Attachment #8638564 - Flags: review?(jonas)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Comment on attachment 8638564 [details] [diff] [review] When alerts/prompts/confirms are suppressed, just return silently instead of throwing Review of attachment 8638564 [details] [diff] [review]: ----------------------------------------------------------------- That looks like jst's review and not mine.
Attachment #8638564 - Flags: review?(jonas) → review?(jst)
I'm personally totally fine with silently suppressing the dialog though. Maybe stick something in the error console unless we already are logging this there as a blocked popup.
Comment on attachment 8638564 [details] [diff] [review] When alerts/prompts/confirms are suppressed, just return silently instead of throwing This seems totally reasonable to me. r=jst
Attachment #8638564 - Flags: review?(jst) → review+
QA Whiteboard: [good first verify]
Whiteboard: [lang=c++] → [lang=c++], STR in comment 11
Following the STR from comment 11 , I have reproduced the bug with Firefox 43.0a1(20150909030223) on Windows 7 64 bit. The fix is verified for latest Firefox Beta 43.0b7(20151126120800) UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:43.0) Gecko/20100101 Firefox/43.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Whiteboard: [lang=c++], STR in comment 11 → [lang=c++], STR in comment 11 , [testday-20151127]
You need to log in before you can comment on or make changes to this bug.